Până în 2008, proiectul de construcție trebuia să includă un document cunoscut în mediul profesional sub denumirea caracteristică "GIP Oath". Acum se numește "asigurarea organizației de proiect că documentația proiectului a fost elaborată în conformitate cu..." [1] și apoi un număr de documente, conform căruia se evaluează.
Dar, ca și înainte, toată lumea înțelege cât de responsabil și cuprinzător este rolul inginerului șef și al arhitectului șef al proiectului - GIP și GAP.
Odată cu debutul erei autoreglementării în domeniul construcțiilor în 2010, funcțiile și responsabilitățile persoanei care realizează pregătirea documentației de proiect (designerul general) sunt stabilite și fixate de legile și documentele federale ale ministerelor și departamentelor [1] [2] [3] [4]. În același timp, regulamentele SNiP din 1985 privind inginerul-șef al Proiectului "[5], care stabilea drepturile, sarcinile și responsabilitățile persoanelor numite pe baza legislației URSS, nu au fost incluse în listele documentelor de standardizare atât pentru utilizarea obligatorie, cât și pentru cele voluntare, și astfel, din 2010, și-a pierdut statutul.
Care sunt actele normative actuale care descriu funcțiile, drepturile, sarcinile și responsabilitățile ISU / GAP?
Resursele informaționale ne abordează la două surse:
- Rezoluția Ministerului Muncii și Dezvoltării Sociale din Federația Rusă din 1998 "Cu privire la aprobarea cărții de referință de calificare a managerilor, specialiștilor și a altor angajați" [6];
- Ordinul Ministerului Sănătății și Dezvoltării Sociale al Federației Ruse în anul 2008 "Cu privire la aprobarea unui singur registru de calificare a funcțiilor managerilor, profesioniștilor și angajaților" [7].
Ambele acte acționează, cu identitatea numelor izbitoare. Documentul din 1998 conține o secțiune privind responsabilitățile inginerului șef și arhitectului șef al proiectului, iar în 2008 numai inginerul șef al proiectului. Ambele documente stabilesc doar obligațiile oficiale și cerințele de calificare și cu aceleași cuvinte.
O lectură atentă arată că Ministerul Sănătății al Rusiei, un deceniu mai târziu (în 2008), aproape cu cuvânt, repetă compilația Ministerului Muncii din 1998 cu SNiP din 1985, în partea dedicată îndatoririlor inginerului / arhitectului șef al proiectului, iar anul trecut ambele ministere sunt o zi ( 02.12.2014) "au actualizat" documentele lor, fără a înlocui un singur cuvânt pe fond în secțiunile corespunzătoare! Duplicarea stereotipică, pe care sunt cheltuiți în mod evident resurse de stat, este încurcată. În corectitudine, observăm că, deși cuvintele și expresiile întregi indică sursa, dar din cauza unui schimb parțial de ocara de plagiat în unele locuri ar fi fost de neconceput.
De la Ministerul Muncii, precum și Ministerul Sănătății, nu deranjez pentru a crea un nou document, care corespunde timpului actual, sau cel puțin pentru a actualiza în mod corespunzător, astăzi vom folosi în continuare hârtia de calc cu SNIP 1985. Amintiți-vă ce funcții au îndeplinit în mod obligatoriu GUI-urile și GAP-urile acum treizeci de ani și, în opinia ministerelor, trebuie să se facă astăzi, este necesar să citați decizia Ministerului Muncii (și, de fapt, toate cele trei acte).
Inginer șef, arhitect șef al proiectului:
"Realizează managementul tehnic al lucrărilor de proiectare și supraveghere în proiectarea instalației și supraveghează construcția, punerea în funcțiune și dezvoltarea capacității de proiectare.
Ia măsuri pentru îmbunătățirea calității documentației de proiectare și estimare.
Pregătește date pentru încheierea contractelor cu clienții pentru dezvoltarea (transferul) produselor științifice și tehnice
Participă la lucrările comisiilor pentru selectarea locațiilor (pistelor) pentru construcții, pentru pregătirea sarcinilor de proiectare și pentru organizarea de studii de inginerie pentru elaborarea estimărilor de proiectare și a altor documentații tehnice
Organiză dezvoltarea pe obiectele care îi sunt atribuite, participă la pregătirea planurilor de planificare cuprinzătoare pentru implementarea lucrărilor de cercetare, proiectare, inginerie și tehnologică
Elaborează orare de eliberare a produselor științifice și tehnice.
Formează sarcinile subcontractanților de a-și îndeplini sarcinile care le sunt atribuite și oferă acestor organizații datele necesare de intrare. Rezolvă problemele care apar în timpul elaborării documentației.
Supraveghează nivelul tehnic al design-ului primit, de planificare urbană, deciziile arhitecturale și de planificare, utilizarea eficientă a fondurilor pentru proiectare si cercetare de lucru, termeni de documentație de proiectare și estimări.
Garantează conformitatea documentației elaborate și a estimării cu standardele, normele, regulile și instrucțiunile de stat.
Oferă pentru prima dată verificarea purității patentului și brevetabilității utilizate în proiect sau a dezvoltat pentru ea procese tehnologice, echipamente, instrumente, structuri, materiale și produse.
Protejează proiectul în cadrul organizațiilor-mamă și al organismelor de expertiză.
Participă la examinarea și aprobarea organizației contractante generale a documentației de proiectare și estimare.
Rezolvă problemele apărute în procesul de proiectare, construcție, punere în funcțiune a instalației, dezvoltarea capacității de proiectare.
Organizează lucrările de eliminare a defectelor detectate în estimările de proiectare și în alte documentații tehnice, precum și privind contabilizarea cheltuielilor cu estimările aprobate.
Elaborează propuneri pentru gestionarea organizației de proiect și a clientului pentru modificarea documentației de lucru referitoare la introducerea de noi documente de reglementare, luând în considerare stadiul actual al construcției.
Coordonează abateri rezonabile față de normele, regulamentele, instrucțiunile existente cu organele de supraveghere de stat și alte organizații care le-au aprobat.
Oferă analiza și sinteza experienței în proiectarea, construcția și funcționarea instalațiilor construite și pregătirea pe această bază a propunerilor de îmbunătățire a nivelului tehnic și economic al soluțiilor de proiectare.
Elaborează recenzii și concluzii privind inovațiile și invențiile, proiectele de standarde, specificațiile tehnice și alte documente de reglementare referitoare la proiectare și construcție.
Participă la examinarea proiectelor, pregătirea publicațiilor și pregătirea cererilor pentru invenții, la lucrările de seminarii și conferințe în specialitatea sa ".
Cum respectă sarcinile enumerate la actualele acte normative privind planificarea urbană, autoreglementarea și reglementarea tehnică? O parte semnificativă a elementelor de mai sus contravine legii atât din punct de vedere terminologic, cât și din punct de vedere al conținutului și nu poate fi executată obligatoriu.
Luați în considerare în ordinea poziției, provocând întrebări în ceea ce privește angajamentul.
1. Managementul tehnic al lucrărilor de proiectare și supraveghere în proiectarea obiectului și supravegherea construcției, punerii în funcțiune și dezvoltării capacității de proiectare.
În conformitate cu Regulamentul tehnic "Cu privire la siguranța clădirilor și structurilor" [8], începând cu 2010, supravegherea autorului este atribuită formelor de evaluare voluntară a conformității și se realizează cu acordul părților, în funcție de decizia dezvoltatorului (client tehnic). Desigur, supravegherea arhitecturală este necesară atunci când se creează opere de arhitectură - ca parte integrantă a procesului creativ și un element de protecție a drepturilor de autor. De asemenea, fără supravegherea autorului, nu există o bază de dovezi pentru responsabilitatea designerului general pentru conformitatea proiectului de construcție de capital construit cu documentația de proiectare, care distruge conceptul piramidal de responsabilitate în condițiile autoreglementării. În același timp, fără supravegherea autorului, nu poate exista nici o participare obligatorie, nici voluntară a designerului general, și mai ales a inginerului sau inginerului, în rezolvarea problemelor de construcție, punerea în funcțiune a instalației și dezvoltarea capacităților de proiectare.
Rețineți că numitele regulamente tehnice [8] au identificat persoanele responsabile de procedurile de punere în funcțiune a obiectului de construcție capitală: antreprenorul general, clientul dezvoltator și / sau tehnic, persoanele care exercită controlul construcției și supravegherea construcției de stat. Acest lucru poate fi incorect și greșit din punctul de vedere al responsabilității interdependente pentru rezultatele proiectării și construcției, însă nici proiectantul general, nici chiar ISU / HAP, nu este menționat în normele actuale atunci când instalația este comandată.
Atâta timp cât supravegherea autorului este definită prin lege ca element voluntar al procesului de construcție, ea nu poate fi imputată obligațiilor oricărei persoane prin act normativ, totuși, dacă este necesar, aceste relații pot fi reglementate prin descrierea internă a postului organizației.
Cele de mai sus se aplică în întregime la p.5. (Rezolvă problemele apărute în procesul de proiectare, construcție, punerea în funcțiune a instalației, dezvoltarea capacității de proiectare).
1). Începând cu anul 2004, în conformitate cu Codul de amenajare a teritoriului [2], termenul "punerea în funcțiune a unui obiect de construcție capitală" ar trebui folosit în locul cuvintelor "punerea în funcțiune a unui obiect".
2). Codul de urbanism [2] nu utilizează conceptul de "utilizare a capacității de proiectare".
2. Participarea la lucrările comisiilor de selecție a locațiilor (pistelor) pentru construcție, la pregătirea misiunilor de proiectare și la organizarea anchetelor de inginerie.
Aici este necesar să reamintim responsabilitățile dezvoltatorului sau ale clientului tehnic stabilite prin Codul de urbanism [2]: "dezvoltatorul sau clientul tehnic este obligat să furnizeze (la proiectantul general): (a se vedea textul din ediția precedentă)
1) un plan de amenajare a unui teren sau în cazul pregătirii documentației de proiect pentru un obiect liniar, un proiect de amenajare a teritoriului și un proiect de monitorizare a terenurilor;
(vezi textul din ediția precedentă)
2) rezultatele anchetelor de inginerie...;
3) condiții tehnice... ".
Și mai departe: "Pregătirea documentației de proiect se realizează pe baza sarcinii dezvoltatorului sau a clientului tehnic".
Astfel, alegerea locațiilor pentru construcție, pregătirea sarcinilor de proiectare și organizarea de sondaje de proiectare (și nu sondaje) nu sunt astăzi o datorie oficială a PIU sau GAP, așa cum a fost treizeci de ani în urmă, ci responsabilitatea funcțională a dezvoltatorului sau a clientului tehnic. Responsabilitățile funcționale ale dezvoltatorului sau ale clientului tehnic sunt prezentate în mod clar în timpul licitațiilor pentru proiectare bazate pe legislația privind achizițiile publice. Datele inițiale menționate mai sus constituie, în acest caz, un pachet de documente de licitație formate de client și participarea la pregătirea managerului de proiect sau GAP, prin definiție, reprezentând designerul general, este considerată o încălcare a legilor antitrust.
3. Asigură conformitatea documentației elaborate și a estimării cu standardele, normele, regulile și instrucțiunile de stat.
În conformitate cu Hotărârea Guvernului „Cu privire la partea de secțiuni ale documentației de proiect...“ [1], evaluarea conformității cerințelor documentației de proiect ale legislației ia forma de „asigurări de organizare de proiectare că documentația de proiect este dezvoltat în conformitate cu planul de dezvoltare urbană a terenului, atribuirea de proiectare,..., reglementările tehnice,... și cu respectarea condițiilor tehnice ". După cum vedem, responsabilitatea în această parte nu este impusă angajatului organizației, ci a organizației generale de proiectanți, ceea ce este adevărat în ceea ce privește autoreglementarea, necesitatea apartenenței generale a designerului în parteneriate specializate și responsabilitatea în cadrul fondurilor de compensare ale acestor parteneriate. Și, pe lângă aceasta, lista documentelor, a căror respectare este evaluată, este complet diferită și a fost din 2008.
4. Coordonează abateri rezonabile față de normele, regulamentele, instrucțiunile existente cu organele de supraveghere a statului și alte organizații care le-au aprobat.
Este necesar să se acorde cea mai gravă atenție principalelor prevederi ale actualului Cod de dezvoltare urbană [2]: "Nu este permisă necesitatea aprobării documentației de proiect, a unei concluzii privind documentația proiectului și a altor documente care nu sunt prevăzute în prezentul cod". Printre concluziile cerute de cod [2], se indică concluziile examinării, examinarea ecologică de stat pentru gama stabilită a obiectelor și examinarea istorică și culturală a obiectelor patrimoniului cultural.
În cazul în care este necesar să se abată de la cerințele documentelor de reglementare, astăzi trebuie să respectăm regulile stabilite de Regulamentul tehnic privind securitatea clădirilor și structurilor [8]: "... dacă pentru pregătirea documentației de proiect este o abatere de la cerințele stabilite de... standardele naționale și codurile de practică... documentația... sunt efectuate în conformitate cu condițiile tehnice speciale. "
Și din nou Decretul guvernamental "Cu privire la componența secțiunilor documentației de proiect..." [1]: "... dezvoltarea documentației (proiectului) ar trebui să fie precedată de elaborarea și aprobarea în mod prescris a unor condiții tehnice speciale". Cu alte cuvinte, condițiile tehnice speciale (CTS) sunt materiale pentru pregătirea înainte de proiect, adică date sursă pentru proiectare. Astfel, armonizarea abaterilor de la cerințele de reglementare de către legislația în vigoare nu prevede și dezvoltarea unui CTS (document care să legitimeze abaterile de la cerințele documentelor de reglementare atunci când sunt îndeplinite anumite cerințe) este responsabilitatea funcțională a dezvoltatorului sau a clientului tehnic.
Deci, se poate afirma că documentele existente privind responsabilitățile PIU / GAP sunt nesatisfăcătoare, deoarece citează norme învechite de treizeci de ani în urmă și nu iau în considerare cerințele moderne ale legislației privind urbanismul, regulile de reglementare tehnică și autoreglementarea în construcții. Încercările de a crea documente metodologice sunt inacceptabile atâta timp cât se bazează pe normele depășite indicate. De exemplu, recent pregătit pentru sistemul de informații Consultant Plus (2015) forma descrierii postului de inginer șef al proiectului, ne întoarce cu încăpățânare la prevederile din 1985. Estimările conflictuale ale cerințelor provoacă o atmosferă de conflict în relațiile dintre dezvoltatori, designeri generali și specialiști specifici.
Necesitatea de a restabili ordinea în acest domeniu din când în când este recunoscută de instituțiile guvernamentale. În 2012, cu puțin timp înainte de aderarea Rusiei la OMC, a fost luată în considerare un proiect al modificărilor nereușite ale codului urbanistic și al altor acte normative și legale cu privire la introducerea institutului inginerului șef și a arhitectului șef al proiectului. Sa propus definirea termenilor ISU și GAP, pentru a stabili termenii de referință și criteriile de calificare în corespondența unu-la-unu direct cu codul urbanistic. În același timp, a considerat problema de a oferi responsabilitate personală Heep și Gap, cu includerea administrativ și codul penal al articolelor relevante cu sancțiuni foarte severe pentru încălcarea îndatoririlor oficiale: amenzi de venituri de 18 luni, închisoare de până la șapte ani...
Se poate presupune că institutul GIP / GAP ar fi fost distrus chiar înainte de crearea sa, dacă s-ar adopta astfel de inițiative legislative. Pe de o parte, astăzi responsabilitatea pentru încălcarea regulilor de proiectare este atribuită proiectantului general cu ajutorul instrumentelor de autoreglementare, al fondurilor de compensare și al asigurării riscurilor. Pe de altă parte, codul penal încă dispune de o sancțiune adecvată în cazul unor daune asupra proprietății, sănătății sau vieții. Dar există oa treia parte a problemei: legislația actuală este destul de contradictorie, insuficientă din punct de vedere terminologic, slab coordonată între diversele ramuri ale reglementării și determină astfel imposibilitatea de a-și îndeplini cerințele fără excepții semnificative. În conformitate cu principiile justiției sociale, este rezonabil să vorbim despre stabilirea responsabilității, cel puțin din punct de vedere administrativ, și atunci când dezvoltăm și adoptăm acte de reglementare contradictorii (și, prin urmare, neaplicabile). Numai cu o legislație logică, consecventă, agreată reciproc în toate domeniile, este posibil să o respectăm cu bună-credință, iar încălcarea poate fi evaluată în mod concludent.
Evident, documentele complexe și complexe care determină în mod fiabil drepturile, obligațiile, cerințele de calificare și responsabilitatea inginerului șef / arhitectului șef al proiectului - figuri-cheie ale procesului de proiect - sunt necesare pe baza cerințelor legale și profesionale moderne. Responsabilitatea, cel mai probabil, ar trebui să fie luată în considerare în legătură inseparabilă dintre toate subiectele relațiilor de planificare urbană, autoritățile legislative și executive. Pentru a elabora o opinie consolidată cu privire la o chestiune atât de acută și insuficient abordată în prezent, ar fi utilă organizarea unei discuții profesionale ample, ale cărei rezultate pot deveni baza unui pachet de modificări necesare și, dacă este necesar, elaborarea de noi acte de reglementare.
Documentele menționate în text:
[1] Decretul Guvernului Federației Ruse nr. 87 din 16 februarie 2008 "Cu privire la componența secțiunilor de documentare a proiectului și cerințele privind conținutul acestora" (REGULAMENT privind componența secțiunilor de documentare a proiectului și cerințele pentru întreținerea acestora)
[2] Legea federală a Federației Ruse nr.190-FZ din 29 decembrie 2004 "Codul de urbanism al Federației Ruse"
[3] Legea federală a Federației Ruse nr. 315-ФЗ din data de 1 decembrie 2007 "Despre organizațiile de autoreglementare"
[4] Ordinul Ministerului Dezvoltării Regionale al Federației Ruse din 30.12.2009 № 624 „Cu privire la aprobarea listei de lucrări pe studii de inginerie, pregătirea documentației de proiect pentru construcții, reconstrucție, reparație de construcție de capital, care afectează securitatea construcțiilor de capital“
[5] SNiP 1.06.04-85 "Reglementări privind inginerul șef (arhitect șef) al proiectului"
[6] Rezoluția Ministerului Muncii și Dezvoltării Sociale din Federația Rusă din 21.08.1998 Nr. 37 "Cu privire la aprobarea cărții de referință a calificărilor managerilor, specialiștilor și a altor angajați". Secțiunea II, Partea 2. "Poziții de conducători și lucrători tehnico-tehnici ai organizațiilor de proiectare, inginerie, tehnologică și de cercetare", paragraful "Inginer șef de proiect. Arhitectul principal al proiectului.
[7] Ordinul Ministrului Sănătății și Dezvoltării Sociale al Federației Ruse din 23 aprilie 2008 nr. 188 "Cu privire la aprobarea unei singure cărți de referință de calificare pentru manageri, specialiști și angajați", secțiunea "Caracteristicile calificării managerilor și specialiștilor în arhitectură și activități de urbanism". Partea 5 "Design", p.5.1. "Pozițiile managerilor. Proiectant inginer.
[8] Legea federală a Federației Ruse nr. 384-ФЗ din 30 decembrie 2009 "Reglementări tehnice privind siguranța clădirilor și structurilor".
Cine poate fi o hipoglicemie
Grupa: Noutati
Mesaje: 11
Înregistrare: 01/31/2011
Cod de utilizator: 91953
Grupa: Moderatori
Mesaje: 34679
Înregistrare: 07/11/2006
Din: Moscova
Cod de utilizator: 3370
Grup: participanți la forum
Mesaje: 1553
Înregistrare: 8.1.2008
Din: Krasnoyarsk
Cod de utilizator: 14254
nu, nu pot.
și de ce aveți nevoie de asta?
Ei bine, acesta este un caz penal, cu această experiență.
ștampila, de exemplu, cum se va umple?
GUI - I
făcut - eu
și.t.p.?
Post a fost editatDaniel - 4.4.2012, 9:13
Grupa: Noutati
Mesaje: 8
Înregistrare: 04/12/2010
ID utilizator: 51897
Grupa: Moderatori
Mesaje: 34679
Înregistrare: 07/11/2006
Din: Moscova
Cod de utilizator: 3370
Grupa: Noutati
Mesaje: 11
Înregistrare: 01/31/2011
Cod de utilizator: 91953
Grupa: Moderatori
Mesaje: 34679
Înregistrare: 07/11/2006
Din: Moscova
Cod de utilizator: 3370
Grup: participanți la forum
Mesaje: 1302
Inregistrat: 4 decembrie 2009
De la: împotriva risipei de resurse naturale de neînlocuit
Cod de utilizator: 41817
Grup: participanți la forum
Mesaje: 2360
Inregistrat: 12.7.2006
Din: Harkov
Cod de utilizator: 3382
Grupa: Moderatori
Mesaje: 34679
Înregistrare: 07/11/2006
Din: Moscova
Cod de utilizator: 3370
Grup: participanți la forum
Mesaje: 104
Înregistrare: 01/24/2010
Cod de utilizator: 45022
Pentru GUI, este nevoie de experiență, se semnează interfața grafică în pagina de titlu, proiectul a fost finalizat în conformitate cu standardele actuale și este rezistent la explozie, ignifug, adică este pe deplin responsabil pentru luarea deciziilor tehnice. Anterior, în birourile proiectului, era necesar să se obțină semnătura pe proiect, semnătura inginerului senior, inginer-pilot, lider de echipă, apoi specialist șef, șef de departament, GIP și apoi semnat-o în departamentul de control tehnic.
Postul a fost editedvladi - 04.04.2012, 20:10
Inginerul șef de proiect este o poziție ca asta sau ceva.
proiectarea structurilor hidraulice
Vreau să fiu fotograf
(((Acesta este un țap ispășitor plătit pentru vînătoare și un grătar.
Și, dacă este necesar, pot scana mâine la lucru drepturile, obligațiile și responsabilitățile care îi revin în temeiul legii. )))
Dacă există posibilitatea scanării, este deosebit de interesantă responsabilitatea conform legii (numere de articole, etc.).
Dacă este vorba despre interfața grafică, atunci aveți nevoie de ea.
Faptul este că, de exemplu, în lista de posturi de locuri de muncă în construcții există doar inginerul șef și designer-șef.
În măsura în care înțeleg, ISU nu este o poziție, ci un statut temporar atribuit unui anumit proiect.
Răspunderea prin lege, am vrut să spun, bine, știi ce. - Moartea unei persoane, datorită studiului incomplet al proiectului, datorită viciilor designerilor. - Răspunderea penală.
Acest curs de pliante scanate "Organizarea și managementul în domeniul designului".
[ATTACH] 1147756227.jpg [/ ATTACH]
proiectarea structurilor hidraulice
Într-un birou, GAPom a devenit o fată care a primit doar o diplomă, iar lucrarea a devenit insuportabilă. Asta e capriciul regizorului, pentru că el este un om fără educație la acel moment, este dificil pentru el să se certe cu un specialist PTS real, așa că a făcut o astfel de mișcare.
Oricum, tandemul ar putea schimba cu usurinta sectiunea Republicii Azerbaidjan cand CR era pregatit pentru aceasta, si a fost davolno la nivel global, iar acest lucru a devenit normal. Toți erau încărcați cu lucruri inutile pe amigdalele. Invertirea fără sfârșit fără sens și reluarea aceluiași lucru. Nu vreau să vorbesc despre detalii, dar a ajuns la punctul că clădirea cu mai multe etaje a fost proiectată din 3 locuri, 1 pornind de la etajele întâi, 2 din vârf, 3 din mijloc (adică podele). În cele din urmă, podelele nu se potriveau. Nitsche, remodelate. Și atunci când redone, sa dovedit secțiunile adiacente nu corespund cu AR, și davolno în serios. Când secțiunile adiacente au început să fie corectate, s-a dovedit că nu era o podea tehnică, era ideea regizorului, dorea să dizolve totul sub tavanul birourilor și să "coboare" subcontractanții cu propriile SNiP-uri. Această problemă sa încheiat cu o scădere a numărului de locuri de parcare în garajul subteran, trebuia să le reduc la podeaua tehnică.
Pe parcursul anului, toți specialiștii reali au renunțat, inclusiv pe mine. Și ce zici de fată, destul de mult timp. E în regulă dacă nu știe dimensiunea cărămizii sau de ce este făcută asfaltul, etc.
Cine poate fi o hipoglicemie
Paragraful 2 al articolului 55.5 alineatul (6) din Codul de urbanism prevede următoarele:
„6. Cerințele pentru membrii unei organizații de autoreglementare stabilite în standardele organizației de autoreglementare și în documentele interne ale organizației autoreglementatoare nu pot fi mai mici decât minimul stabilit în această parte:
2) cerințele pentru prezența unui antreprenor individual sau a unei persoane juridice specializate în organizarea anchetelor de inginerie (ingineri șefi de proiect), specialiști în organizarea proiectării arhitecturale și de construcție (ingineri șefi de proiect, șefi de proiect), organizatori de construcții (ingineri șefi de proiect) a cărui funcție constă, respectiv, în organizarea efectuării anchetelor de inginerie, executarea lucrărilor de pregătire a documentației de proiect, lucrări de construcție construcția, reconstrucția, revizia obiectelor de construcții de capital și informații despre care sunt incluse în registrele naționale ale specialiștilor prevăzuți la articolul 55.5-1 din prezentul Cod (denumiți în continuare și specialiști) sunt cel puțin doi specialiști la locul de muncă principal ".
Clauzele 1, 3, 6 din articolul 55.5-1 din Codul de urbanism au următorul text:
„1. Specialist în organizarea anchetelor de inginerie, specialist în organizarea de proiectări de arhitectură și construcții, specialist în organizarea construcțiilor este o persoană care are dreptul de a desfășura, în baza unui contract de muncă cu un antreprenor individual sau persoană juridică, funcții în organizarea lucrărilor de inspecție inginerie, documentația, construcția, reconstrucția, revizia obiectului construcției de capital în postul principal inginer de proiect, arhitect-șef al proiectului și informații despre care este inclus în registrul național al specialiștilor în domeniul studiilor de proiectare și proiectării arhitecturale sau în registrul național al specialiștilor din domeniul construcțiilor. "
„3. Funcțiile oficiale ale specialiștilor în organizarea studiilor de inginerie, specialiști în organizarea de proiectări arhitecturale și de construcție includ, respectiv:
1) pregătirea și aprobarea sarcinilor de efectuare a anchetelor de inginerie, sarcini pentru pregătirea documentației de proiect a instalației de construcție de capital;
2) stabilirea criteriilor de selecție pentru participanții la lucrările de realizare a anchetelor de inginerie, pregătirea documentației de proiect și selectarea executorilor acestor lucrări, precum și coordonarea activităților executorilor acestor lucrări;
3) depunerea, aprobarea și acceptarea rezultatelor lucrărilor privind implementarea anchetelor de inginerie, pregătirea documentației de proiect;
4) aprobarea rezultatelor anchetelor de inginerie, documentația proiectului ".
„6. Informațiile despre persoana specificată în partea 1 a prezentului articol vor fi incluse în registrul național al specialiștilor din construcții de către Asociația Națională a Organizațiilor de Autoreglementare relevante în registrul național al specialiștilor în domeniul anchetelor de proiectare și proiectare arhitecturală (denumiți în continuare registre naționale de specialiști) aplicarea unei astfel de persoane, sub rezerva respectării următoarelor cerințe minime:
1) prezența învățământului superior în profesie, specializare sau formare în domeniul construcțiilor;
2) prezența experienței de muncă în organizațiile care efectuează studii de inginerie, pregătirea documentației proiectului, construcția, reconstrucția, revizia proiectelor de construcție de capital în poziții de inginerie timp de cel puțin trei ani;
3) prezența unei experiențe de muncă totale în profesie, specialitate sau direcție de formare în domeniul construcțiilor nu mai puțin de zece ani;
4) dezvoltarea profesională în direcția formării în domeniul construcțiilor cel puțin o dată la cinci ani;
5) disponibilitatea unui permis de muncă (pentru cetățenii străini) ".
Șeful unei entități juridice - membru al unei organizații care se autoreglează, poate încredința responsabililor inginerului-șef al proiectului un angajat care nu îndeplinește cerințele de mai sus, totuși îndeplinirea de către angajat a îndatoririlor enumerate la paragraful 3 al articolului 55.5-1 va fi ilegală (a se vedea partea finală a scrisorii explicative a Ministerului Construcțiilor din Rusia) 08.06.2017 Nr. 20243-TB / 02).
Semnătura inginerului șef al proiectului în documentația de proiect prezentată spre examinare înseamnă aprobarea, acceptarea și aprobarea acestuia, adică atribuțiile unui specialist în organizarea proiectării arhitecturale și de construcție, prin urmare, comentariul expertului este legitim.
Inginerul șef de proiect este o figură cheie în procesul de proiectare.
M.S. Podolsky, președintele Subcomisiei pentru organizarea activităților șefilor ingineri ai proiectelor Comitetului pentru proiectarea tehnologică a unităților de producție ale Asociației Naționale a Designerilor și Surveyorilor, director științific al Școlii Internaționale de Ingineri Șefi (Arhitecți Șefi) al proiectelor de la MGSU
A. V. Litvinov, Director General Adjunct, Centrul de Consultanță "TsNIO-Project", membru al Consiliului Școlii Internaționale de Ingineri Chief (Arhitecți Șef) al Proiectelor la MGSU
În condițiile de afaceri moderne, clientul are posibilitatea de a alege organizația de proiect (software) în funcție de raportul optim dintre timpul, prețul și calitatea serviciilor oferite. Odată cu egalitatea aparentă a criteriilor de mai sus, calitatea documentației proiectului poate fi o condiție decisivă pentru succesul software-ului în competiție. Calitatea documentației proiectului este evaluată atât prin parametrii obiectivi - conformitatea cu cerințele regulilor și reglementărilor actuale, cât și subiective - pentru a maximiza satisfacția clienților. Și acești parametri și alți parametri se schimbă în mod constant: clienții se deplasează de la proiectarea standard la schimbările individuale, lunare și adăugiri la bazele de reglementare și tehnică și legislativă, apar noi materiale de construcție, echipamente noi, tehnologii etc.. Clientul obișnuit este "mulțumit" sau "Nu satisfăcut" cu documentația proiectului este completată de necesitatea de a crește în mod constant satisfacția clienților, iar acest lucru este inerent în ideologia standardelor internaționale ISO 9000.
Pentru a asigura calitatea necesară a produselor, software-ul ar trebui, dacă nu să țină pasul cu progresul științific și tehnologic, cel puțin să țină pasul cu, oferind clientului noi soluții de design originale și de încredere.
Ce împiedică îmbunătățirea reală a activității șefilor de ingineri (șefii de arhitect) ai proiectelor (CIP)? În opinia noastră, în primul rând, stereotipurile incorecte existente cu privire la locul și rolul GIPA în procesul de proiectare, care sunt transmise din generație în generație de designeri, și în al doilea rând, lipsa calificărilor de capete în probleme legate de activitatea GIPov care nu le permite să ia adecvată soluții, și al treilea rând, lipsa unei idei clare a ceea ce constituie soluții de proiectare de calitate și pentru o parte din ea este responsabilitatea ISU, în al patrulea rând, înțelegerea simplificată a mecanismului calității actului de formare și, în special, atunci când este pus în aplicare în subproektirovschikov, și în cele din urmă, în al cincilea rând, pentru că cei mai mulți designeri nu au realizat încă importanța GIPA în reducerea costului lucrărilor de proiectare.
Ar fi greșit să credem că liderii software-ul în sine nu GIPy doresc să elimine motivele menționate mai sus, dar încercările lor nu aduce rezultate semnificative, adică. A. În loc să se bazeze pe fapte care dicteaza in mod clar deciziile corecte, ele sunt ghidate de experiența din trecut și subiective vederi care nu îndeplinesc cerințele timpului.
În procesul de dezbatere a acestor probleme, ne-am aflat adesea pe părțile opuse ale baricadelor cu mulți dintre colegii noștri - cu un fel de "adversar colectiv", ale cărui vederi au fost modelate istoric și care încă mai trăiesc în realitatea economică din trecut. Acest articol este o obiecție suplimentară față de "adversarul colectiv".
După cum se știe, managementul modern recomandă documentarea unor reglementări importante, dar apariția oricărei reglementări ar trebui să fie precedată de formarea unor principii care să stabilească, de exemplu, "de-a lungul sau peste râu" un pod care va fi construit. Aceasta este cea mai importantă parte a procesului de reglementare. În acest stadiu, trebuie să se ajungă la un consens în comunitatea profesională, după care orice restricție de reglementare să nu contravină principiilor convenite.
Din păcate, în realitate, triumful "stereotipurilor proaste", care în majoritatea cazurilor nu este legat nu numai de știința organizării și managementului producției, dar adesea doar de bunul simț.
Să ne referim la unele, după părerea noastră, idei greșite, scăderea căreia este o rezervă reală în dezvoltarea afacerii proiectului:
1. ISU este responsabil pentru calitatea documentației proiectului (de lucru), adică ISU este responsabil pentru tot.
Nu poate fi. Cerințele pentru poziție sau, așa cum se spune astăzi, "responsabilitatea și autoritatea" ISU au fost corelate istoric cu complicațiile cerințelor pentru obiectele de proiectare, precum și schimbările în așteptările clienților cu privire la rezultatele designului. În trecut, proiectarea și construcția au fost gestionate de un specialist care a luat toate deciziile. În prezent, principala sarcină a companiei este de a asigura dinamica necesară a investițiilor, precum și venitul clientului din proiect, suficient pentru a compensa investitorii pentru resursele investite de aceștia și riscul asumat. Astfel, toate deciziile în proiectarea ISU se bazează pe criteriul eficienței economice a proiectării, construcției și funcționării obiectului. Prin urmare, cerințele pentru calificările sale. Toți ceilalți participanți la procesul de proiectare iau decizii cu privire la criteriul optimalității tehnice și această condiție se realizează în procesul de coordonare a deciziilor de proiectare de către principalii specialiști în secțiunile proiectului.
2. "Jurământul" GIP elimină responsabilitatea pentru calitatea documentației de proiectare (de lucru) de la ceilalți participanți la proiectare.
Cu alte cuvinte, ISU este responsabil pentru respectarea proiectelor de norme și standarde pentru proiectarea, construcția și exploatarea instalațiilor de, standarde ale organizațiilor de autoreglementare, cerințele individuale ale clienților la nivel tehnic și de calitate a expresivității arhitecturale, și facilități sociale. Considerăm necesar să ne întoarcem la simțuri: responsabilitatea pentru ce și în ce cazuri.
Este evident că responsabilitatea poate apărea dacă se descoperă un rezultat negativ al lucrării, pe care specialistul la efectuat personal sau personal; dacă există o semnătură corespunzătoare, susținută de dată și, de asemenea, documentată, pentru ce și în ce se asumă responsabilitatea și când se încheie. Acestea sunt condiții obligatorii pentru responsabilitatea personală. În caz contrar, prevalează iresponsabilitatea colectivă. Să dăm un exemplu. După cum știți, desenele trebuie semnate: "dezvoltat", "verificat" și "control normal". Atragem atenția asupra faptului că semnăturile sunt date în ceea ce privește acțiunile, adică răspund la întrebarea: ce ați făcut? - dezvoltat; ce ai făcut? - să îndeplinească un control normativ, etc. nu ar trebui să li se permită „inițiativă“ organizații de proiect și apariția unor desene Semnături șefi de departamente, specialist principal, inginer-șef al proiectului, și astfel schimburi de focalizare, și semnăturile au început să se determine nu „a“ și „Cine.... a făcut. "
După cum am menționat deja, semnătura reprezintă responsabilitatea. Nicio semnătură - nici o responsabilitate. Deoarece responsabilitatea are limite, este necesar să se convină asupra locului unde se află, adică să se asigure că toată lumea înțelege în mod egal zona de responsabilitate. Semnificația acordului este următoarea: fiecare desen are conținut ("ce" este reprezentat) și design ("cum" este prezentat). Contractantul este responsabil pentru conținutul și designul. Pentru conținutul - în fața examinatorului, pentru proiectare - în fața controlerului normal. Responsabilitatea contractantului încetează în momentul în care semnăturile vor fi date de către inspector și controlor. În continuare, este necesar să se determine cine este responsabil de verificator și de controlor. În mod ideal, acesta ar trebui să fie un client care este cu adevărat interesat de potrivirea semnăturii și a rezultatului. În organizația de proiect în sine, este imposibil să se găsească adepții verificării și normontroller. Dar poate fi un GUI? În acest caz, Heep semnătură ar însemna că el a verificat încă o dată conținutul și aspectul de desen, și-a asumat responsabilitatea pentru ei înșiși, inclusiv „pentru respectarea proiectelor de norme și standarde pentru proiectarea, construcția și exploatarea...“ și așa mai departe. D. Și etc. Este imposibil însă verificarea fizică a tuturor soluțiilor de proiectare pentru îndeplinirea tuturor standardelor și a tuturor cerințelor ISU. Prin urmare, de stabilire pe răspunderea GIPA orice pentru toți - nu mai mult de o vrajă, o formală din cauza incapacității de a efectua periculoase și, dacă este necesar, să fie pedepsit pentru vina altcuiva. GUI este doar unul dintre mulții autori ai piesei "pregătirea documentației proiectului".
3. Dacă se întâmplă ceva grav pe șantier, acesta va fi primul care va fi "plantat" de GIP.
Dacă nu va fi ceva cu adevărat serios, investigatorul, numit examinare tehnică medico-legală sau de a petrece câteva astfel de evaluări va determina ordinea de designer, care, de exemplu, efectuat calculele de proiectare, și aplicate rata incorecte, apoi a determina care a verificat calcul și este la această persoană să prezinte un urmărirea penală, dar instanța poate, în anumite circumstanțe, să pedepsească făptuitorul și verificatorul.
4. GUI ar trebui să fie cel mai calificat designer în toate secțiunile proiectului.
Este clar că acest lucru nu poate fi pur și simplu, deoarece în documentația de proiect nu mai puțin de zece secții specializate, lucrarea pe care se presupune prezența a mai mult de douăzeci de specialități. Acest "stereotip rău" se extinde și la ideea de a numi un specialist în postul Institutului. Cu toate acestea, este recomandabil să luăm decizia de numire a UIP pe baza unei selecții competitive și să ne ghidăm pe criterii complet diferite.
Solicitantul pentru funcția de GIPA trebuie să justifice solicitantului posibilitatea de a atinge parametrii tehnici și economice superioare ale obiectului proiectat, reducând condițiile inițiale de proiectare și construcție, a redus volumul de muncă (cost) lucrări de proiectare, mai favorabile condițiilor de calcul organizarea proiectului cu participanții de lucrări, precum și extinderea cerințelor suplimentare client pe obiectul de proiectare (7.2.1 "d" GOST R ISO 9001-2008), etc. O importanță deosebită o are reputația GIP: caracter, comunicare durabilitate, diligență, angajament, eficiență, punctualitate, decență, capacitate de negociere, atenție, politețe, reactivitate, eficiență etc.
Pentru obiectele civile, un avantaj în numirea în funcția de arhitect șef al proiectului (GAP) poate fi prezența educației economice și arhitecturale. A doua prioritate este educația economică, a treia este arhitecturală și, în final, doar inginerie.
Pentru facilitățile industriale (design tehnologic), un avantaj în alegerea funcției de Inginer Proiect (CIP) poate fi disponibilitatea educației și a tehnologiei economice, corespunzătoare specificului obiectului de proiectare. A doua prioritate este educația economică, a treia este tehnologică și, în final, doar inginerie.
În primul și al doilea caz, managerul de proiect trebuie să aibă o calificare de management al proiectului. Conform rezultatelor selecției competitive, ISU este numit la post prin ordinul relevant al managerului de software.
5. În cazul în care apar dezacorduri între principalii specialiști din secțiunile proiectului, ISU ia decizia finală.
Imaginați-vă următoarea scenă: specialist principal - electrice în partea sa din proiect a decis că tabloul este ceva între aceste axe și la o anumită altitudine a clădirii. Principalul specialist - un inginer de căldură în același loc are o stație. Ei vin la ISU să "facă pace". Desigur, calificarea fiecăruia dintre specialiștii-șefi în specialitatea relevantă este mai mare decât cea a ISU. Dacă ISU va discuta această problemă cu ei în planul tehnic propus, atunci este evident într-o poziție dezavantajoasă. Acesta trebuie să traducă discuția în plan economic, spunând că o opțiune este în valoare de atât de mult, iar celălalt - atât de mult, luând în considerare nu numai costurile de construcție ci și costurile de exploatare, precum și riscurile potențiale asociate cu schimbările din costul echipamentului. Acceptarea și justificarea deciziei din punct de vedere economic, ISU, care este responsabilă de decizia investitorului, ar trebui să caute de la specialiști o soluție tehnică adecvată. Astăzi, puține dintre GUI-urile pot acționa în acest fel, dar aceasta este misiunea GUI, partea sa de responsabilitate pentru calitatea deciziilor de proiectare.
6. O interfață grafică ar trebui în primul rând să aibă o specialitate tehnică.
Am vorbit deja despre ce specialitate și de ce ar trebui să fie la GUI. În condițiile ratelor accelerate de dezvoltare științifică și tehnică, calitatea documentației proiectului depinde direct de pregătirea sistematică avansată a GIP. Astăzi, ISU trebuie să fie competent în organizarea și gestionarea procesului de proiectare, metode pentru asigurarea eficienței economice a proiectării, construcției și funcționării instalației pentru a-și obține poziția pe o bază competitivă. Dar chiar și cu succes GUI-uri simt insuficiența cunoștințelor lor pe aceste probleme, încercați să compensați în mod independent lacunele în competențele lor.
Pentru a rezolva aceste probleme la inițiativa Comitetului pentru proiectarea tehnologică a instalațiilor de producție NOPRIZ și Institutul de Construcții și Arhitectură (ISA) al Universității Naționale de Cercetare de Stat din Moscova constructii (MGRS), cu ajutorul „proiectului TSNIO“ consultativ Centrul și Comitetul pentru educație profesională continuă în industria construcțiilor Uniunea rusă a constructorilor (RCC) a organizat proiectele Școlii Internaționale de Ingineri Șefi (Arhitecți Șefi). Consiliul Școlar include specialiști bine cunoscuți în Federația Rusă și țările CSI în domeniul proiectării și asigurării calității documentației proiectului (de lucru). Președinte al Consiliului Școlii Internaționale de Ingineri Șefi (Arhitecți Șef) al proiectelor Mescherin Igor Viktorovici are o experiență unică în lucrul cu GAP și GIP în URSS, Rusia, SUA și Italia.
Informații despre Școala GIPov International (Gapova), inclusiv punerea în aplicare a cursurilor specifice postate pe website-ul ISA MGSU, Asociația Națională a designerilor și topografi, proiect TSNIO, precum și pe site-urile „Proiectantul“ din Federația Rusă, Kazahstan, Belarus și Ucraina.
Obiectivul principal al Școlii Internaționale a GIP-urilor - prin formarea avansată de formare a personalului cu înaltă calificare din GIP. Îndeplinirea cerințelor moderne ale programului, orientarea practică a cursurilor pentru a satisface nevoile de proiectare tehnologică și de arhitectură, pentru a menține o creștere profesională continuă și reproducerea GIPov și gătit la comandă piscina organizațiilor de proiectare talentul pentru a umple posturi GIPov.
Există două produse principale în "portofoliul educațional" al Școlii Internaționale de Informații Științifice și Industriale:
Sistemul propus de reconversie a GIP-urilor este flexibil, adecvat nevoilor timpului, răspunzând nevoilor reale ale designerilor extrem de ocupați cu munca practică. Conținutul programelor este echilibrat între cunoștințele teoretice și practice, precum și experiența în managementul de proiectare. Este foarte important ca programul implică o acoperire teritorială largă a publicului și comoditatea de formare, inclusiv prin utilizarea unor principii moderne, forme și metode de formare: modularitate, de învățare „pentru a avea ca rezultat“, variația termenilor de formare, de învățare la distanță, etc...
Principalele subiecte discutate în cursurile Școlii Internaționale de GIP la MSSU:
1. Situația pe piața construcțiilor și impactul acesteia asupra activităților ISU.
2. Principalele modificări ale conținutului conceptului de "sistem de management al calității" în legătură cu activitatea ISU.
3. Distribuirea de organizare a proiectului (PO), responsabil pentru dezvoltarea de soluții de proiectare și de calitate între primul director, inginer șef, director al producției, GIPom, departamentul tehnic și departamentele de producție (ateliere) în procesul de pregătire, producție și vânzări în cadrul proiectului de construcție (tehnic a) documentația, inclusiv controlul, verificarea, analiza, coordonarea, validarea și aprobarea documentației de proiectare și estimare.
4. Clarificarea rolului și locului în GIPov „prin procesul de“ software, centrată pe client „interacțiunea cu clientul“ - „formarea și susținerea software-ului de portofoliu“ - „Pregătirea și proiect de producție / implementare (de lucru) documentație“ - „Sprijin pentru punerea în aplicare a proiect în construcții "-" îndeplinirea obligațiilor de garanție pentru proiectele implementate în construcții ".
5. Șeful unității de producție: proiectantul sau managerul (managerul)? Interacțiunea cu GUI. Principalele obiective ale conducerii conducătorului unității de producție: resursele de muncă, munca, timpul, finanțele, resursele materiale; subordonarea, autoritatea, obligațiile funcționale de bază (responsabilitatea) șefului unității de producție, criteriile de evaluare a activităților sale.
6. Procedura de "lansare" a lucrărilor privind pregătirea documentației de proiect în conformitate cu acordul de proiect încheiat. Contractul aproximativ cu organizația de proiectare subcontractantă (ACT); procedurile de evaluare, selecția (selectarea) și reevaluarea software-ului open source; concepte de subcontractare și externalizare.
7. Interacțiunea GUI cu departamentul contractual, arhiva tehnică, departamentul de lansare a proiectului. Cerințele principale pentru ISU în sistemul de disciplină executivă.
8. Analiza noilor responsabilități ale ISU; descrierea tipică a postului ISU; cerințele pentru interfața grafică în desfășurarea supravegherii pe teren (inclusiv a sub-designerilor); GUI și probleme de re-echipare tehnică, extindere a întreprinderii, modernizare, revizie etc.
9. Monitorizarea satisfacției clientului cu procesele și rezultatele organizării proiectului.
10. Rolul GUI în extinderea tipurilor de produse (servicii) ale organizației proiectului. Formarea reputației companiei printre participanții la proiectul de investiții.
11. Subproiecte de management. Cerințe moderne pentru selectarea participanților la proiect.
12. Observații privind proiectul noilor documente organizatorice și procedurale pentru GIPov: standarde profesionale Heep, Recomandări privind organizarea GIPA activități ProfilyuGIPa, cerințele de formare și de numire ca GIPA, care sunt dezvoltate în Subcomisia pentru organizarea inginerului-șef al Comitetului pentru proiectarea tehnologică a proiectelor obiectelor destinație de producție NOP în anul curent.
13. Negocierea la încheierea contractelor și stabilirea prețurilor contractuale. Tipuri de contracte.
14. Interacțiunea cu expertiza de stat și non-stat.
15. Cadrul juridic și organizațional pentru proiectarea, documentele de reglementare legate de activitatea GIP, inclusiv GOST R 54869-2011, precum și sistemul EUROCODES.
16. Costul lucrărilor de proiectare. Indice de bază și metode de resurse pentru calcularea costului. Forme de documentație bugetară. Evaluarea eficienței economice a soluțiilor de proiectare.
17. Managementul riscului de proiect. Identificarea și identificarea riscurilor (categorii de risc, riscurile cunoscute și riscuri necunoscute, mărimea riscului, probabilitatea apariției și gradul de influență a riscului); gestionarea riscurilor pentru gestionarea riscurilor; determinarea probabilității de implementare a termenelor limită și a bugetului proiectului tehnici de răspuns la risc (evitarea, transferul, atenuarea și acceptarea); controlul simptomelor de risc.
18. Participarea la licitații pentru un contract de lucrări de proiectare și supraveghere.
19. Principalele prevederi ale sistemului de management al calității în organizația de proiect care îndeplinește cerințele GOST ISO 9001-2015.
20. Funcțiile și conținutul supravegherii tehnice a clientului. Supravegherea construcțiilor de stat.
21. Competența Institutului în materie de auto-educație și formare avansată.
22. GIP, GAP în structurile funcționale, organizaționale și financiare ale organizației proiectului.
23. Competența GIP referitoare la marketing și vânzări.
24. Competența GIP în stabilirea competențelor, drepturilor și responsabilităților sale.
25. Competența Institutului în evaluarea eficacității și eficienței activităților sale profesionale și a motivației.
Din mai 2015, un program suplimentar "Estimarea eficienței economice a soluțiilor de proiectare" (30 de ore) a fost inclus în Programul Școlii Internaționale de Informații Științifice și Tehnologice. Volumul total al Programului devine 80 ac. o oră Acest modul este predat de profesorii Academiei de Stat pentru Profesioniști în Investiții (GASIS) al Universității Naționale de Cercetare Școala Superioară de Științe Economice. Studenții primesc, de asemenea, un certificat GASIS.
Programele tematice propuse International School GIPov educaționale, consiliere și cercetare axat pe rezolvarea problemelor de bază cu care se confruntă în prezent cu care se confruntă organizațiile de proiectare prin formarea reală a cifrelor cheie ale procesului de proiectare - GIPov.
Pe temele principale ale Programului Școlii Internaționale de GIP, Centrul de Consultanță "TsNIO-Project" a elaborat recomandări specifice.
Să trecem acum la mecanismul de modelare a calității deciziilor de proiectare pentru a stabili în mod clar și fără ambiguitate limitele responsabilității ISU.
Unele prevederi comune de proiectare:
1. Orice proiect de construcție este o combinație a trei modele:
- modele de obiecte viitoare (soluții de planificare spațială și inginerie);
- modelele sale de creare (proiectul de organizare a construcțiilor);
- modele de funcționare a acestuia (organizarea și managementul producției).
2. Formarea unei decizii de proiectare este alcătuită din adoptarea efectivă a acesteia, iar apoi este necesar să se confirme respectarea acesteia, cu alte cuvinte, să se verifice. Adoptarea unei decizii de proiectare în sine este o alegere între alternative, iar confirmarea conformității are multe opțiuni diferite și, în consecință, numeroși termeni care corespund acestor opțiuni. Majoritatea opțiunilor depind de timpul, locul și standardele care sunt selectate pentru confirmare.
Calitatea deciziei de proiectare constă în patru proprietăți de bază. Fiecare dintre aceste proprietăți este format de cineva din software și este destinat unei persoane. Cel care formează proprietatea calității poartă răspunderea personală pentru acest lucru. Prima este "capacitatea tehnică", adică soluția de proiectare trebuie să fie astfel încât să poată fi implementată în timpul construcției. Este necesar, în primul rând, contractantul clădirii, tehnicienii săi, inginerii și principalii experți ai diviziilor industriale. Al doilea este "oportunitatea informațională", deci decizia de proiectare trebuie să conțină toate informațiile necesare pentru executarea lucrărilor de construcție și instalare, comandarea echipamentului, primirea tuturor autorizațiilor și autorizațiilor necesare. Are nevoie de un client și de un constructor. Această proprietate este formată de tehnicieni, ingineri și specialiști șefi ai unităților de producție. A treia este "fezabilitatea economică" a soluției de proiectare, adică soluția de proiectare trebuie să fie competitivă din punct de vedere economic în timpul construirii și funcționării instalației. Acest lucru este necesar pentru persoana principală de pe piață - investitorul, este format și ISU este responsabil pentru acest lucru. Al patrulea este "sistemic", adică toate deciziile de proiectare asupra proiectului trebuie să fie coordonate. Acest lucru este necesar în primul rând de către proiectanții înșiși, iar principalii specialiști în secțiunile de proiecte sunt responsabili pentru acest lucru.
Deciziile de proiectare se fac pe cinci nivele. Luați în considerare aceste niveluri pe exemplul secțiunii de proiectare a proiectului. Primul nivel va fi "noduri, părți." La acest nivel de tehnologie, se iau decizii privind întărirea ochiurilor, pieselor încorporate etc. Al doilea nivel este "elemente". La acest nivel, inginerii proiectează grinzi, coloane, fundații libere etc. Al treilea este "componente". Senior și ingineri de conducere proiectarea suprapuneri, acoperitoare, structuri de închidere, etc. Al patrulea nivel este "secțiunea de proiect". La acest nivel, specialistul-șef hotărăște proiectarea structurală a clădirii și principalii parametri de rezistență ai structurii. Al cincilea nivel - "indicatori tehnici și economici ai proiectului". ISU este responsabil pentru luarea deciziilor la acest nivel.
Să trecem la "confirmarea conformității soluției de proiectare". Acest control, evaluare, verificare, analiză, validare, coordonare și aprobare a deciziilor de proiectare. Aici este important pentru noi să determinăm limitele responsabilității GUI.
Controlul implică corelarea deciziei de proiectare adoptate cu normele existente (regulile), adică documentele de reglementare care funcționează în prezent în complexul de clădiri (Codul de urbanism al Federației Ruse, SNiP, SN, GOST, VSN etc.). Rezultatul controlului este "corespunde" sau "nu corespunde" deciziei de proiectare cu documentele de reglementare specificate.
Evaluare - aceeași procedură de control, numai în apendicele la "corespunde" sau "nu corespunde" indică cât de mult "corespunde" sau "nu corespunde". De regulă, rezultatul evaluării este dat în termeni cantitativi, de exemplu, pauza de incendiu dintre clădiri este cu 10 metri mai mică decât cea standard.
Așa-numitul control normativ este în același rând ca și controlul, singura diferență fiind aceea că SPDS GOSTs sunt folosite pentru a compara soluția de proiectare adoptată cu documentele de reglementare.
Verificarea implică compararea deciziei de proiectare cu datele de proiectare de intrare (atribuirea proiectului, datele de proiectare inițială, specificațiile tehnice). GOST ISO 9001-2011 stabilește foarte clar cerințele pentru verificarea soluțiilor de proiectare, inclusiv planificarea verificării și înregistrarea rezultatelor. În special, articolul 7.3.5 prevede că "în conformitate cu activitățile planificate, ar trebui să se efectueze un control pentru a se asigura că producția de proiectare și dezvoltare respectă cerințele de intrare pentru proiectare și dezvoltare. Trebuie păstrate și păstrate înregistrările rezultatelor testelor și toate acțiunile necesare. " Deoarece "datele de intrare", de regulă, conțin indicatori tehnici și economici (cerințe) pentru documentația proiectului, ISU verifică conformitatea datelor primite efectiv.
Analiza - o acțiune colectivă sub conducerea GIP - vă permite să prezicați consecințele imutabilității procesului de proiectare existent în ceea ce privește caracteristicile tehnice și economice ale deciziilor de proiectare, costul designului și durata acestuia. În clauza 7.3.4 din GOST ISO 9001-2011, precum și pentru verificare sunt prezentate cerințele pentru analiză, și anume: "În etapele corespunzătoare, în conformitate cu activitățile planificate, ar trebui să se realizeze analize sistematice de proiectare și dezvoltare pentru a evalua capacitatea rezultatelor de proiectare și dezvoltare îndeplinesc cerințele, precum și identifică orice [probleme apărute în timpul proiectării și dezvoltării] și propun acțiunile necesare. Participanții la astfel de analize ar trebui să includă reprezentanți ai funcțiilor legate de etapa de proiectare și dezvoltare analizată. Se păstrează și se păstrează înregistrările rezultatelor analizei și toate acțiunile necesare. " Rețineți că analiza trebuie planificată și rezultatele acesteia trebuie documentate. Este, de asemenea, evident că analiza nu poate fi efectuată la începutul proiectului, deoarece nu există încă nimic de analizat și la sfârșitul proiectului, deoarece "trenul a plecat deja" și procesul este complet. În proiectarea, responsabilitatea pentru analiză revine ISU. De regulă, în timpul procesului de proiectare, UIP reunește șefi de departamente de producție și specialiști șefi în secțiunile de proiect și discută cu aceștia cursul de proiectare și caracteristicile tehnice și economice ale deciziilor de proiectare făcute pentru a se asigura că materialele de proiectare rezultate la sfârșitul proiectului corespund "datelor de intrare".
Coordonarea presupune încrederea că această soluție de proiectare nu contravine deciziilor de proiectare din alte secțiuni ale proiectului, adică, de exemplu, soluția de proiectare a secțiunii de proiectare a proiectului este comparată cu soluțiile de proiectare ale secțiunilor de proiectare electrică, sanitară sau termică.
Responsabilitatea pentru coordonarea care trebuie efectuată este responsabilitatea ISU, iar pentru corectitudinea coordonării sunt responsabili principalii specialiști pentru secțiile de proiect.
Amintiți-vă ce este "validarea". În proiectare, sunt posibile două situații de confirmare: în primul caz, acest lucru se poate face direct "pe hârtie", adică soluția de proiectare se află pe ecranul calculatorului. De exemplu, decizia de proiectare este un fascicul proiectat și construit care trebuie să reziste la sarcina corespunzătoare. Pentru a confirma conformitatea, este suficient să se utilizeze aceeași metodă de calcul care a fost utilizată la luarea acestei decizii (sau alternativă) și dacă această metodă este testată și fiabilă, atunci recalcularea va da încredere absolută în corectitudinea deciziei de proiectare. Sau alt exemplu, în atribuirea proiectării, este indicată compoziția clădirilor de pe podeaua corespunzătoare a clădirii și sunt indicate zonele solicitate. Soluția de proiectare a acestui plan etaj este ușor de verificat prin compararea cu datele originale. Ar trebui să se sublinieze faptul că astfel de decizii de proiectare în suma totală de proiectare - cel puțin 80-90 la sută. Acestea includ deciziile de proiectare realizate folosind modele standard, ansambluri și piese tipice, soluții individuale aprobate inițial dezvoltate, utilizate în mod repetat, cataloage de echipamente care sunt certificate în modul prescris, etc., etc. Cu alte cuvinte, vorbirea Este vorba despre soluții de design fiabile, dovedite, de multe ori aplicate, fără îndoială.
A doua situație este atunci când soluția de proiectare nu poate fi verificată în mod fiabil utilizând tehnicile tradiționale de verificare. Acestea pot fi verificate numai în procesul de construcție sau exploatare a instalației construite, precum și efectuarea de teste speciale în condiții cât mai apropiate de construcția sau funcționarea instalației. O astfel de nevoie apare atunci când se aplică tehnologiile avansate sau materialele deja recomandate sau anunțate în anunțuri, metode noi de calcul, echipamente care nu au fost folosite niciodată, soluții tehnologice care nu au analogi etc. De exemplu, la expoziție, designerii s-au familiarizat cu materiale noi de acoperiș care este publicată în mod activ, iar caracteristicile acestui material sunt impresionante.
Se poate decide folosirea acestui material pentru un acoperiș cu o suprafață de 20 mii de metri pătrați, totuși se stipulează în mod specific că în timpul construcției trebuie mai întâi să finalizați o secțiune de acoperiș de 10 metri pătrați, să creați o sarcină dinamică asupra acestuia pentru o anumită perioadă de timp, cum se comportă suprafața inferioară a acoperișului. Dacă rezultatul testului este pozitiv, atunci designerii vor da permisiunea de a face restul acoperișului. Uneori această nevoie apare din cauza incertitudinii ridicate a condițiilor geologice din zonele dificile de construcție, atunci când prospectorii nu pot (inclusiv din motive economice) să acopere cu suficientă precizie caracteristicile solului în locații specifice ale fundațiilor de fundație. În aceste cazuri, ele indică necesitatea de a conduce piloni de testare și numai după aceea confirmă posibilitatea construirii unui câmp de piloți sub întregul obiect.
Aceasta este validarea soluției de proiectare. Utilizarea validării demonstrează angajamentul organizației de proiect pentru tot ceea ce este nou și avansat. Acesta este un semn al competitivității soluțiilor de design, este dorința de a ocupa o poziție de lider în design datorită creșterii continue a satisfacției clienților. Responsabilitatea pentru efectuarea validării este suportată de ISU, pentru conținutul validării - principalii experți pe secțiunile proiectului.
Aprobarea este permisiunea de transferare a documentației complete a proiectului către un client. Aceasta este responsabilitatea GUI și îl implementează atunci când semnează factura înainte de a trimite documentația clientului.
Acum ne îndreptăm spre responsabilitatea ISU, asociată cu o reducere a costului lucrărilor de proiectare. După cum știți, există multe oportunități de reducere a costurilor, iar aceasta este o "durere de cap" pentru conducere și pentru toți specialiștii de software de top, deoarece acesta este practic singurul mod de a crește profiturile organizației de proiect. GUI are o contribuție semnificativă la acest lucru, realizând responsabilitatea pentru gestionarea (subcontractării) sub-designerilor.
În prezent, a fost posibilă alegerea sub-designerilor (STRs) pe baza rezultatelor evaluării, comparării cu concurenții, reevaluării regulate și responsabilității GUI pentru această alegere. Un principiu important, "cine plătește, comandă muzică", a început să lucreze între subiecți, nu numai în sensul tradițional cunoscut, ci și ca o cerință a designerului general (GP) să se gândească constant la îmbunătățirea (asigurarea) calității și reducerea costului lucrărilor de proiectare. În plus, Legea stabilește că responsabilitatea față de client pentru calitatea documentației de proiectare și estimare, elaborată de ACT, este suportată numai de GP. Prin urmare, este necesar să se țină cont de cerințele GOST ISO 9001-2011 și de Ghidul de aplicare a proceselor de outsourcing (ISO / TS 176 / SC 2 / N 630R2, 24 noiembrie 2003).
În general, există trei tipuri condiționale de STR:
- "Ordinar" - SPO cu care GP are relații normale de piață;
- "Ordinar" - SPO cu care GP are relații normale de piață;
- "Henchmen" - creatura clientului, relația dintre GP și clientul pe care îl determină clientul.
Folosind exemplul relațiilor cu software-ul open source, vom lua în considerare fiecare subsistem secvențial, având în vedere faptul că ISU în unele cazuri ia decizii, iar în altele participă la adoptarea lor.
Evaluarea, selecția și reevaluarea sub-designerilor.
Acest subsistem constă din două blocuri:
- formarea și întreținerea listei (baza de date, registru, etc.) a STR-urilor aprobate și actualizarea acestora;
- selectarea software-ului open source din lista specificată pentru a efectua lucrul la un anumit proiect.
Lucrul în cadrul primei unități este funcția departamentului tehnic al software-ului, iar în al doilea rând, responsabilitatea ISU.
Pentru a forma lista, departamentul tehnic al software-ului caută, evaluează, selectează și reevaluă software-ul open source în conformitate cu nevoile software-ului, utilizând criteriile dezvoltate împreună cu GUI-urile.
Este clar că o astfel de abordare nu garantează faptul că STR este în deplină conformitate cu așteptările medicului de familie datorită complexității formalizării anumitor probleme. De exemplu, o întrebare privind disponibilitatea unui QMS valabil și conformitatea acestuia cu cerințele GOST ISO 9001-2011. ACT răspunde că sistemul de management al calității funcționează și respectă, după cum reiese din certificatul organismului de certificare "N". Experiența în evaluarea îndeplinirii anumitor cerințe ale GOST ISO 9001-2011 de către organizațiile de autoreglementare ale designerilor indică faptul că peste 90% din certificate sunt primite oficial, pur și simplu "cumpărate" și adesea nu au nici o legătură cu un anumit STR. Se dovedește că GP are responsabilitatea reală pentru calitatea documentației proiectului (de lucru) elaborată de ACT, dar alegerea ACT se bazează pe "asigurările" STR însuși sub forma răspunsurilor la chestionar. La proiectarea unui obiect specific, GUI selectează, de regulă, ACT corespunzător din listă, ghidat de criterii suplimentare, inclusiv locația teritorială a STR, informațiile din STR privind proprietățile unui anumit șantier de construcție, contactele anterioare cu un anumit client, pregătirea ACT pentru a îndeplini ordinea și altele.
Înainte de a lua o decizie cu privire la implicarea software-ului open source în proiectarea GUI ar trebui să fie direct în organizație. Aceasta este o nouă datorie GUI. Această tehnologie este prevăzută de standardele seriei ISO 9000 și se numește auditul "al doilea". Durata auditului de către partea a doua nu este mai mare de o zi lucrătoare (de preferință 3-4 ore).
O astfel de durată scurtă se explică prin faptul că nu este luat în considerare întregul sistem de management al calității software-ului cu sursă deschisă, ci doar anumite puncte-cheie. Practica arată că, dacă la aceste puncte totul este normal, atunci cu un grad ridicat de probabilitate, ACT corespunde așteptărilor SE.
Este necesar să subliniem faptul că clientul se ocupă numai de medicul de familie, cu care are un contract. Poate că nu știe ceilalți participanți la proiect. În consecință, relația cu software-ul open source este exclusiv o problemă a GP. SPO de fapt acționează ca o unitate structurală suplimentară a medicului generalist, pe care ar trebui să o gestioneze în procesul de implementare a proiectului în același mod ca și cu diviziile sale "proprii", având în vedere termenele limită și calitatea documentației de proiect elaborate de ACT, pentru care GP este responsabil de către client. Aceasta determină responsabilitățile întreprinderilor de stat în gestionarea STR.
Tipul și domeniul de aplicare al gestionării software-ului open-source pot varia într-o gamă largă: de la minim, atunci când software-ul open source este emis o sarcină tehnică și munca acceptată este acceptată cu puțin sau deloc verificare maximă. În același timp, se efectuează o verificare completă a STR, PSD completate, inclusiv cu ajutorul experților independenți.
Suma necesară de gestionare este determinată de ISU în funcție de rezultatele evaluării (reevaluării) STR, inclusiv luând în considerare informațiile obținute în timpul auditului de către partea terță și, de asemenea, în funcție de costurile planificate pentru RP să efectueze inspecția viitoare a materialelor STR, având în vedere că aceste costuri măresc costul lucrărilor pentru proiect.
Caracteristicile de management ale SPO ar trebui stabilite de GUI în "condițiile speciale" ale acordului de subcontractare. Departamentul tehnic al GP dezvoltă un model de astfel de "condiții speciale" în care sunt prezentate practic toate aspectele posibile și / sau necesare ale managementului open source, iar GUI, atunci când analizează un contract specific cu software open source, include acele metode de gestionare care întrunesc condițiile unui anumit proiect. Cu cât este mai mare gradul de control al software-ului open source, cu atât este mai mic volumul controlului de intrare al materialelor de design de software open source și, în consecință, costul GP.
Astfel de metode de control pot include necesitatea:
- aprobarea procesului de proiectare tehnologică utilizat de software-ul open source sau executarea lucrărilor de proiectare utilizând procesul de proiectare tehnică utilizat de directorul general;
- coordonarea programului de lucru privind proiectarea pe care STR ar trebui să-l dezvolte pe baza programului de lucru atașat contractului;
- numiri (în acord cu întreprinderea de stat) ale unui anumit manager de proiect (manager de proiect) pentru ordinul depus pentru execuție (secțiunea de proiect) etc.
În funcție de gradul de control al software-ului open source, volumul de control al intrărilor pentru un GP poate varia de la 100% la aproape nici unul, adică o recalculare formală a documentelor de proiect primite de la software-ul open source.
După transferarea documentației de proiectare și estimare completă către Client sau după punerea în funcțiune a obiectului (în cazul în care a fost efectuată supravegherea autorului), ISU trebuie să finalizeze proiectul de externalizare.
Pentru aceasta aveți nevoie de:
- verificați disponibilitatea documentelor care confirmă primirea documentației de proiectare și estimare din ACT, inclusiv verificarea calității documentației specificate;
- să evalueze cooperarea cu ACT și să raporteze rezultatele departamentului tehnic pentru a ajusta lista;
- obțineți de la ACT și transferați la arhiva GP informațiile despre soluțiile individuale de proiectare eficiente, inclusiv documentația STR, care poate fi recomandată pentru reutilizare;
- pregătiți o revizuire oficială pentru software-ul open source;
- să rezolve problema (dacă este necesar și posibil) cu privire la stimulentele economice pentru software-ul open source.
Acum, despre responsabilitatea GUI, care este asociată cu participarea la formarea "cărții de comandă" și costurile reduse ale software-ului pentru găsirea de noi clienți.
Ideea este că, conform clauzei 7.2.1 "Procesele asociate consumatorilor" GOST ISO 9001-2011, software-ul trebuie să definească cerințele:
1. Înființată de client, inclusiv cerințele pentru livrare și activitățile după livrare.
2. Nu este specificat de client, dar este necesar pentru utilizarea specifică sau intenționată a DED atunci când este cunoscută.
3. Legislativ și alte obligatorii referitoare la DED.
4. orice software suplimentar, specific.
Ceea ce se înțelege prin primele trei grupe de cerințe (1-3) este mai mult sau mai puțin clar. Mai clarificăm faptul că "cerințele care nu sunt precizate de client, dar care sunt necesare pentru utilizarea specifică sau intenționată a DED, dacă sunt cunoscute", pot include toate cerințele software-ului însuși, pe care depind calitatea, prețul și timpul de livrare al documentației proiectului.
De exemplu, dacă un client primește estimări de proiectare care, în conformitate cu tehnologia de proiectare existentă, sunt stocate pentru o anumită perioadă de timp înainte de a fi transferate clientului într-o arhivă tehnică, cerințele software-ului însuși privind condițiile de depozitare din arhiva documentației specificate vor fi menționate în clauza 7.2.1 (2). Îndeplinind cerințele specificate în clauza 7.2.1 (1-3) din standard, software-ul nu poate obține avantaje competitive, deoarece toți concurenții trebuie să îndeplinească aceste cerințe. În condițiile pieței, numai software-ul care "supraviețuiește" poate determina și îndeplini cerințele clauzei 7.2.1 (4). Am numit aceste cerințe "asumate" și le-am clarificat înțelesul: mai întâi, acestea sunt "ghicite", software-ul însuși este formulat; în al doilea rând, acestea nu sunt aprobate sau convenite cu clientul și, în al treilea rând, implementarea lor se desfășoară pe cheltuiala proprie software-ul. În consecință, clientul primește documentația de proiect (servicii) cu parametri neașteptate pentru el sau cu parametri mai buni decât se aștepta, ceea ce garantează nu numai satisfacția clienților, ci și admirația pentru serviciul oferit. În ultimul caz, software-ul poate fi sigur că clientul se va întoarce la acesta în mod repetat. Și pentru a păstra clientul, după cum știți, este de 5-7 ori mai ieftin decât căutarea unui nou. Aceasta este esența unei poziții fundamentale noi, stabilită în GOST ISO 9001-2011.
Pentru a îndeplini cerința specificată în clauza 7.2.1 (4) a standardului, pentru a influența avantajele competitive ale software-ului, este necesar să se determine proprietarul procesului de a forma cerințele intenționate ale clienților, și anume unul dintre managerii care stabili regulile pentru implementarea acestei activități. Pentru software, cel mai probabil proprietarul procesului ar trebui să fie inginerul șef al institutului. "Stăpânul" procesului, adică specialistul care formulează cerințele clientului potențial pentru un anumit proiect, ar trebui să fie un GUI. Pentru a clarifica, ISU este responsabil pentru faptul că cerințele intenționate ale clientului sunt definite, iar principalii specialiști ai departamentelor de producție sunt responsabili pentru conținutul acestor cerințe.
O altă responsabilitate a UIP se formează în analiza contractului (acordului) cu clientul. Apelul clientului în software poate fi în diferite moduri: informații despre licitația câștigată (concurs); o scrisoare oficială cu o propunere de elaborare a documentației de proiect; apel telefonic către șeful de software; comunicarea informală prin intermediul colegilor etc. În momentul primirii unuia dintre semnalele de mai sus, este recomandat să desemnați un GUI care să gestioneze analiza contractului înainte de semnarea de către client.
Această taxă ISU implică:
- determinarea cercului de persoane care vor participa la coordonarea proiectului de contract și repartizarea responsabilității între acestea;
- introducerea managerilor și a specialiștilor specificați pentru a conduce negocierile cu clientul (întâlniri de lucru) pentru a discuta anumite prevederi ale proiectului de contract, inclusiv negocierile privind stabilirea prețului contractului;
- în selectarea din baza de date a șabloanelor a unei opțiuni adecvate pentru un anumit client și obiect de proiectare;
- determinarea necesității și a posibilității de a atrage sub-proiectanți și de a organiza negocieri preliminare cu acestea;
- evaluarea riscurilor care pot fi asociate cu îndeplinirea obligațiilor care îi revin în temeiul contractului.
Fiecare dintre aceste acțiuni în condițiile de astăzi diferă semnificativ de practica pe care o cunoaștem. De exemplu, acordul privind un proiect de acord este, de obicei, redactat pe "Lista aprobărilor", unde sunt indicate numele complet și funcția managerului respectiv, care, dacă este aprobat pozitiv, semnează negativ - îi dau scrisă în scris. În opinia noastră, este necesar să se stabilească responsabilitatea șefului pentru elementele relevante ale proiectului de contract. Suma punctelor din "Lista aprobărilor" trebuie să fie egală cu suma punctelor din proiectul de contract. Aceasta asigură responsabilitatea personală a fiecărui manager pentru îndeplinirea condițiilor contractului de către organizația de proiect și înțelegerea egală a termenilor relevanți ai proiectului de contract de către organizația de proiect și de către client etc.
Materialul acestui articol cu unii designeri poate provoca obiecții. Suntem pregătiți pentru o discuție constructivă cu colegii într-o formă convenabilă.