Sobre la composición de las secciones documentación del proyecto de acuerdo con las normas de la Federación Rusa y los requisitos específicos para el registro, consulte la Resolución 87. Muchos están interesados en la legislación actual y sus explicaciones para esta resolución, por lo que debe averiguar qué novedades apareció en esta ley para este año y cuál es el lista de sus requisitos parece.
sobre la composición de la documentación del proyecto
Al redactar esta disposición, el gobierno se refirió a la planificación urbana y sus código ruso. Según el art. 48 de este código, se estableció el contenido de la documentación. Los principales requisitos comenzaron a ser presentados por el Ministerio, bajo cuya competencia se encuentra la construcción, así como el servicio de seguridad de la Federación. Asimismo, la Federación puede recibir recomendaciones sobre la preparación de documentos a través de la autoridad estatal de transporte. Se puede hacer un requisito adicional a pedido de muchos otros servicios. La primera edición y las aclaraciones debían entrar en vigor en febrero de 2008. Luego, a fines de febrero, se le dio una designación a cada aspecto de los requisitos.
Modificaciones a la Ley Federal sobre la composición de la documentación del proyecto.
El Decreto del Gobierno de la Federación Rusa sobre la composición de la documentación del proyecto con fecha 16 de febrero de 2008 87 con cambios tuvo que ser aprobado en enero de 2016. Previo a esto, más de un tramo, por decisión del gobierno, fue cambiado en abril ya fines de abril, en diciembre, marzo, agosto, julio, mayo y junio de años pasados. Ultima revision por decisión del Pleno, recibió una pequeña adición, y se introducirá algún párrafo en una nueva redacción. Hoy puedes leer la editorial gratis. con fecha 2016 a través de su computadora o descargue el plan de posiciones.
Posición Federación Rusa sobre la composición de la documentación del proyecto con cambios contiene las siguientes secciones:
- Disposiciones básicas;
- La composición del proyecto para el proceso de construcción lineal;
- La composición de las secciones sobre el proceso de construcción de producción y no producción de capital.
Comentarios sobre la Resolución 87
Los comentarios recientes sobre la documentación de planificación de esta ley dejan en claro la relevancia de las nuevas disposiciones. Por ejemplo, la ley federal tiene una lista de requisitos para la etapa de trabajo del diseño. En relación con los comentarios, se puede comprender con mayor precisión qué hacer si se cumple la condición de una publicación específica en la ley, cómo funciona el poder de este decreto y cómo el sistema lleva a cabo la supervisión tecnológica.
Juramento del GIP según la resolución 87
Esta disposición de la Federación Rusa no regula el juramento del GIP, aunque debe haber su nota o una entrada al proyecto. Siempre debe haber certificación, sello y firma de la DAA. Esto le permite proporcionar información de que el esquema del proyecto está escrito de acuerdo con los requisitos y el desarrollo está certificado oficialmente.
Lista de secciones de la documentación del proyecto según la Ley Federal 87
Dependiendo de la construcción para la que se requiera aplicar esta disposición, la muestra y la puesta en escena de la compilación cambian. En total, la adición a la ley contiene dos tipos de construcción: objetos lineales y construcción de capital. Vale la pena clasificar un objeto y aplicarle reglas de diseño de texto y gráfico. La ayuda sobre este tema está en desuso por muchos portales legales, como un experto técnico, consultor o consultantplus. Esto sugiere que hoy en día el orden de redacción de los proyectos es interesante para más de una organización. Vale la pena comprobar el estado de parcela, edificios y estructuras de acuerdo con esta ley, y luego seguirla por escrito.
Nota explicativa general sobre el Decreto 87
Según el texto de la disposición, se sustancia la nota explicativa general y su desarrollo. El proyecto deberá contener los volúmenes y secciones que se describen en la resolución. Por ejemplo, se debe indicar una estimación, el suministro de electricidad, los códigos importantes, la disponibilidad de la red, el aspecto ambiental del proyecto, la seguridad y la experiencia, la eficiencia energética, etc. Además, el proyecto en sí mismo debe actuar como garante del correcto desarrollo, por ejemplo, es importante preservar el medio ambiente si se trata de un documento para una planta nuclear o un lavado de autos en Moscú. Si se bloquea un nodo público importante, o si es necesario eliminar una parte de la infraestructura, se deben adjuntar los permisos. A documento terminado se puede utilizar encuadernación o plegado, y también se pone la fecha de aceptación.
Publicado el 01/04/2015
M. S. Podolsky, Presidente del Subcomité sobre la organización de las actividades de los Ingenieros Jefes de Proyectos del Comité para el Diseño Tecnológico de Instalaciones Industriales de la Asociación Nacional de Diseñadores y Agrimensores, Asesor científico Escuela Internacional Chief Engineers (Chief Architects) de proyectos en MGSU
A. V. Litvinov, Diputado Director general Centro de consultoría "TsNIO-project", miembro del Consejo de la Escuela Internacional de Ingenieros Jefes (Arquitectos Jefes) de proyectos en la Universidad Estatal de Ingeniería Civil de Moscú
EN condiciones modernas gestión, el cliente tiene la oportunidad de elegir una organización de diseño (software) de acuerdo con la relación óptima de plazos, precios y calidad de los servicios ofrecidos. Con la aparente igualdad de los criterios anteriores, es la calidad de la documentación del proyecto la que puede convertirse en una condición decisiva para el éxito del software en competencia. La calidad de la documentación del proyecto se evalúa tanto por parámetros objetivos: cumplimiento de los requisitos de las normas y reglas existentes, como subjetivos: máxima satisfacción de los requisitos del cliente. Tanto esos como otros parámetros están cambiando constantemente: los clientes están pasando del diseño estándar a cambios mensuales individuales y adiciones a los reglamentos y a las normas técnicas y Marco legislativo, nuevo Materiales de construcción, nuevos equipos, tecnologías, etc. El cliente habitual “satisfecho” o “no satisfecho” con la documentación del proyecto se complementa con la necesidad de mejorar constantemente la satisfacción del cliente, y esto está incrustado en la ideología de las normas internacionales de la serie ISO 9000.
Para proveer calidad requerida productos, el software debe, si no seguir el ritmo de progreso cientifico y tecnologico, al menos mantenerse al día, ofreciendo al cliente soluciones de diseño nuevas, originales y fiables.
¿Qué impide la mejora real del trabajo de los Chief Engineers (Chief Architects) de proyectos (CEOs)? En nuestra opinión, en primer lugar, los erróneos estereotipos predominantes sobre el lugar y el papel de la GUI en el proceso de diseño, que se transmiten de generación en generación de diseñadores, y en segundo lugar, la insuficiente cualificación de los gestores de software en cuestiones relacionadas con las actividades de GUI, lo que no les permite tomar decisiones adecuadas, en tercer lugar, la falta de una idea clara de en qué consiste la calidad de la solución de diseño y de qué parte de ella es responsable la GUI, en cuarto lugar, una comprensión simplificada de la mecanismo de formación de calidad, incluso cuando es implementado por subdiseñadores, y finalmente, en quinto lugar, porque la mayoría de los diseñadores aún no se dan cuenta de la importancia del papel de la GUI en la reducción de costos trabajo de diseño.
Sería un error pensar que los administradores de software y las propias GUI no quieren abordar las causas anteriores, pero sus intentos no arrojan resultados notables, porque en lugar de confiar en hechos que dictan claramente las decisiones correctas, se guían por experiencias pasadas y opiniones subjetivas que no se ajustan a las exigencias de los tiempos.
En el proceso de discutir estos temas, a menudo nos encontramos en lados opuestos de la barricada con muchos de nuestros colegas, con una especie de "oponente colectivo", cuyas opiniones se formaron históricamente y que aún vive en la realidad económica pasada. Este artículo es una objeción adicional al "opositor colectivo".
Como es sabido, administración moderna recomienda documentando regulaciones importantes, pero la aparición de cualquier regulación debe estar precedida por la formación de principios que establezcan, por ejemplo, “a lo largo o al otro lado del río” se construirá un puente. Esta es la parte más importante de la elaboración de normas. En esta etapa, se debe alcanzar un consenso en la comunidad profesional, luego de lo cual cualquier restricción regulatoria no debe contradecir los principios acordados.
Desafortunadamente, en realidad triunfan los “malos estereotipos”, que en la mayoría de los casos nada tienen que ver no solo con la ciencia de organizar y administrar la producción, sino muchas veces simplemente con el sentido común.
Detengámonos en algunas, en nuestra opinión, ideas erróneas, deshacerse de las cuales es una reserva real en el desarrollo del negocio del diseño:
1. La GUI es responsable de la calidad de la documentación de diseño (funcionamiento), es decir, la GUI es responsable de todo.
Eso es imposible. Los requisitos de trabajo o, como se dice hoy, la "responsabilidad y autoridad" de la GUI se ha correlacionado históricamente con la complejidad de los requisitos para los objetos de diseño, así como con los cambios en las expectativas del cliente con respecto a los resultados del diseño. En el pasado, el diseño y la construcción estaban a cargo de un especialista que tomaba todas las decisiones. En la actualidad, la tarea principal de la GUI es proporcionar la dinámica necesaria de inversiones, así como ingresos al cliente de la implementación del proyecto, suficientes para compensar a los inversores por los recursos que han invertido y el riesgo que han tomado. Así, todas las decisiones en el diseño de la GUI se toman según el criterio eficiencia económica diseño, construcción y operación de la instalación. De ahí los requisitos para sus calificaciones. Todos los demás participantes en el proceso de diseño toman decisiones de acuerdo con el criterio de optimización técnica, y esta condición se realiza en el proceso de coordinación de decisiones de diseño por parte de los principales especialistas en las secciones del proyecto.
2. El "juramento" de la GUI libera al resto de los participantes del diseño de la responsabilidad por la calidad de la documentación del diseño (de trabajo).
En otras palabras, el GIP es responsable del cumplimiento de las normas y estándares para el diseño, construcción y operación de las instalaciones, los estándares de los organismos autorreguladores, los requisitos individuales de los clientes en cuanto al nivel técnico y la calidad, la expresividad arquitectónica y la importancia social de las instalaciones. en el proyecto. Consideramos necesario volver a los significados: responsabilidad de qué y en qué casos.
Obviamente, la responsabilidad puede surgir si se revela un resultado negativo del trabajo que el especialista realizó personalmente o lo comprobó personalmente; si hay una firma adecuada, respaldada por la fecha, y también documentada, de qué y ante quién se responde y cuándo termina. Este condiciones obligatorias por responsabilidad personal. De lo contrario, triunfa la irresponsabilidad colectiva. Tomemos un ejemplo. Como saben, los dibujos deben estar firmados: "desarrollado", "controlado" y "control estándar". Prestemos atención al hecho de que las firmas se dan en términos de acciones, es decir, responden a la pregunta: ¿qué hiciste? - desarrollado; ¿Qué hiciste? - control normativo realizado, etc. No debemos permitir "actividades de aficionados" de las organizaciones de diseño y la aparición en los dibujos de firmas de jefes de departamento, especialistas en jefe, ingenieros de proyectos en jefe, etc. Los acentos están cambiando y las firmas comienzan a determinar no " qué hizo", sino "quién hizo".
Como ya se mencionó, la firma representa responsabilidad. Sin firma, sin responsabilidad. Como la responsabilidad tiene límites, es necesario ponerse de acuerdo a dónde van, es decir, asegurarse de que todos entiendan el área de responsabilidad de la misma manera. El significado del contrato es el siguiente: cada dibujo tiene contenido (se muestra “qué”) y diseño (se muestra “cómo”). El contratista es responsable del contenido y diseño. Por el contenido - ante el inspector, por el diseño - ante el controlador normativo. La responsabilidad del contratista cesa en el momento en que el inspector y el controlador normativo ponen sus firmas. A continuación, es necesario determinar ante quién es responsable el inspector y el controlador normativo. Idealmente, debería ser un cliente que esté realmente interesado en hacer coincidir la firma y el resultado. En el organización de diseño es imposible encontrar a los que siguen al inspector y al controlador normativo. Pero, ¿podría ser la GUI? En este caso, la firma del GUI significará que una vez más verificó el contenido y el diseño del dibujo y asumió la responsabilidad, incluso por "la observancia en el proyecto de normas y estándares para el diseño, construcción y operación de instalaciones ... ”, etc. y etc. Pero es físicamente imposible para la GUI verificar que todas las soluciones de diseño cumplan con todos los estándares y todos los requisitos. Por lo tanto, responsabilizar al GUI de todo en general no es más que un hechizo, formal por la imposibilidad de cumplimiento y peligroso, si es necesario, para castigar la culpa ajena. La ISU es solo uno de los muchos autores de una obra de teatro llamada "Documentación del proyecto".
3. Si sucede algo grave en el sitio de construcción, el GUI será el primero en ser "encarcelado".
Si sucede algo realmente grave, entonces el investigador, después de haber designado un examen técnico forense o después de realizar varios exámenes de este tipo, determinará el diseñador que, por ejemplo, realizó el cálculo de la estructura y aplicó el coeficiente incorrecto, luego determina quién verificó el cómputo y es éste quien presentará acusación, pero el tribunal en determinadas circunstancias podrá sancionar al ejecutante y al inspector.
4. El GUI debe ser el diseñador más calificado en todas las áreas del proyecto.
Está claro que esto simplemente no puede ser, porque la documentación del proyecto contiene al menos diez secciones especializadas, cuyo trabajo implica la presencia de más de veinte especialidades. Este “mal estereotipo” se extiende también a la idea de nombrar a un especialista para el puesto de CEO. Sin embargo, es recomendable tomar una decisión sobre el nombramiento de un Consejero Delegado sobre la base de una selección competitiva y guiarse por criterios completamente diferentes.
El postulante para el puesto de Ingeniero Jefe debe fundamentar por parte del postulante la posibilidad de lograr mayores indicadores técnicos y económicos de la instalación proyectada, reduciendo el tiempo inicial de diseño y construcción, reduciendo la intensidad de mano de obra (costo) del trabajo de diseño, más favorable para las condiciones de organización del diseño para asentamientos con participantes en el trabajo, así como la ampliación de la composición requerimientos adicionales cliente por el objeto de diseño (7.2.1 "d" GOST R ISO 9001-2008), etc. La reputación de la GUI es de particular importancia: carácter, sociabilidad, diligencia, compromiso, eficiencia, puntualidad, decencia, capacidad de negociación, atención, cortesía, capacidad de respuesta, desempeño, etc.
Para objetos civiles, una ventaja en el nombramiento para el cargo de Arquitecto Jefe de Proyecto (GAP) puede ser la presencia de una educación económica y arquitectónica. La segunda prioridad es la educación económica, la tercera es la arquitectura y, finalmente, solo la ingeniería.
Para instalaciones industriales(diseño tecnológico) una ventaja en el nombramiento para el cargo de Ingeniero Jefe de Proyectos (CIP) puede ser la presencia de una educación económica y tecnológica correspondiente a las especificaciones del objeto de diseño. La segunda prioridad es la educación económica, la tercera es la tecnológica y, finalmente, solo la ingeniería.
Tanto en el primer como en el segundo caso, la UIP (GAP) debe tener una calificación en gestión de proyectos. Con base en los resultados de la selección competitiva, el director ejecutivo es designado para el puesto por orden pertinente del jefe del software.
5. Si hay desacuerdos entre los principales especialistas sobre las secciones del proyecto, la ISU toma la decisión final.
Imagine la siguiente imagen: El especialista jefe, un electricista en su sección del proyecto, decidió que el tablero de distribución estaría entre tal y tal eje y en tal y tal marca del edificio. El especialista jefe: un ingeniero de calefacción ubicó un punto de calefacción en el mismo lugar. Vienen a la GUI para "reconciliarlos". Naturalmente, la calificación de cada uno de los Jefes Especialistas en la especialidad correspondiente es superior a la del Director General. Si la ISU discutirá este tema con ellos en el área técnica propuesta, obviamente estará en desventaja. Debería traducir la discusión a un plano económico, diciendo que una opción cuesta tanto y la otra cuesta tanto, teniendo en cuenta no solo los costos de construcción, sino también los costos de operación, así como posible riesgo asociados con cambios en el costo del equipo. Al tomar y justificar su decisión desde un punto de vista económico, la GUI, que es responsable de esta decisión ante el inversor, debe buscar una solución técnica adecuada de especialistas. Hoy en día, pocas GUI pueden actuar así, pero esta es la misión de la GUI, es parte de la responsabilidad por la calidad de las soluciones de diseño.
6. La IGU debe tener, en primer lugar, una especialidad técnica.
Ya hemos hablado de qué especialidad y por qué debe tener el GIP. En las condiciones de ritmo acelerado del desarrollo científico y tecnológico, la calidad de la documentación del proyecto depende directamente de la mejora sistemática de las habilidades de los directores ejecutivos. Hoy en día, el director general debe ser competente en la organización y gestión del proceso de diseño, métodos para garantizar la eficiencia económica del diseño, construcción y operación de la instalación para obtener su posición sobre una base competitiva. Pero incluso los directores ejecutivos exitosos sienten la falta de conocimiento sobre estos temas, tratando de compensar de forma independiente las brechas en sus competencias.
Para resolver estos problemas, a iniciativa del Comité para el Diseño Tecnológico de Instalaciones Industriales de NOPRIZ y el Instituto de Construcción y Arquitectura (ISA) de la Universidad Nacional de Investigación de Ingeniería Civil del Estado de Moscú (MGSU), con la participación de la TsNIO- Centro de Consultoría del proyecto y el Comité de Continuidad educación profesional en la industria de la construcción, la Unión Rusa de Constructores (RCC) organizó la Escuela Internacional de Ingenieros Jefes (Arquitectos Jefes) de proyectos. El Consejo Escolar incluyó a reconocidos especialistas en la Federación Rusa y los países de la CEI en el campo del diseño y la garantía de calidad de la documentación de diseño (de trabajo). Presidente de la Junta de la Escuela Internacional de Ingenieros en Jefe (Arquitectos en Jefe) de Projects Meshcherin Igor Viktorovich tiene una experiencia única de trabajo como Arquitecto en Jefe y Arquitecto en Jefe en la URSS, Rusia, EE. UU. e Italia.
La información sobre la Escuela Internacional de GUI (GAS), incluida la realización de cursos específicos, se publica en los sitios web de ISA MGSU, la Asociación Nacional de Diseñadores y Agrimensores, el proyecto TsNIO, así como en los sitios web de Projectant en el Federación de Rusia, Kazajstán, Bielorrusia y Ucrania.
El objetivo principal de la Escuela Internacional de GUI es poner yo m formación avanzada para garantizar la formación de personal altamente profesional de los directores ejecutivos. Programas que cumplen con los requisitos modernos, la orientación práctica de los cursos le permite satisfacer las necesidades de diseño tecnológico y arquitectónico, mantener un continuo crecimiento profesional y reproducción de GUI, así como para preparar por orden de las organizaciones de diseño reserva de personal para cubrir puestos de directores ejecutivos.
Hay dos productos principales en la "cartera educativa" de la Escuela Internacional de GUI:
El sistema propuesto de reciclaje de GUIs es flexible, adecuado a las necesidades del momento, respondiendo a las necesidades reales de personas extremadamente ocupadas. trabajo practico diseñadores El contenido de los programas equilibra el conocimiento teórico y práctico, así como la experiencia en gestión del diseño. Es muy importante que el programa asuma una amplia cobertura territorial de los estudiantes y la conveniencia de aprender, incluso mediante el uso de principios modernos, formas y métodos de formación: modularidad, formación "al resultado", variabilidad en cuanto a la formación, formación a distancia, etc.
Los principales temas que se tratan en los cursos de la Escuela Internacional de GIPs en MGSU:
1. La situación del mercado de la construcción y su impacto en las actividades del GIP.
2. Los principales cambios en el contenido del concepto de "sistema de gestión de la calidad" en relación con el trabajo de la ISU.
3. Distribución en la organización de diseño (PO) de responsabilidad para el desarrollo de soluciones de diseño y su calidad entre el primer gerente, ingeniero jefe, director de producción, GUI, departamento técnico y departamentos de producción(talleres) en el proceso de preparación, emisión e implementación de documentación (técnica) de diseño en la construcción, incluido el control, verificación, análisis, aprobación, validación y aprobación de diseño y documentación presupuestaria.
4. Aclaración de la función y el lugar de las GUI en el "proceso de extremo a extremo" del software orientado al cliente: "interacción con los clientes de software" - "formación y soporte de una cartera de pedidos de software" - "preparación y emisión/implementación de documentación (de trabajo) del proyecto" - "soporte para la implementación del proyecto en construcción" - "cumplimiento de las obligaciones de garantía para proyectos de software implementados en construcción".
5. El jefe de la unidad de producción: ¿un diseñador o un líder (gerente)? Interacción con GUI. Los principales objetos de gestión del jefe de la unidad de producción: recursos laborales, trabajo, tiempo, finanzas, recursos materiales; subordinación, autoridad responsabilidades funcionales(responsabilidad) del jefe de la unidad de producción, criterios para evaluar sus actividades.
6. El procedimiento para "lanzar" el trabajo sobre la preparación de la documentación del proyecto de acuerdo con el acuerdo general de diseño concluido. contrato de muestra contrato con una organización de diseño subcontratista (SPO); procedimientos de evaluación, selección (selección) y reevaluación de ROS; conceptos de subcontratación y outsourcing.
7. Interacción de la GUI con el departamento de contratos, archivo técnico, departamento de liberación de proyectos. Requisitos básicos para la GUI en el sistema de disciplina ejecutiva.
8. Análisis de las nuevas responsabilidades de la ISU; típico descripción del trabajo interfaz gráfica de usuario; requisitos para la GUI durante la supervisión arquitectónica (incluso por subdiseñadores); GUI y problemas de reequipamiento técnico, expansión de la empresa, modernización, revisión etc.
9. Seguimiento de la satisfacción del cliente con los procesos y resultados de la organización de diseño.
10. El papel de la GUI en la expansión de los tipos de productos (servicios) de la organización de diseño. Formación de la reputación de la ISU entre los participantes del proyecto de inversión.
11. Gestión de subdiseñadores. Requisitos modernos a la selección de los participantes del diseño.
12. Comentarios sobre el borrador de nuevos documentos organizativos y metodológicos para las ISU: Estándar actividad profesional Ingeniero Jefe, Recomendaciones sobre la organización de las actividades del Director General, Perfil del Director General, Requisitos para la preparación y designación para el cargo de Director General, que son desarrollados por el Subcomité de organización de las actividades de los Ingenieros Jefes de Proyectos del Comité de Diseño Tecnológico de Facilidades Productivas del NOP en el presente año.
13. Negociación de contratos y fijación de precios de contratos. Tipos de contratos.
14. Interacción con expertos estatales y no estatales.
15. Bases legales y organizativas para el diseño, documentos reglamentarios relacionados con el trabajo de las GUI, incluido GOST R 54869-2011, así como el sistema EUROCODE.
16. El costo del trabajo de diseño. Métodos de índice básico y de recursos para el cálculo de costos. Formas de documentación presupuestaria. Evaluación de la eficiencia económica de las soluciones de diseño.
17. Gestión de riesgos del proyecto. Definición e identificación de riesgos (categorías de riesgos, riesgos conocidos y riesgos desconocidos, la magnitud del riesgo, la probabilidad de ocurrencia y el grado de impacto del riesgo); elaboración de presupuestos de gestión de riesgos; determinación de la probabilidad de cumplir con los plazos especificados y el presupuesto del proyecto; métodos de respuesta al riesgo (evitación, transferencia, mitigación y aceptación); control de los síntomas de riesgo.
18. Participación en licitaciones para la obtención de un contrato de trabajo de diseño y topografía.
19. Las principales disposiciones del sistema de gestión de calidad en una organización de diseño que cumple con los requisitos de GOST ISO 9001-2015.
20. Funciones y contenido de la supervisión técnica del cliente. Supervisión estatal de edificios.
21. Competencias del GIP en materia de autoformación y formación avanzada.
22. CIP, CAP en aspectos funcionales, organizativos y estructuras financieras organización del diseño.
23. Competencias del CEO relacionadas con marketing y ventas.
24. La competencia de la DAA en materia de determinación de sus facultades, derechos y responsabilidades.
25. La competencia del Consejero Delegado para evaluar la eficacia y eficiencia de su actividad profesional y su motivación.
Desde mayo de 2015, el Programa de la Escuela Internacional de GUIs incluye un módulo adicional “Evaluación de la eficiencia económica de soluciones de diseño” (30 horas académicas). El importe total del Programa pasa a ser de 80 ac. hora. Las clases de este módulo son impartidas por profesores de la Academia Estatal de Especialistas en Inversiones (GASIS) de la Universidad Nacional de Investigación " Escuela de posgrado economía” Los estudiantes también reciben un certificado GASIS.
Los temas de los programas educativos, de consultoría e investigación que ofrece la Escuela Internacional de GUI se centran en resolver los problemas básicos que enfrentan actualmente las organizaciones de diseño, mejorando las habilidades de las figuras clave en el proceso de diseño: GUI.
Sobre los temas principales del Programa de la Escuela Internacional de GUI, se ha desarrollado el Centro de Consultoría del proyecto TsNIO.
Y ahora pasemos al mecanismo para la formación de la calidad de las decisiones de diseño para determinar de manera clara y sin ambigüedades los límites de la responsabilidad de la GUI.
Algunas consideraciones generales de diseño:
1. Cualquier proyecto de construcción es una combinación de tres modelos:
Modelos del objeto futuro (soluciones de ingeniería y planificación espacial);
Modelos de su creación (Proyecto de organización de la construcción);
Modelos de su funcionamiento (Organización y gestión de la producción).
2. La formación de una decisión de diseño consiste en la adopción real de la misma, y luego es necesario confirmar su cumplimiento, en otras palabras, verificar. La misma adopción de una decisión de diseño es una elección de alternativas, y la confirmación del cumplimiento tiene muchas opciones diferentes y, en consecuencia, muchos términos que corresponden a estas opciones. Básicamente, las opciones dependen de la hora, el lugar y las normas que se seleccionen para la confirmación.
La calidad de una solución de diseño consta de cuatro propiedades principales. Cada una de estas propiedades está formada por alguien en el software y está destinada a alguien. El que forma la propiedad de cualidad lleva por ella responsabilidad personal. El primero es la "viabilidad técnica", es decir, la solución de diseño debe ser tal que pueda implementarse durante la construcción. En primer lugar, es necesario que lo formen el contratista de obras y sus técnicos, ingenieros y especialistas principales de las unidades de producción. El segundo es la "capacidad de información", es decir, la solución de diseño debe contener todo lo necesario para la realización de los trabajos de construcción e instalación, ordenar equipos, obtener todos permisos requeridos e información de aprobación. Es necesario para el cliente y el contratista de la construcción. Esta propiedad está formada por técnicos, ingenieros y especialistas principales de las unidades productivas. Tercero - " conveniencia económica» solución de diseño, es decir, la solución de diseño debe ser económicamente competitiva en el proceso de construcción y operación de la instalación. Esto es necesario para la persona principal en el mercado: el inversor, está formado y la ISU es responsable de esto. El cuarto es “sistemático”, es decir, todas las decisiones de diseño del proyecto deben ser acordadas. Esto es necesario principalmente para los propios diseñadores, y los principales especialistas en las secciones de proyectos son responsables de esto.
Las decisiones de diseño se toman en cinco niveles. Consideremos estos niveles en el ejemplo de la sección de diseño del proyecto. El primer nivel será "ensamblajes, piezas". En este nivel, los técnicos toman decisiones sobre mallas de refuerzo, piezas empotradas, etc. El segundo nivel son los “elementos”. En este nivel, los ingenieros diseñan vigas, columnas, cimientos independientes, etc. El tercero son los "componentes". Ingenieros senior y líderes diseñan techos, revestimientos, estructuras de cerramiento, etc. El cuarto nivel es la “sección del proyecto”. En este nivel Jefe especialista toma una decisión sobre el esquema estructural del edificio y los principales parámetros de resistencia de la estructura. El quinto nivel es “indicadores técnicos y económicos del proyecto”. La toma de decisiones a este nivel es responsabilidad de la DAA.
Pasemos a la "confirmación de la conformidad de la solución de diseño". Estos son control, evaluación, verificación, análisis, validación, coordinación y aprobación de decisiones de diseño. Aquí es importante para nosotros definir los límites de la responsabilidad de la GUI.
El control implica la correlación de la decisión de diseño adoptada con las normas (reglas) vigentes, es decir, los documentos reglamentarios que actualmente están operando en el complejo de edificios ( código de urbanismo Federación Rusa, SNiP, SN, GOST, VSN, etc.). El resultado del control - "corresponde" o "no corresponde" la solución de diseño a los documentos reglamentarios especificados.
Evaluación: el mismo procedimiento de control, solo que además de "corresponde" o "no corresponde" se indica cuánto "corresponde" o "no corresponde". Por regla general, el resultado de la evaluación se da en indicadores cuantitativos, por ejemplo, el espacio de fuego entre edificios es menor que el estándar en 10 metros.
El llamado control normativo está en la misma fila que el control, con la única diferencia de que los SPDS GOST se utilizan para comparar la decisión de diseño adoptada con los documentos reglamentarios.
La verificación implica comparar la decisión de diseño adoptada con los datos de diseño de entrada (asignación de diseño, datos de entrada de diseño, especificaciones). GOST ISO 9001-2011 establece con bastante claridad los requisitos para verificar las soluciones de diseño, incluida la planificación para verificar y registrar los resultados. En particular, 7.3.5 dice que “De acuerdo con los arreglos planificados, se llevará a cabo una verificación para garantizar que los resultados del diseño y desarrollo se ajusten a los requisitos de entrada del diseño y desarrollo. Se deben mantener y conservar registros de los resultados de la inspección y todas las acciones necesarias.. Dado que los "datos de entrada", por regla general, contienen indicadores técnicos y económicos (requisitos) para la documentación del proyecto, la GUI verifica su conformidad con los realmente recibidos.
El análisis, una acción colectiva dirigida por la GUI, le permite predecir las consecuencias de la inmutabilidad del proceso de diseño existente en términos de características técnicas y económicas de las soluciones de diseño, costos de diseño y su duración. En la cláusula 7.3.4 de GOST ISO 9001-2011, así como para la verificación, se establecen requisitos para el análisis, a saber: “Las revisiones sistemáticas de diseño y desarrollo deben llevarse a cabo en las etapas apropiadas de acuerdo con las actividades planificadas para evaluar la capacidad de los resultados del diseño y desarrollo para cumplir con los requisitos, y para identificar cualquier problema [de diseño y desarrollo] y proponer acciones necesarias. Los participantes en tales revisiones deben incluir representantes de funciones relevantes para la etapa de diseño y desarrollo bajo revisión. Se deben mantener y conservar registros de los resultados del análisis y todas las acciones necesarias. Tenga en cuenta que el análisis debe ser planificado y sus resultados documentados. También es obvio que el análisis no se puede realizar al principio del diseño, ya que no hay nada que analizar todavía, y al final del diseño, porque “el tren ya se fue” y el proceso está completo. En el diseño, la GUI es responsable de realizar el análisis. Por regla general, el GUI durante el proceso de diseño reúne periódicamente a los jefes de los departamentos de producción y a los principales especialistas en las secciones del proyecto y discute con ellos el progreso del diseño y las características técnicas y económicas de las decisiones de diseño tomadas, con el fin de ser asegúrese de que al final del diseño los materiales de diseño recibidos se correspondan con los "datos de entrada".
La coordinación implica confianza en que esta solución de diseño no contradiga las soluciones de diseño para otras secciones del proyecto, es decir, por ejemplo, la solución de diseño de la sección de diseño del proyecto se compara con las soluciones de diseño de las secciones de ingeniería eléctrica, sanitaria o térmica. del proyecto.
Es responsabilidad de la PSU asegurarse de que la coordinación se lleve a cabo, y los respectivos especialistas jefes de las secciones del proyecto son responsables de la corrección de la coordinación.
Recuerde lo que es "validación". En diseño, son posibles dos situaciones de confirmación: en el primer caso, esto se puede hacer directamente "en papel", es decir, la decisión de diseño está en la pantalla de la computadora. Por ejemplo, la decisión de diseño es una viga calculada y diseñada, que debe soportar la carga correspondiente. Para confirmar el cumplimiento, es suficiente usar el mismo método de cálculo que se usó al tomar esta decisión (o uno alternativo), y si este método es probado y confiable, entonces el cálculo repetido dará absoluta confianza en la corrección del diseño. decisión. U otro ejemplo, en la tarea de diseño se indica la composición del local en la planta correspondiente del edificio y se indican las áreas requeridas. La solución de diseño para este plano de planta es fácil de verificar comparándola con los datos originales. Debe enfatizarse que tales soluciones de diseño en el alcance total del diseño son al menos 80-90 por ciento. Estos incluyen decisiones de diseño tomadas usando diseños estándar, ensambles y partes estándar, soluciones de diseño tempranas individuales aprobadas que son reutilizadas, catálogos de equipos debidamente certificados, etc., etc. En otras palabras, hablamos de confiables, probados, muchos tiempos aplicados, indudables soluciones de diseño.
La segunda situación es cuando la solución de diseño no se puede verificar de manera confiable utilizando técnicas de verificación tradicionales. Solo pueden verificarse durante la construcción u operación de la instalación construida, así como mediante la realización de pruebas especiales en condiciones lo más cercanas posible a la construcción u operación de la instalación. Tal necesidad surge cuando se utilizan tecnologías avanzadas o materiales ya recomendados o anunciados en anuncios, nuevos métodos de cálculo, equipos que nunca antes se han utilizado, soluciones tecnológicas, que no tienen análogos, etc. Por ejemplo, en la exposición, los diseñadores se familiarizaron con un nuevo material para techos que se anuncia activamente, y las características de este material son impresionantes.
Se puede decidir usar este material para un techo con un área de 20 mil metros cuadrados, sin embargo, se estipula específicamente que durante la construcción, primero debe completar una sección de techo de 10 metros cuadrados, crear una carga dinámica en él. durante un cierto tiempo, vierta agua encima y vea cómo se comporta la superficie inferior del techo en este caso. Si el resultado de la prueba es positivo, los diseñadores darán permiso para la fabricación del resto del techo. A veces, tal necesidad surge debido a la alta incertidumbre de las condiciones geológicas en áreas de construcción complejas, cuando los buscadores no pueden (incluso por razones económicas) modelar las características del suelo con suficiente precisión en ubicaciones de cimentaciones específicas. En estos casos, indican la necesidad de conducir pilotes de prueba y solo después de eso confirman la posibilidad de organizar un campo de pilotes debajo de todo el objeto.
Esta es la validación de la solución de diseño. El uso de la validación indica el compromiso de la organización de diseño con todo lo nuevo, avanzado. Este es un signo de competitividad en soluciones de diseño, este es el deseo de tomar una posición de liderazgo en el diseño a través de la mejora continua de la satisfacción del cliente. La responsabilidad por el hecho mismo de la validación recae en la GUI, por el contenido de la validación, los principales especialistas en las secciones del proyecto.
La aprobación es el permiso para transferir la documentación de diseño completa al cliente. Esto es responsabilidad del GUI, y lo implementa cuando firma la factura antes de enviar la documentación al cliente.
Ahora pasemos a la responsabilidad de la GUI, asociada con la reducción del costo del trabajo de diseño. Como sabe, hay muchas oportunidades para reducir costos, y esto es un "dolor de cabeza" para la gerencia y todos los especialistas líderes en software, ya que esta es prácticamente la única forma de aumentar las ganancias de una organización de diseño. La GUI hace una contribución significativa a esto, al darse cuenta de la responsabilidad de la gestión (externalización) de los subdiseñadores.
En la actualidad, se ha vuelto posible seleccionar subdiseñadores (SPO) en función de los resultados de su evaluación, comparación con competidores, reevaluación periódica y ha aparecido la responsabilidad de la GUI para esta elección. Entre los temas en el diseño comenzaron a trabajar principio importante, “quien paga, llama a la música”, no solo en un cierto sentido tradicional, sino también como un requisito del diseñador general (GP) para pensar constantemente en mejorar (asegurar) la calidad y reducir el costo del trabajo de diseño. Además, la Ley establece que sólo el médico de cabecera es responsable ante el Cliente por la calidad de la documentación de diseño y estimación desarrollada por el software de fuente abierta. Por lo tanto, es necesario guiarse por los requisitos de GOST ISO 9001-2011 y las Directrices para el uso de procesos de subcontratación // ISO/TS 176/SC 2/N 630R2, 24 de noviembre de 2003).
En general, hay tres tipos condicionales de software de código abierto:
- "ordinarios" - ROS con los que las empresas estatales tienen relaciones normales de mercado;
- "protegidos" - una criatura del cliente, la relación del GP con la cual es determinada por el cliente.
Usando el ejemplo de las relaciones con el software de código abierto, consideraremos cada uno de los subsistemas a su vez, teniendo en cuenta que la GUI en algunos casos toma decisiones y en otros participa en su adopción.
Evaluación, selección y reevaluación de subdiseñadores.
Este subsistema consta de dos bloques:
Formación y mantenimiento de la Lista (base de datos, registro, etc.) de software de código abierto aprobado y su actualización;
Selección de software de código abierto de la lista especificada para realizar trabajos en un proyecto específico.
La realización del trabajo dentro del primer bloque es función del departamento técnico de software, dentro del segundo bloque es responsabilidad de la GUI.
Para formar la Lista Departamento técnico La OP busca, evalúa, selecciona y reevalúa los ROS de acuerdo con las necesidades de la OP utilizando criterios desarrollados en conjunto con las ISU.
Está claro que tal enfoque no garantiza la completa adecuación del STR a las expectativas del GP debido a la dificultad de formalizar algunas cuestiones. Por ejemplo, la pregunta sobre la disponibilidad de un SGC válido y su cumplimiento con los requisitos de GOST ISO 9001-2011. El software de código abierto responde que el SGC está funcionando y cumple, como lo demuestra el certificado del organismo de certificación “N”. Experiencia en la evaluación del cumplimiento de ciertos requisitos de GOST ISO 9001-2011 organizaciones autorreguladoras de los diseñadores indica que más del 90 % de los certificados se reciben formalmente, simplemente se “compran” y, a menudo, no tienen nada que ver con un software de código abierto en particular. Resulta que el médico de cabecera tiene la responsabilidad real de la calidad de la documentación de diseño (de trabajo) preparada por la SPO, pero la elección de la SPO se basa en las "certificaciones" de la propia SPO en forma de respuestas a las preguntas de El cuestionario. Al diseñar una instalación específica, el GUI, por regla general, selecciona la SPO adecuada de la Lista, guiado por criterios adicionales, incluida la ubicación territorial de la SPO, el conocimiento de la SPO sobre las propiedades de un sitio de construcción en particular, contactos previos con un Cliente específico, la disposición del SPO para cumplir con el pedido, y otros.
La GUI debe visitar la organización directamente antes de tomar la decisión de involucrar software de código abierto en el diseño. Este nuevo deber GUI. Esta tecnología se proporciona Normas ISO 9000 y se denomina auditoría de "segunda parte". La duración de la auditoría por parte de la segunda parte no es más de un día hábil (óptimamente 3-4 horas).
Esta duración tan corta se explica por el hecho de que no se considera todo el sistema de gestión de calidad del software de código abierto, sino solo algunos puntos clave. La práctica muestra que si todo es normal en estos puntos, entonces, con un alto grado de probabilidad, el STR cumple con las expectativas del médico de cabecera.
Cabe destacar que el Cliente trata únicamente con el médico de cabecera con el que tiene un contrato. Es posible que no conozca al resto de los participantes del proyecto. Por lo tanto, la relación con el software libre es un problema exclusivo de las EP. SPO en realidad actúa como una subdivisión estructural adicional del GP, que debe administrar en el proceso de implementación del proyecto de la misma manera que su "propio" divisiones estructurales, teniendo en cuenta el tiempo y la calidad de la documentación de diseño (de trabajo) desarrollada por el software de código abierto, de la cual el médico de cabecera es responsable ante el cliente. Esto también determina las responsabilidades de la EP para la gestión de los ROS.
El tipo y alcance de la gestión del software libre puede variar en un rango significativo: desde el mínimo, cuando se emite la tarea técnica y se acepta el trabajo realizado con poca o ninguna verificación, hasta el máximo, cuando se requiere que el El software de código abierto se guiará por la gestión y otros documentos aprobados por el médico de cabecera al cumplir con el pedido. Al mismo tiempo, se lleva a cabo una verificación completa del SPO completo de la documentación de diseño y estimación, incluso con la participación de expertos independientes.
El alcance requerido de la gestión lo determina la GUI en función de los resultados de la evaluación (reevaluación) del ROS, incluso teniendo en cuenta la información obtenida durante la auditoría por la segunda parte, así como en función de los costos planificados por la GPU para realizar control de entrada materiales STR, teniendo en cuenta que estos costos aumentan el costo de trabajo en el proyecto.
Características de la gestión de la SPO La ISU debe emitir un acuerdo de subcontratación bajo "condiciones especiales". El departamento técnico de la SE desarrolla una plantilla para dichas “condiciones especiales”, en la que se enumeran casi todos los aspectos posibles y/o necesarios de la gestión de un software de código abierto, y la GUI, al analizar un contrato específico con un software de código abierto, incluye aquellos métodos de gestión que cumplen con las condiciones de un proyecto en particular. Cuanto más profundo sea el grado de control del software de código abierto, menor será el volumen de control de entrada de los materiales de diseño del software de código abierto y, por lo tanto, el costo de la GP.
Dichos métodos de gestión pueden incluir la necesidad de:
Coordinar con el médico de cabecera el proceso tecnológico de diseño utilizado por el software de código abierto o garantizar la implementación del trabajo de diseño utilizando proceso tecnológico diseño, que es utilizado por el médico de cabecera;
Aprobación del cronograma de trabajo de diseño, que la SPO debe desarrollar con base en plan de calendario obras anexas al contrato;
Designación (de acuerdo con el GP) de un GUI (gestor de proyecto) específico para la orden (sección de proyecto) transferida para ejecución, etc.
Dependiendo del grado de gestión del software de fuente abierta, el alcance del control de entrada en la SOE puede variar del 100% a casi nada, es decir, el recálculo formal de los documentos del proyecto recibidos del software de fuente abierta.
Después de la transferencia del diseño completo y la documentación del presupuesto al Cliente o después de la puesta en marcha de la instalación (si se llevó a cabo la supervisión arquitectónica), la GUI debe completar el proyecto de subcontratación.
Para esto necesitas:
Verificar la disponibilidad de documentos que confirmen la aceptación del diseño y la documentación estimada de la SPO, incluida la verificación de la calidad de la documentación especificada;
Realizar una evaluación de la cooperación con software de código abierto e informar los resultados al departamento técnico para corregir la Lista;
Obtener del SPO y transferir al archivo de GP información sobre las soluciones de diseño efectivas individuales desarrolladas, incluso en la documentación del SPO, que se puede recomendar para su reutilización;
Preparar una revisión oficial del software de código abierto;
Resolver el tema (si es necesario y posible) de los incentivos económicos para el software libre.
Ahora sobre la obligación de la GUI, que está asociada con la participación en la formación de una "cartera de pedidos" y la reducción del costo del software para buscar nuevos clientes.
Estamos hablando del hecho de que de acuerdo con la cláusula 7.2.1 "Procesos relacionados con los consumidores" de GOST ISO 9001-2011, el software debe determinar los requisitos:
1. Establecido por el cliente, incluidos los requisitos para la entrega y las actividades posteriores a la entrega.
2. No especificado por el cliente, pero necesario para el uso particular o previsto del DCE, cuando se conozca.
3. Documentación legislativa y otras obligatorias, relacionadas con el diseño y estimación.
4. Cualquier software adicional definido.
Lo que se entiende por los primeros tres grupos de requisitos (1-3) es más o menos claro. Expliquemos además que los “requisitos no declarados por el cliente, pero necesarios para el uso específico o previsto del diseño y la documentación del presupuesto, si se conocen”, pueden incluir todos los requisitos del propio software, cuyo cumplimiento determina la calidad, precio y plazo de entrega de la documentación del proyecto.
Por ejemplo, si el cliente recibe estimaciones de diseño que, de acuerdo con la tecnología de diseño existente, se almacena tiempo específico antes de la transferencia al cliente en el archivo técnico, los requisitos del propio software con respecto a las condiciones para almacenar la documentación especificada en el archivo se referirán a la cláusula 7.2.1 (2) de la norma. Cumpliendo los requisitos especificados en la cláusula 7.2.1 (1-3) del estándar, el software no puede recibir ventaja competitiva, ya que estos requisitos son necesariamente implementados por todos los competidores. En condiciones de mercado, solo “sobrevive” el software que puede determinar y cumplir los requisitos de la cláusula 7.2.1 (4). Llamamos a estos requisitos "previstos" y aclaramos su significado: en primer lugar, son "adivinados", formulados por el propio software, en segundo lugar, no están aprobados ni acordados con el cliente, y en tercer lugar, su implementación se lleva a cabo a expensas de propios fondos POR. Como resultado, el cliente recibe documentación del proyecto (servicios) con parámetros inesperados para él o con parámetros mejores a los esperados, lo que garantiza no solo la satisfacción del cliente, sino que lo hace admirar la documentación de diseño y estimación proporcionada (servicio prestado). En este último caso, el software puede estar seguro de que el cliente volverá a él repetidamente. Y mantener un cliente, como sabes, es 5-7 veces más barato que buscar uno nuevo. Esta es la esencia de una disposición fundamentalmente nueva establecida en GOST ISO 9001-2011.
Para que el cumplimiento del requisito especificado en la cláusula 7.2.1 (4) de la norma tenga un impacto en la formación de ventajas competitivas del software, es necesario determinar el propietario del proceso para la formación de la esperada requisitos de los clientes, es decir, uno de los gerentes que establece las reglas para la ejecución de esta actividad. Para el software, es probable que el propietario del proceso sea el ingeniero jefe del instituto. El "propietario" del proceso, es decir, el especialista que forma los requisitos esperados del cliente para un proyecto específico, debe ser la GUI. Para aclarar, la GUI es responsable de garantizar que se definan los requisitos previstos del cliente y del contenido requisitos especificados los principales especialistas de los departamentos de producción son responsables.
Otra obligación de la GUI se forma durante el análisis del contrato (acuerdo) con el cliente. El atractivo del cliente para el software puede ser de diferentes maneras: información sobre la licitación ganada (competencia); una carta oficial con una propuesta para desarrollar la documentación del proyecto; llamada telefónica administrador de software; contacto informal a través de compañeros, etc. En el momento de recibir una de las señales anteriores, se recomienda designar un GUI que gestionará el análisis del contrato hasta que sea firmado por el cliente.
Este deber del GIP implica:
Determinación del círculo de personas que participarán en la coordinación del proyecto de convenio y la distribución de responsabilidades entre ellas;
Contratación de los gerentes y especialistas antes mencionados para realizar negociaciones (reuniones de trabajo) con el cliente para discutir ciertas disposiciones del borrador del contrato, incluidas las negociaciones para determinar el precio del contrato;
Selección de la base de datos de plantillas de una opción adecuada para un cliente específico y un objeto de diseño;
Determinar la necesidad y posibilidad de atraer subdiseñadores y realizar negociaciones preliminares con ellos;
Evaluar los riesgos que pueden acompañar el cumplimiento por parte del software de sus obligaciones en virtud del contrato.
Cada una de estas acciones en las condiciones actuales es significativamente diferente de la práctica que conocemos. Por ejemplo, la aprobación de un proyecto de acuerdo, por regla general, se redacta en la "Hoja de Acuerdo", en la que se indica el nombre completo y el cargo del gerente correspondiente, quien, si la decisión es positiva, pone su firma, y si la decisión es negativa, argumenta su opinión por escrito. En nuestra opinión, es necesario establecer la responsabilidad del titular por las cláusulas pertinentes del proyecto de contrato. La suma de los puntos de la "Lista de aprobaciones" debe ser igual a la suma de los puntos del proyecto de acuerdo. Esto asegura la responsabilidad personal de cada gerente por la viabilidad de los términos del contrato por parte de la organización de diseño y la comprensión equitativa de los términos relevantes del borrador del contrato por parte de la organización de diseño y el cliente, etc.
El material de este artículo puede causar objeciones a algunos diseñadores. Estamos listos para una discusión constructiva con colegas en una forma conveniente para ellos.
| Discutir en el foro |
|
| |
|
Desde febrero de 2008 se ha iniciado la etapa de trabajo en relación a los documentos que definen el proceso de diseño. Fue la ley de febrero de 2008 la que introdujo sus propias reglas para la construcción en el territorio de la Federación Rusa. Cualquiera que sea el mes en que la construcción esté en marcha, en diciembre, abril, mayo o agosto, debe aprobar los documentos de las autoridades pertinentes. Esto se aplica incluso a las reparaciones mayores en la instalación.
Decreto Gubernativo 87 sobre la composición de la documentación del proyecto,
Por ejemplo, el primer párrafo establece que cualquier explicación sobre el uso del Reglamento, que está aprobado en la Resolución, es proporcionada directamente por el Ministerio de Construcción de la Federación Rusa. Las demás cuestiones se resuelven de acuerdo con la competencia de órganos específicos. poder Ejecutivo involucrados en el desarrollo de la política pública.
Cambios 2016
con cambios contiene varias modificaciones en comparación con versión antigua. Por ejemplo, el desarrollo de estándares estimados para la construcción de una instalación en particular se lleva a cabo de acuerdo con la decisión del Gobierno de la Federación Rusa.
Suficiente visa de la GUI en la portada
Somos auditados anualmente por el organismo territorial de normalización
y no hubo comentarios
Yo y no solo ya he informado que sigo tu conjunto de documentación como crees que es correcto
Parece que solo su organización del ejército de institutos de diseño realiza la documentación de diseño.
Bien
No habrá más comentarios de mi parte.
Repito que esta pregunta ya ha creado un "mordisco en los dientes" y ¿no es hora de que dediquemos tiempo útil al desarrollo de documentación de trabajo?
No entiendo tu disgusto. Si no está interesado o ha decidido todo por sí mismo y realmente no debería perder el tiempo discutiéndolo, no lo obligo a hacer esto. Además, su opinión sobre este tema se conocía incluso antes de su creación. Y te escribí sobre esto, diciendo que estaba interesado no solo en mis opiniones y las tuyas sobre este problema así como otros profesionales. Además, de ninguna manera afirmé que mi empresa es superior a mí personalmente, como diseñador, en contraste con usted. Solo tenemos una disputa sobre las reglas de registro y solo en base a sus comentarios sobre mi proyecto. Por supuesto, trato de proteger mi proyecto, como lo harías tú en mi lugar. Pero estoy listo para entender todo y hacer los cambios apropiados en el diseño posterior, creo que todo diseñador que se precie quiere publicar la documentación con el formato correcto.
8.7 Páginas de título Los volúmenes de documentación de diseño están firmados por:
- el jefe o ingeniero jefe de la organización;
Ingeniero jefe (arquitecto) del proyecto.
Las firmas del ingeniero jefe (arquitecto) del proyecto son obligatorias en las hojas de datos generales sobre los dibujos de trabajo, las hojas más importantes de los dibujos de trabajo, la parte gráfica del diseño y la documentación de la encuesta de informes;
sobre la presencia obligatoria del juramento del GIP y la lista documentos normativos Ya publiqué enlaces en OD.
De aquí sacamos una conclusión. A pesar de la falta de comentarios. organización territorial estandarización (no creo que haya grandes especialistas) y su gran experiencia, que realmente respeto, desde el punto de vista del GOST 21.1101-2009 que menciona repetidamente, elabora el OD incorrectamente, sin embargo, como la mayoría ( si no todos) de los aquí presentes (sí y no sólo aquí), sin excluirme.
Quién viola en mayor medida, quién en menor medida, pero nadie podría presumir de absolutamente competente al menos OD (esperamos que alguien lo sea, sobre todo porque lo prometieron) y esto es realmente lamentable. Sólo queda admitir tímidamente este hecho, a pesar de sus atavíos y méritos, para hacer trabajar los errores y seguir cumpliendo los requisitos. Básicamente, es por eso que creé este hilo.
¿Cómo relacionarse con diseñadores que aplican hace treinta años una norma anulada? Una prueba de fuego que muestra la falta de conocimiento en el campo del diseño es la inclusión del "juramento GIP" en los datos generales.
La historia se remonta al menos a GOST 21.102-79 "SPDS Datos generales sobre dibujos de trabajo":
"12. En la esquina inferior izquierda de la primera hoja de datos generales de cada juego principal de planos de trabajo, se coloca en un marco rectangular un registro del ingeniero jefe del proyecto, que certifica el cumplimiento del proyecto con las normas vigentes y normas, y para edificios o estructuras con un riesgo de incendio y naturaleza explosiva de producción, además, asegurar su funcionamiento sujeto a las medidas previstas por el proyecto.
GOST 21.101-93 "SPDS Requisitos básicos para la documentación de trabajo", que lo reemplazó, canceló esta norma:
" 2.5.4. Las instrucciones generales son:
4) un registro de que las soluciones técnicas adoptadas en los planos de trabajo cumplen con los requisitos ambientales, sanitarios e higiénicos, de seguridad contra incendios y otras normas vigentes en el territorio de la Federación de Rusia y garantizan el funcionamiento seguro de la instalación para la vida humana y salud, con sujeción a las medidas previstas en los planos de trabajo;"
GOST 21.101-97, que lo reemplazó, "Requisitos básicos de SPDS para el diseño y la documentación de trabajo" simplificó aún más la frase necesaria:
"4.2.9 Las instrucciones generales dan:
d) un registro de que los dibujos de trabajo se han desarrollado de acuerdo con los códigos, reglas y normas aplicables.
GOST R 21.1101-2013 actualmente en vigor en Rusia “Sistema de documentos de diseño para la construcción. Requisitos básicos para el diseño y la documentación de trabajo” contiene la siguiente frase:
"4.3.5 Las instrucciones generales dan:
- un registro del cumplimiento de la documentación de trabajo con la tarea de diseño emitido por especificaciones, los requisitos de la actual reglamentos tecnicos, normas, códigos de práctica, otros documentos que contengan requisitos establecidos".
Es fácil ver que ninguno de los documentos normativos anteriores, excepto el primero, contiene una palabra sobre la GUI. Ahora coge el primer botiquín básico que te venga a la mano. Busque la frase "sobre el cumplimiento" allí. Dependiendo de la redacción, puede estimar aproximadamente la edad del diseñador que emitió la documentación :) Si ve el "Juramento de la GUI en el marco", probablemente sea un jubilado, y no muy lejos: una vez le enseñaron esto manera, y durante 25 años nunca pensó en mirar la normativa.
Para los que duden, daré un argumento más. Todavía no hay cancelado SNiP 1.06.04-85 "Reglamento sobre el ingeniero jefe (arquitecto jefe) del proyecto. Contiene las siguientes disposiciones:
"2.2. De acuerdo con las tareas principales, el ingeniero jefe (arquitecto jefe) del proyecto es responsable de:
2.2.15. Confirmación en materiales proyecto entrada correspondiente que la documentación de diseño y estimación para la construcción de empresas, edificios y estructuras se ha desarrollado de acuerdo con las normas, reglas, instrucciones y estándares estatales. Ni una palabra más, exigiendo registrar por separado en la documentación de trabajo.
Ahora, por el bien de la colección, citaré mi pregunta, que se incluyó en la Colección de explicaciones, número 2. “Colección de explicaciones de los requisitos de los estándares del sistema de documentación del proyecto para la construcción (preguntas y respuestas). Número 2. - OJSC "CNS", Moscú, 2012 ":
4. Especificar la necesidad de llevar el "juramento del GIP" en las hojas de datos generales. Este requisito ni siquiera estaba contenido en GOST 21.101-97, pero un número significativo de organizaciones de diseño continúan por inercia para cumplir con el requisito del GOST 1979 cancelado.
Respuesta: Sí, al continuar realizando un "registro sobre el cumplimiento de la documentación de trabajo", como fue el caso en GOST 21.102-79, que se canceló en 1993, ahora estas organizaciones de diseño están violando el estándar actual. De acuerdo con la cláusula 4.3.5 de GOST R 21.1101-2009, se proporciona un registro del cumplimiento de la documentación de diseño con la asignación de diseño emitida por las especificaciones técnicas, los requisitos del TR actual, GOST, SP, etc. en el instrucciones generales en las hojas de datos generales.
La pregunta continúa agitando las mentes, y en el Libro de las explicaciones, número 4 “Colección de explicaciones de los requisitos de los estándares del sistema de documentación de proyectos para la construcción (SPDS) (preguntas y respuestas). Número 4. - OJSC "CNS", Moscú, 2015 " Lea de nuevo:
"Pregunta 5: ¿Es necesario emitir el requisito de la cláusula 4.5.6 de GOST R 21.1101-2013 sobre el cumplimiento de la documentación de trabajo con todas las normas y reglas por separado, en un marco y poner la firma de la GUI?
Respuesta: En GOST R 21.1101-2013 no hay requisitos para ninguna asignación al marco de un párrafo de instrucciones generales que contengan un "registro sobre el cumplimiento de la documentación de trabajo" y su firma por separado por parte de la GUI.
La firma de la persona que prepara la documentación de trabajo (GIP) es obligatoria en las inscripciones principales en las hojas de datos generales en los dibujos de trabajo y firmas adicionales la misma persona bajo ninguna información en las mismas hojas no es obligatorio.
Tener dos firmas GUI en el mismo documento (y más a menudo en la misma hoja) no hará que la documentación sea el doble de buena.
No confunda el elemento en las "instrucciones generales" en la documentación de trabajo con la "certificación de la organización de diseño" en la documentación del proyecto"
