Vault + Inventor выпуск КД: статусы, согласование, спецификации

Почему выпуск КД в Vault часто превращается в ручную рутину

Когда Vault и Inventor используются «как получилось», выпуск КД быстро обрастает привычками: переименовать файл, сделать копию в папку «Выпуск», добавить суффикс _R1, разослать PDF по почте. Сначала это кажется быстрым, но через пару месяцев такие действия начинают мешать: появляются дубли, теряются связи, а ошибки сложно отследить.

Чаще всего рутина начинается с попытки управлять статусом документа через имя файла и папки. Инженер меняет название, чтобы показать «согласовано» или «выпущено», а Vault видит просто новый файл или новый путь. Поиск начинает выдавать копии, в проекте появляются «финал_финал2», а ссылки между моделью и чертежом легко ломаются после копирования.

Отдельная боль - ревизии. Если повышают ревизию только у чертежа, а 3D-модель остается прежней, спецификация и PDF быстро начинают жить в разных «версиях правды». Позже кто-то открывает сборку и получает актуальную модель, но печатает старый чертеж, потому что он лежит в другой папке и назван «правильно». Так и появляется путаница между моделью, чертежом и ведомостями.

Параллельная работа нескольких инженеров усиливает проблему. Без понятных статусов и правил согласования обычно происходит одно и то же: два человека правят одну деталь, кто-то выпускает PDF, пока другой еще меняет размеры, в сборку подтягиваются черновые компоненты, а согласующий смотрит не тот файл.

При нормальной настройке процесс становится предсказуемым: статус виден без переименований, ревизия фиксируется одинаково для связанных документов, а PDF и спецификации выходят по одному сценарию. Документы проще искать, ошибки быстрее находить, а время уходит на проектирование, а не на перекладывание файлов.

Базовые понятия: статус, ревизия и жизненный цикл

В Vault легко запутаться, если смешать три разные вещи: обозначение (номер документа), имя файла и то, как объект «называется» в проекте. Имя файла нужно системе и людям для хранения и поиска. Обозначение нужно для выпуска КД и обычно попадает в основную надпись. Обозначение вполне может жить в свойстве и не обязано совпадать с именем файла. Если вы жестко связываете эти вещи, любая правка превращается в ручные переименования.

Статус и ревизия отвечают на разные вопросы.

Статус показывает, где документ находится в процессе прямо сейчас: в работе, на проверке, согласован, выпущен, устарел.

Ревизия показывает, сколько раз вы выпускали изменения как официальную версию КД. Статус может меняться много раз без изменения ревизии. Ревизия повышается только когда вы фиксируете изменение и выпускаете новый комплект.

Жизненный цикл в Vault - это набор статусов и правил переходов между ними. К нему привязываются права и маршруты: кто может отправить на проверку, кто может утвердить, кто может вернуть на доработку. Чем меньше исключений, тем меньше ручных действий и тем проще объяснить процесс новичку.

В выпуске обычно участвует связка: 3D-модели (детали и сборки), 2D-чертежи, спецификация (BOM) и производные файлы вроде PDF/DXF/STEP. Важно сразу решить, что именно вы считаете «комплектом выпуска», и выпускать это как единое целое.

Что определить до настройки: роли, правила и формат выпуска

Прежде чем настраивать статусы и жизненные циклы, договоритесь о правилах. Иначе Vault будет «правильно» работать, но по-разному для каждого, а это быстро приводит к обходным путям.

Сначала определите роли и ответственность: кто разрабатывает, кто проверяет, кто отвечает за нормоконтроль, кто имеет право выпускать. Важно заранее решить, где ставится финальное «ОК», потому что под это строятся права на смену статусов и выпуск.

Дальше зафиксируйте схему ревизий. Выберите один формат (буквы или числа) и не смешивайте их. Затем запишите простое правило: когда повышается ревизия, а когда меняется только статус. Например, опечатка в примечании без влияния на изделие - это обычно та же ревизия, но документ можно вернуть «на доработку». А вот изменение размера, материала, посадки или состава изделия - это новая ревизия.

Отдельно согласуйте выходные форматы, которые считаются выпуском. Обычно это PDF для просмотра, BOM в согласованном формате, и при необходимости DXF/STEP для производства или подрядчиков. Именно здесь чаще всего появляются ручные экспорты, копии и «правильные» имена файлов.

И наконец - обязательные атрибуты, которые заполняются всегда. Минимум: обозначение, наименование, материал, масса, разработал/проверил, формат, лист/листов.

Если нужны опорные вопросы для регламента, хватит пяти:

• Кто имеет право переводить документ в «Выпущено».
• Какая схема ревизий используется и где она хранится (в свойствах, а не в имени файла).
• Какие изменения требуют новой ревизии, а какие только смены статуса.
• Какие форматы выдачи обязательны.
• Какие свойства должны быть заполнены до проверки.

Схема статусов: короткая и понятная

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

Базовый вариант:

• Черновик: конструктор редактирует, собирает состав, заполняет свойства.
• На проверке: правки возможны только после возврата; проверяющий фиксирует замечания.
• На согласовании: документ готов, идет формальное согласование.
• Выпущено: изменения запрещены, доступна выдача в производство и формирование производных файлов.
• Архив: документ выведен из актуальной работы, хранится для истории.

Сразу задайте правила переходов. Если все могут переводить все, статусы становятся ярлыками. На практике обычно работает простое разделение: конструктор отправляет на проверку, проверяющий переводит дальше или возвращает, ответственный согласующий выпускает.

Для возвратов удобно иметь отдельный статус «На доработке» и требовать заполнить комментарий с причиной возврата. Так видно, почему документ вернули и что исправляли.

Для статуса «Выпущено» имеет смысл включить запрет на изменения и запрет на «тихую замену» файлов. Если нужно изменить выпущенное, путь один: оформить изменение и выпустить новую ревизию.

Ревизии без путаницы: когда повышать и как фиксировать изменения

Ревизия должна отражать управляемое изменение, а не каждое сохранение файла. В Vault версия растет при любом сохранении, а ревизия меняется только когда вы осознанно фиксируете новый выпуск.

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

Причину изменения лучше хранить там, где она не потеряется: в свойствах/карточке Vault и в комментарии к фиксации. Комментарий должен быть коротким и понятным: что изменили и почему.

Связка модель - чертеж - спецификация

Путаница начинается, когда деталь в одной ревизии, чертеж в другой, а BOM «живет отдельно». Рабочее правило простое: выпускается комплект, и ревизия у него одна.

Перед повышением ревизии проверьте, что 3D-модель и 2D-чертеж соответствуют друг другу, BOM пересчитана, а все связанные файлы переводятся в нужный статус одним действием (набором/пакетом, а не по одному).

Архив и поиск старых ревизий

Не храните старые ревизии в отдельных папках «на всякий случай» и не делайте копии вручную. Правильный архив - это прошлые состояния в Vault: доступные для просмотра и сравнения, но защищенные от правок. Тогда легко понять, что было выпущено в Rev.A, чем отличается от Rev.B и почему это произошло.

Как уйти от ручных переименований: свойства и шаблоны

Ручные переименования почти всегда начинаются с одной ошибки: обозначение и наименование пытаются держать в имени файла. Надежнее, когда ключевые данные живут в свойствах (iProperties и свойствах Vault), а имя файла остается стабильным.

Сделайте так, чтобы в штампе, спецификации и PDF подтягивались поля «Обозначение», «Наименование», «Материал», «Масса», «Ревизия» именно из свойств. Тогда при изменении текста или версии не придется трогать имя файла и ломать ссылки в сборках.

Чтобы новые файлы создавались одинаково, используйте шаблоны и автонумерацию. Полезный минимум: резервирование номера при создании, обязательные свойства перед отправкой на согласование и правило «ревизия повышается в процессе выпуска, а не переименованием файла».

Со структурой папок тоже лучше не усложнять. Достаточно базовой дисциплины: один проект - одна корневая папка, стандартные компоненты отдельно и только для чтения, никаких копий через проводник (только операции Vault).

Выпуск PDF и спецификаций: сделать процесс повторяемым

Сначала договоритесь, что именно считается комплектом выпуска. Обычно это исходники (чертежи и модели) плюс неизменяемые производные файлы: PDF и BOM в согласованном формате. При необходимости добавляются STEP/DXF.

Ключевое правило: переводить в «Выпущено» только после проверки зависимостей. Потерянные ссылки, локальные файлы вне Vault или не обновленные чертежи гарантированно приведут к набору, который нельзя повторить и сложно доказать.

Дальше помогает автоматизация по событию смены статуса: при переводе в «Выпущено» система формирует PDF и выгрузку BOM и кладет их туда, где их нельзя править вручную (отдельная зона «выпущенных копий» с правами только на чтение). Тогда не нужно каждый раз «вспоминать, как делали в прошлый раз».

Самая частая ловушка здесь - несоответствие BOM ревизии сборки. Спецификацию нужно выпускать из той же ревизии, что и комплект чертежей, и хранить как часть выпуска.

Типовые ошибки при настройке

Первая причина «вечного бардака» в PDM - когда команда не договорилась, что означает статус и что означает ревизия. Статус - это этап процесса. Ревизия - это зафиксированный выпуск. Если их смешать, ревизии начинают повышать «для прогресса», и история теряет смысл.

Вторая ошибка - кодировать ревизию в имени файла. Стоит переименовать модель или чертеж, и где-то обязательно порвутся ссылки: в сборке, чертеже, спецификации или шаблонах. Надежнее держать идентификаторы в свойствах, а имя файла не дергать.

Третья проблема - выпускать только то, что «видно» заказчику (PDF/DWG), оставляя модель в работе, или наоборот. Проверяйте связку «модель - чертеж - спецификация - публикации» как единый комплект.

И наконец, обходные копии и «тихие правки»: скачать, изменить вне системы и загрузить обратно. Это убивает доверие к Vault. Лучше заранее определить понятный путь: замечания, возврат на доработку, повторная проверка, выпуск новой ревизии.

Короткий чек-лист перед выпуском

Перед переводом комплекта в «Выпущено» достаточно 3-5 минут на проверку. Это почти всегда экономит часы на разборе «почему в производстве не та версия».

• Проверьте свойства модели и чертежа: обозначение и наименование заполнены в свойствах и попадают в штамп.
• Убедитесь, что у сборки нет потерянных ссылок, и что получены последние версии из Vault.
• Сверьте ревизию у ключевых файлов: сборка/модель, чертеж, BOM должны совпадать.
• Проверьте права: выпуск должен быть доступен только тем, кто реально имеет право выпускать.
• Убедитесь, что PDF и BOM сформированы заново из текущего состояния и лежат в согласованном месте для производства и снабжения.

Если важна прослеживаемость (например, для крупных предприятий и проектов с формальным контролем), такой чек-лист лучше закрепить как обязательное правило.

Пример сценария: выпуск и ревизия без перекладки файлов

Есть узел: 8 деталей, 1 сборка, 1 чертеж и 1 спецификация. Задача: выпустить ревизию A, получить замечания, исправить одну деталь и выпустить ревизию B без копирования и переименований.

Сценарий выглядит так:

1. Инженер завершает модель и чертеж, заполняет свойства и отправляет комплект на проверку/согласование. Имя файла не меняется, меняются свойства и статус.

2. После утверждения комплект переводится в «Выпущено». На этом шаге фиксируется ревизия A, а PDF и BOM формируются как производные файлы и привязываются к выпуску.

3. Поступает замечание. Инженер берет рабочую копию (check-out), меняет модель, обновляет чертеж, возвращает изменения (check-in) и оставляет понятный комментарий: что изменено и почему.

4. Комплект снова проходит те же статусы, и при повторном выпуске ревизия повышается до B. Vault хранит обе ревизии, а производные файлы пересоздаются именно для B.

Дальше нужная версия ищется не по имени файла, а по свойствам: обозначение, наименование, ревизия, статус и дата выпуска.

Следующие шаги: пилот и закрепление процесса

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

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

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