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

Краткий пример разобщенности коллектива, не так уж и редко встречающийся на практике. Некий "специалист" создаёт план здания. Ещё "сырой" файл (сроки "горят" всегда) высылается нам для проектирования систем безопасности. КСБ-шник вставляет его через внешнюю ссылку, в листе оформляет свой чертёж в нестандартном масштабе (план чуть-чуть не влез в формат, а брать бОльшего размера ему не захотелось) и в нулевом слое, опять же в листе, расставляет УГО (условные графические обозначения) оборудования, связывая его раскрашенными в разные цвета линиями кабельных трасс (красная - шлейф, синяя - питание и т.п.). Ещё чаще - внешней ссылкой не пользуются, чертят прямо поверх полученного плана, в том слое, который оказался текущим на момент получения файла.

В какой-то момент приходит очередная редакция плана здания, его помещают в папку внешних ссылок. Открывают свой чертёж и видят в нём перечёркнутое изображение. Оказалось, автор выполнил новую версию плана в новом месте своей модели, а старую перечеркнул (в лучшем случае). У всех, кто стоит в цепочке проектирования дальше, появилась проблема. Она небольшая, требуется подвинуть внешнюю ссылку, но могла и не возникать.

КСБ-шник отправил свой файл проектировщику, который будет сводить сети. Для начала его задачей будет отделить мух от котлет (всё ж в одном слое, да ещё и в листе), нередко - привести к действительному масштабу. И так по каждой инженерной системе. После сведения сетей будут определены узкие мета, выданы замечания, получены обновлённые варианты, и процесс чистки, приведения к масштабу и т.д. и т.п. повторится снова, и снова, и снова...

Описанное выше - не плод больного воображения. Это повседневная практика ряда фирм, с которыми я работаю. Потери труда на этапах преобразования чертежей огромны, а ведь их можно избежать, если уметь использовать AutoCAD и придерживаться неких правил совместной работы.

Цикл статей назван "Стандарт организации". В него сведены различные правила организации труда проектировщиков. Руководитель одного из проектных отделов говорит подчинённым примерно так: "Даже если требования являются спорными, важно то, что они едины для всех нас. Выпускавшаяся ранее документация "кто в лес, кто по дрова" гораздо хуже". Согласитесь, что отсутствие единого стиля работы явным образом указывает на шараш-монтаж-контору, неспособную навести элементарный порядок.

Текст статей далее построен в следующем виде: описание требования, под спойлером - его обоснование или пример, то есть почему требуется делать именно так. Объёмные обоснования оставлены прямо в тексте статьи. Чтобы они не мешали в дальнейшем использовать стандарт, в конце раздела приведена выборка требований, копия которой также представлена в файле для скачивания и адаптации под Вашу организацию.

Стандарт "живой", делается сразу под несколько организаций, поэтому замечания коллег принимаются и даже приветствуются. Как говорили раньше, "марксизм - не догма"... Даже ГОСТ 21.101 (ГОСТ Р 21.1101) меняется раз в несколько лет.

В качестве отправной точки для написания данного стандарта мною использован файл "Предложения по стандартизации проектирования с использованием продукции компании Autodesk на предприятии", автор Кулик Алексей. Последняя правка там датирована 12.11.2004, возможно, поэтому в нём масса положений, которые применять либо просто нельзя, либо я с ними не согласен. Да и оформлен этот документ с кучей нарушений. Желающие могут сравнить наши версии и поискать общие положения.

Под проектом здесь и далее понимается как совокупность разделов проекта, так и совокупность основных комплектов рабочих чертежей.