(Утративший силу) СТО УП «Стандартизация. Порядок создания, управления и применения...

Докипедия просит пользователей использовать в своей электронной переписке скопированные части текстов нормативных документов. Автоматически генерируемые обратные ссылки на источник информации, доставят удовольствие вашим адресатам.

Утративший силу
- недопустимости создания условиями СТО препятствий для деятельности участников Системы стандартов.
3.2. Структура системы стандартизации.
3.2.1.1. Общее руководство процессом стандартизации и решение финансовых вопросов осуществляет Владелец стандарта.
3.2.1.2. Участники Системы стандартов в своей деятельности должны руководствоваться действующим законодательством Российской Федерации, техническими регламентами, нормативными правовыми актами, документами, принимаемыми федеральными органами исполнительной власти, техническими нормативными документами (ГОСТ, ГОСТ Р, СНиП, СП, РД, РДС и пр.), другими документами в области проектирования, строительства, эксплуатации зданий и сооружений, а также стандартами, утвержденными Владельцем стандартов в установленном порядке и входящими в Систему стандартов.
3.2.2. Стандарты организации могут разрабатываться по различным направлениям деятельности, в зависимости от объекта и аспекта стандартизации, а также устанавливаемым к ним требований.
а) стандарты по управлению процессами (СТО УП), которые включают в себя:
- основополагающие стандарты;
- правила;
- реестры;
- общие стандарты;
- классификаторы и т.п.
б) стандартные типовые договора (СТО СТД);
в) формы документов (СТО ФД);
г) методические инструкции (СТО МИ).
3.2.4. В случае необходимости решения комплексных задач стандартизации могут разрабатываться комплексы стандартов, В этом случае в стандарте необходимо указывать наименование комплекса стандартов, к которому относится СТО.
3.3. Процессы создания и управления стандартами
3.3.1. Стандарты разрабатываются и создаются в ходе четырехстадийного процесса:
Карта жизненного цикла разрабатываемого СТО приведена на рисунке 1.
928 × 895 пикс.     Открыть в новом окне
Рисунок 1 – Карта жизненного цикла разрабатываемого СТО
3.3.2. Во время разработки СТО возможен пропуск некоторых стадий, в случае их досрочного выполнения.
3.3.3. В процессе управления действующим стандартом возможны две стадии:

4. Описание процессов создания нового стандарта

4.1. Стадия предложения

4.1.1. Потенциальный Разработчик стандарта по мере появления потребности в СТО сообщает Управляющему проектом по стандартизации, который согласовывая с Владельцем стандарта, подтверждает необходимость разработки стандарта.
4.1.2. Управляющий проектом по стандартизации, при необходимости, запрашивает дополнительную информацию о будущем СТО, чтобы обеспечить соответствие с существующей Системой стандартов.

4.2. Стадия разработки и обсуждения

4.2.1. Разработчик стандарта подготавливает проект, в соответствии с данным Стандартом и СТО УП «Стандартизация. Порядок изложение и оформления стандартов бренда develop-man», и направляет его на обсуждение заинтересованным лицам. Перечень лиц и срок обсуждения определяется Разработчиком самостоятельно или по требованию Владельца стандартов.
4.2.2. По окончании или во время обсуждения проекта СТО Разработчик вносит необходимые поправки в свой проект и (или) отклоняет выявленные замечания (предложения, комментарии и т.п.) с обоснованием причин.
4.2.3. Разработчик вправе самостоятельно направить проект СТО на стадию утверждения, указанной в пункте 4.3, данного Стандарта.

4.3. Стадия утверждения

4.3.1. Стадия утверждения предполагает итоговое утверждение разрабатываемого СТО Владельцем стандарта и, при необходимости, дополнительным кругом лиц.
4.3.2. Длительность цикла согласования устанавливается в зависимости от сложности, вида и объема стандарта.
4.3.3. Согласующий при визировании рассматриваемого проекта СТО может указать:
а) визу «Подписал» (положительная виза) при отсутствии замечаний, подтвердить согласие с проектом СТО и, в случае наличия предложений, вправе сообщить о них Разработчику;
б) визу «Отказал» (отрицательная виза) при наличии замечаний по проекту СТО, при этом согласующий обязан указать обоснованную и аргументированную причину отказа, написав соответствующий комментарий, либо предоставить предлагаемый вариант.
4.3.4. После окончания цикла утверждения, при наличии виз(ы) «Отказал» по проекту СТО, либо при наличии комментариев и дополнений при визе «Подписал», Разработчик вносит корректировки в рассматриваемый проект. В случае, если Разработчик не принимает и не вносит в проект СТО корректировки по замечаниям и предложениям, ему необходимо дать конструктивный и аргументированный ответ согласующему.
4.3.5. После внесения корректировок в рассматриваемый проект Разработчик направляет исправленный вариант СТО на повторный цикл согласования тому согласующему, который поставил отрицательную визу.
4.3.6. При повторных циклах утверждения согласующему лицу не допускается указывать замечания, которые не были им указаны при даче заключения по разрабатываемому проекту СТО и (или) при предыдущем цикле согласования, и не касаются исправленных или появившихся в результате доработки данных.
4.3.7. Стадия утверждения проводится до того момента, пока не будут проработаны и устранены все аргументированные замечания участвующих в цикле согласования лиц, указанные при отрицательной визе. Стандарт считается одобренным при наличии всех положительных виз.
4.3.8. Утвержденный проект стандарта Разработчиком направляется Управляющему проектом по стандартизации на стадию публикации.