Когда опытный руководитель называет своего инженера «творческим человеком», стоит насторожиться. Чаще всего это не комплимент, а завуалированное проклятие. Такой творческий он человек, пять раз просил его конкретно здесь разместить бетонную эстакаду, так он типовую вертикальную лестницу запихал. И еще защищает решение — по его мнению, так лучше: это сколько заказчик на материалах сэкономит, а такую стремянку, он видел, бесполезно валяющейся в подсобном помещении — даже покупать не надо. Зачем ругаешься, начальника! Все в лучшем виде сделал.
Творчество, как это часто бывает
Глубинная суть этого «творчества» в гремучей смеси рационализма, энергоэффективности (сиречь лени) и ограниченной картине мира конкретного специалиста. Ему не было интересно, зачем его просят здесь сделать именно так. Что технологическая линия сбрасывает отходы, которые на своем горбу по лестнице не потягаешь. Он не предложил заранее концепцию оптимизированного решения на согласование. Зато «позаботившись» о кармане заказчика, вместо утомительных расчетов и выпуска чертежей, просто дал ссылку на типовое решение… гора родила мышь.
Конечно, бывает, что человека реально завалили работой. Разгоряченный мозг в попытке успеть всё судорожно ищет способ закрыть вопрос хоть как-нибудь, чтобы выиграть время. Особенно часто это встречается в работе с перегруженными фрилансерами, которые набрали заказов, а потом благополучно сливают все на финише.
Но давайте оставим крайние случаи и посмотрим на необходимые процедуры, где подобное «творчество» проявляется в полной мере. Вот вы получаете после правок, скажем, техническое задание (ТЗ) с гордой пометкой: «уточненное» и комментарием: «добавили требования по просьбе заказчика». И всё. Что именно добавлено — тайна, покрытая мраком. Автор предлагает вам заново проштудировать весь документ, выискивая различия, тратя время, силы и последние крохи душевного спокойствия. А ведь ТЗ — такой же официальный документ, как и чертеж, и на него распространяются те же правила внесения изменений. Но нет, даже выделить скорректированный текст — это слишком сложно и вероятно нарушает красоту и гармонию божественного замысла.
Поразительная вещь: самые очевидные принципы приходится не только разъяснять, но и доказывать. Особенно молодым, но перспективным сотрудникам. Казалось бы, что тут сложного: внес изменения — зафиксируй, что сделал и почему. Сделай информацию доступной для причастных. Если нужно — выпусти новую ревизию. Ан нет! «Что я, каждую исправленную букву должен записывать? Я же тут чуть-чуть подправил»!
Мой личный фаворит — это убийственный аргумент: «Мы же им окончательную редакцию направили неофициально в апреле! Они же старые версии выкинут и начнут строить по последней. Зачем нам здесь перечень изменений?».
Не выкинут. А начнут строить по старой редакции, а потом, когда с удивлением узнают, что уже залитые фундаменты должны быть на десять метров левее, сильно обидятся, приедут разбираться, почему у них два одинаковых комплекта, но с разными чертежами.
А сколько изменений по-тихому и без всяческих уведомлений вносится на этапах внутренний согласований. Без каких-то следов меняются планировки, сдвигается оборудование и коммуникации. Когда это вскрывается, то разработчик делает удивленное лицо и рассказывает, что он где-то в курилке кого-то предупреждал и возможно, что-то показывал.
И да, это глубинный вопрос качества результата, который должен решаться как минимум двумя способами: организационно и на уровне корпоративной культуры. Ведь сопроводить результат однозначными пояснениями — это еще и проявить уважение к коллегам и организации.
Как вносить изменения по ГОСТ 21.101-2020
На самом деле ГОСТы содержат описание всех элементов процедуры внесения изменений. Что не удивительно, составляли их опытные, не глупые люди (по крайней мере ГОСТы, о которых идет речь в данной статье). Да, некоторые положения кажутся избыточными, так как они универсальны. Как обычно, акцент сделан на технические мероприятия, а суть остается за кадром. Предполагается, что это, итак, все знают. В конце концов, нужно что-то оптимизировать — конкретная компания может выпустить какие-то свои стандарты.
Естественно, дорогие читатели, знают, что у нас есть ГОСТ 21.101-2020, а в нем глава 7 «Правила внесения изменений». Это все про проектную (рабочую) документацию. Кратко напомню суть.
1. Изменение — любая корректировка документа, переданного заказчику, без присвоения нового обозначения. Если обозначение меняется — это уже новый документ. Менять обозначение выпущенного документа «просто так» запрещено: под угрозой наказания в особо извращенной форме.
2. Однако расчеты, в случае обнаружения в них ошибки перевыпускаются полностью, с новым обозначением. При этом старые расчёты сохраняются с указанием на замену.
3. Любые правки вносят только на основании разрешения на внесение изменений (формы 9 и 9а приведены в приложении Л ГОСТ 21.101‑2020). Без разрешения — нельзя, но, конечно, сплошь и рядом.
4. Подписывать разрешения должен руководитель организации, но чаще это делает ГИП. Однако простой подписи исполнителя недостаточно.
5. В разрешении обязательно приводят: содержание изменений (что именно исправляют), обозначение документа (куда вносят правки), номера листов (подлежащих изменению). Рекомендуется также указывать причины изменений. Последние обычно шифруют в рамках какой-то классификации. И это крайне важная управленческая информация, позволяющая понять, где сейчас проектное бюро.
6. Номер разрешения (как минимум последнего) обязательно указывают:
- на титульном листе;
- в графе «№ разрешения» на изменённых листах;
- в ведомости документов (если ведётся);
- на листе регистрации изменений для текстовых документов (если ведется).
Само разрешение прикладывают к документации при передаче заказчику или в архив.
7. Информацию об изменениях указывают в поле «Примечание» в таблицах содержания или ведомости комплекта (смотря, что актуально).
7. Как оформляют изменения на листах? На каждом изменённом листе:
- обводят изменённый участок сплошной тонкой линией и связывают с пометкой «Изм. Х»» (где Х — номер изменения) и при необходимости добавляют: «см. лист», «взамен», «дополнение» и т. д.;
- ставят порядковый номер изменения (1, 2, 3…);
- в основной надписи листа заполняют графы: «Изм.», «Кол.уч.», «Лист», «№ док.», «Подп.», «Дата».
Чаще всего все пользуются возможностью заменять листы даже, если по факту вносится одна небольшая правка. Это позволяет хотя бы не заполнять графу «Кол. уч.» (количество изменяемых участков) на листах чертежей и главное не мудрить при заполнении таблицы листа регистрации изменений для текстовых документов, а значит как-то автоматизировать внесение изменений (см. через рисунок выше).
8. Если изменений много или они затрагивают большую часть листа — лист заменяют (выпускают новый с тем же обозначением, но с пометкой «Зам.»).
9. При добавлении нового листа в бумажный текстовый документ допускается присваивать ему номер предыдущего листа с добавлением очередной строчной буквы русского алфавита или через точку арабской цифры, например 3а или 3.1. При аннулировании листа документа нумерацию его последующих листов сохраняют.
9. Все версии документа (включая заменённые листы) сохраняют в архиве. Это нужно для: отслеживания истории правок; разрешения споров; прохождения экспертиз.
10. Если лист изменяли несколько раз, номера изменений указывают последовательно (например, «Изм. 1», «Изм. 2»). В основной надписи отражают последнее внесённое изменение.
Главная и часто невыполнимая боль для небольших проектных контор, не чурающихся привлекать внештатников и фрилансеров, конечно, вот в этом: «любое изменение в документе, вызывающее какие-либо изменения в других документах, должно одновременно сопровождаться внесением соответствующих изменений во все взаимосвязанные документы». Впрочем, это финансовые затраты для любой организации, особенно, если изменения случились за пару дней до выпуска комплекта.
На практике, конечно, инженеры крайне не любят работать по процедуре и всячески стараются ее упростить. Это же мало внести изменение, его еще надо согласовать, еще кучу штампов надо подправить, учетные листы заполнить, сопроводительное письмо написать и т. д.
Но процедура мешает вносить изменения частично или на отшибись. Сравните два варианта: «стена перенесена с оси А на ось Б». И не важно, что исправление выполнено только на одном чертеже, а пресловутая стена фигурирует на десяти. Пока еще ГИП это заметит, да и будет ли смотреть, когда его сразу зажимают по другим, на текущий момент более важным делам. Или: «стена перенесена с оси А на ось Б на л.3». Вот тут, если знаком с комплектом, сразу возникает вопрос: а на л.4-13?
Как вносить изменения по ГОСТ 2.503-2013
Некоторое неудобство ГОСТ 21.101 в том, что он регламентирует внесение изменений в документацию, передаваемую заказчику. И как бы не регламентирует внутренние корректировки, которые возникают в процессе. А тут, любой знающий человек, подтвердит, есть много проблем. И чем сложнее проект, тем больше проблем.
Но, с другой стороны, у нас есть ГОСТ 2.503 и он также имеет значение при проектировании. Вот его основная канва, которая вполне перекликается и ГОСТ 21.101.
- Любое изменение (исправление, удаление, добавление) в подлинник документа вносится только на основании Извещения об изменении (ИИ). Для электронных документов в качестве подлинника может быть выбран экземпляр файла, в который будет использоваться для создания копий. Ну то есть, если вы кому-то отправили файл, считай сделали копию — в этот момент ваш файл на компьютере стал «подлинником».
- Любое изменение в документе, вызывающее какие-либо изменения в других документах, должно одновременно сопровождаться внесением соответствующих изменений во все взаимосвязанные документы.
- Предложение об изменении (ПР) — документ «снизу», от производственников или смежников (читай: проектировщика), с идеей для правки. На его основе нельзя ничего менять, это лишь заявка для рассмотрения держателем подлинников остальных разделов (читай: ГИП, ГАП, руководитель организации и т. д.).
- Предварительное извещение (ПИ) — временный документ для срочного исправления копий в производстве (чтобы не было брака), пока не готово основное ИИ (вполне можно оформить по определенной форме электронным письмом).
- Извещение об изменении (ИИ) — основной документ для внесения изменений в подлинники. Выпускает только организация-держатель подлинников.
- Для опытных образцов, единичных изделий или внутренней технологической оснастки можно обойтись без ИИ, ведя Журнал изменений. Но это — только для «домашнего использования», когда вся работа ведётся в одной организации.
Конечно, это только база, к тому же немного адаптированная. Для более глубокого знакомства рекомендую ознакомиться с оригиналами документов — там читать не очень много.
Учет, классификация, контроль и ведение единой базы
Итак, чтобы внесение изменений из хаоса превратилось в порядок, нужно разработать и ввести в употребление следующие процессы:
- управление внутренними изменениями,
- управление внешними изменениями.
Например, оформить стандарт организации, далее ознакомить с ним всех участников и жестко карать за необоснованные отклонения. Ну это лирика.
Главная мысль стандарта (одной фразой): каждая правка должна быть документирована, учтена, согласована и не должна ломать то, что уже работает.
Вот что должно быть конкретизировано.
Ну во-первых, перечень документов, изменения которых должны фиксироваться, далее учитываться и, внимание, рассылаться по списку заинтересованным лицам. Актуальные для проекта должны фиксироваться в общедоступном реестре. Естественно, это исходные данные, рабочие письма, протоколы совещаний и т. д.
Сейчас достаточно много программных продуктов, позволяющих автоматизировать данный документооборот. Конечно, можно все делать вручную, через таблички Excel и скрипты — но насколько это для крупного проекта будет работать и дополнительно нагружать ГИПа?
А система должна быть простой, чтобы в ней мог разобраться внештатник Петя, который неожиданно для себя стал почетным членом рабочей группы по проектированию нашего архиважного объекта.
Журнал изменений, куда сводятся и группируются все правки: внешние и внутренние. Механизмы создания записей и их утверждение или отклонение (а такое тоже возможно). Уведомление о новых утвержденных записях всех причастных, а по-хорошему учет статусов: принят, взят в работу, учтен в ревизии и/или изменении.
Существование документа ведь также осуществляется в рамках жизненного цикла: от создания, до помещения в архив (или даже аннулирования с заменой). И важно зафиксировать, когда от внутреннего черновика в рабочей папке проектировщика он переходит к подростковому возрасту и далее — в зрелость.
Не раз у меня были дискуссии на тему редакций и изменений. Это у европейцев все просто — генерируют новую редакцию с последующей буквой алфавита (на каждом листе), вносят в перечень, все. У нас же любят добавлять просто дату редактирования к названию файла. Ну а «изм» — это вообще только для экспертизы. Однако у такого способа есть существенный минус — сама по себе дата не содержит информации о том, какая это итерация, ее сложно учитывать и соотносить с журналом изменений, наконец, трудно отличить от какого-то промежуточного исправления. Особенно, если кроме файла с названием «ХХХХ_24.10.08» в полях ничего нет. Пометки на листах у нас тоже не любят делать — вот и гадай, что у тебя на руках: боевая версия или какой-то черновик, который прислали смежнику чисто посмотреть.
Конечно, конкретику определяет каждая организация сообразно общей технологии и имеющимся инструментам. Да, это требует дисциплины и иногда кажется избыточным. Но именно эта дисциплина отделяет профессиональную проектировочную организацию от сборища «творческих людей», чей полет мысли заканчивается дорогостоящим конфузом на стройплощадке. В конечном счете, управление изменениями — это не про бумажки. Это про предсказуемость результата, сбереженные нервы и деньги, и то самое уважение к труду коллег, о котором мы говорили вначале.
Источники, дополнительная информация:
- Градостроительного кодекса Российской Федерации от 29.12.2004 № 190-ФЗ
- ГОСТ 21.101-2020 «СПДС. Основные требования к проектной и рабочей документации»
- ГОСТ 2.503-2013 «ЕСКД. Правила внесения изменений»
- ПКО-2010.3 Тяжпромэлектропроект. Руководство по внедрению ГОСТ Р 21.1101-2009 в части правил внесения изменений в рабочую и проектную документацию, переданную заказчику, 2010
Ознакомиться с содержанием журнала.
Уважаемые коллеги, желаю хорошего дня. Подписывайтесь, чтобы иметь возможность обсудить со мной вашу задачу в комментариях. Буду рад лайку, альтернативному мнению или истории по теме статьи. При желании вы можете поблагодарить автора чашкой кофе для стимулирования мыслительного процесса и блогерского энтузиазма.
ПРЕДУПРЕЖДЕНИЕ №1: Оценки, суждения и предложения по рассматриваемым вопросам являются личным мнением автора.
ПРЕДУПРЕЖДЕНИЕ №2: Техническая информация, представленная на сайте, не является официальной и предоставлена только в целях ознакомления. Владелец сайта не несет никакой ответственности за риски, связанные с использованием информации, полученной из данного источника.
Все изображения, если не указано иное, либо выполнены автором, либо взяты из открытых источников.