CADmaster

При общении с потенциальными заказчиками иногда приходится отвечать на вопрос, почему «технический» документооборот на порядок дороже обычного «офисного». В зависимости от спрашивающего, ответ может быть как простым и односложным, например, «они функционально намного сложнее», так и не совсем печатным, но вполне объясняющим разницу в весовой категории этих типов ИУС. Если отбросить плоский юмор, системы управления техническим документооборотом выделяются тем, что в них:

• первичны не файлы, а информационные объекты, которые могут содержать неограниченное количество файлов любого типа. Более того, в продвинутых системах типа TDMS файлы могут быть размещены с сохранением иерархической структуры. Это нужно для того, чтобы, не нарушая внутренние связи технического документа, загрузить его в объект системы со всеми вспомогательными файлами, которые требуются приложению САПР;
• для описания свойств объектов используется большое количество атрибутов, среди которых не только простые свойства типа строк, списков и чисел, но и сложные свойства, такие как ссылки на другие информационные объекты и табличные свойства. Например, в типичной СЭТД количество атрибутов у «Проектного документа» более 100, из них два десятка табличных свойств;
• объекты используются для хранения не только свойств документов, но и любых других сущностей, включая справочники, элементы цифровых моделей, сущностей для управления проектами и т.п., связанных между собой как связями типа «ссылается на», так и «содержит», то есть связями «родитель-потомок», образующими иерархию объектов;
• применяются сложные ролевые модели: права доступа назначаются, как правило, не на конкретных исполнителей, а на производственные подразделения или на так называемые «дисциплины», то есть группы пользователей, обладающих определенными компетенциями в рамках своих проектных специальностей. Впрочем, об этом речь пойдет в отдельной статье.

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

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

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

К сожалению, следует признать, что в русскоязычной технической литературе и стандартах по электронному документообороту существует некоторый терминологический произвол. Согласно 2.051−2013 (ЕСКД), «версия документа — электронный документ, соответствующий определенной стадии (этапу разработки документа)». Согласитесь, более странную формулировку сложно придумать. Если сделать над собой усилие и вдуматься в написанное, можно с некоторой вероятностью понять, что хотели сказать авторы. Но это не точно. В ГОСТе 21.101−2020 (СПДС) авторы, видимо, руководствуясь «бритвой Оккама», вообще не стали давать определение версии и между строк приравняли ее к «изменениям».

Поскольку мы в рамках данной статьи хотим объяснить, как работает TDMS при внесении изменений и как это применяется на практике, нам все-таки придется дать все нужные определения. Не претендуя на абсолютную истину, просто постепенно введем здесь нужную нам терминологию.

Информационный объект — это базовая сущность информационной системы в общем случае и системы управления техническим документооборотом в частности, описывающая различные виды объектов, предметов, процессов, материальных или нематериальных явлений и обладающая определенными свойствами: графическим и текстовым представлениями в системе; типом; статусом; наборами атрибутов, файлов, подписей; а также различными связями этой сущности с другими объектами системы. Проекты, Разделы, Чертежи, Комплекты, Задачи — это в терминологии TDMS типы информационных объектов, обладающие различными свойствами, включая версионность.

Частным случаем информационного объекта является электронный документ. Большинству людей проще воспринимать слово «документ», но мы будем использовать его только когда станем говорить об электронных документах, потому что в TDMS нет каких-то особенных «документов», все они в системе являются такими же информационными объектами, как и другие сущности. К слову сказать, в большой информационной системе типов документов тоже много. Отдельные типы объектов используются для хранения информации о проектных документах, чертежах, заданиях, сметах и т.п.

Итак, в контексте информационной системы версия является копией информационного объекта (в частном случае — электронного документа), созданной для фиксации его состояния. Это очень похоже на определение в ГОСТе 2.051−2013, но без использования терминов «стадия», «этап» и т.п. Строго говоря, нам все равно, в результате чего появились новые версии документа: вследствие изменения объекта, его отправки в письме или передачи на согласование. Многократное сохранение версий документа в процессе его согласования нельзя назвать процессом смены «стадий». Стадия будет одна, но ее несколько раз придется пройти заново.

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

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

И наоборот, если тип информационного объекта не предполагает создания версий при его изменении, мы используем для данного объекта только один экземпляр. Одна версия создается в самом начале, и она же при необходимости модифицируется. Но это тоже версия, так как каждый экземпляр документа является версией (то есть обладает полным набором свойств версии — номером, наименованием, датой создания и т.п.). Совокупность всех версий (экземпляров) информационного объекта мы кратко называем «информационным объектом».

Кроме версий есть еще важное понятие в техническом документообороте — «изменение», сокращенно именуемое «изм.». Важно понимать отличия версий и «измов».

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

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

Давайте теперь от голой теории перейдем к практике и покажем процесс внесения изменений. В этой точке наша статья как бы раздваивается. Все, что описано ниже, будет интересно всем, кто так или иначе связан с проектированием объектов промышленного и гражданского строительства. А в следующей «версии» статьи мы углубимся в физическое устройство версионности TDMS. Эта статья будет интересна ИТ-специалистам и разработчикам на платформе TDMS, число которых неизменно растет.

Применяемые термины

ГИП — главный инженер проекта.

Проектная продукция (ПП) — разрабатываемые на разных стадиях проектирования тома и основные комплекты, передаваемые Заказчику.

Группа управления проектом (ГУП) — группа пользователей и одноименная роль в системе, состоящая из ГИПа и его помощников.

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

Заявка на изменение (ЗИ) — информационный объект, предназначенный для сбора всех изменений ПП, выполненных по одной первоначальной причине. Заявка на изменение, как правило, содержит входящие документы, на основании которых инициируется процедура изменения ПП, и описание причин внесения изменений. Без оформления ЗИ невозможно дальнейшее оформление РИ ни одной из дисциплин, участвующих в проекте.

Файл публикации — файл формата PDF, полученный путем преобразования редактируемой версии файла (DOC, XLS, DWG и т.д.) и предназначенный для обмена документами в электронном виде в ходе внутреннего согласования и печати на бумажный формат. Подписанный электронной подписью файл публикации может использоваться как полноценная замена бумажному подлиннику.

Файл подлинника — файл в формате PDF или TIFF, полученный путем сканирования подписанных собственноручной подписью бумажных документов и предназначенный для архивного хранения, тиражирования и передачи Заказчику готовой проектной продукции в электронном виде.

Общая схема процесса

Рис. 1. Общая схема внесения изменений в разработанную ПП

На рис. 1 представлена общая схема процесса.

Процесс внесения изменений, как правило, начинается с того, что у Заказчика «поменялась концепция». Несмотря на некоторую шуточность данного утверждения, если вы считаете, что основной причиной изменений в ПП всегда являются ошибки проектирования, то вы глубоко ошибаетесь. Изменение технических требований, замена оборудования, его компоновки и расположения или просто «внезапное озарение» Заказчика часто служат основной причиной изменений.

Заявка на изменение

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

Рис. 2. Документы, на основании которых формируется ЗИ

Обычно такого документа достаточно, чтобы на его основе принять решение о необходимости внесения изменений в тот или иной Том/Комплект, но необходимо учесть ряд нюансов:

• инициирующих документов по одной теме может быть несколько, и об этом должен быть оповещен специалист, принимающий решение о внесении изменений;
• при внесении изменений одновременно в несколько проектных документов по одной причине необходимо проконтролировать, чтобы во всех разрешениях на внесение изменений (РИ) были указаны одинаковые причины изменений и даны ссылки на один источник изменений. Это необходимо, чтобы аналитика сбора информации по причинам изменений работала корректно;
• в системе должны быть инструменты, которые позволят свести воедино все изменения по одной инициирующей причине и посчитать суммарную стоимость изменений;
• нужно учитывать, что входящего документа может не быть, и решение о внесении изменений принято проектировщиком по какой-либо причине самостоятельно.

Чтобы решить все вышеуказанные вопросы, мы ввели специальный информационный объект «Заявка на изменение» (ЗИ). Наиболее близким по смыслу к ЗИ в ЕСКД является «Предварительное извещение».

Составление ЗИ входит в зону ответственности группы ГИПа (ГУП), где ГИП или его помощники указывают причины внесения изменений, описывают сами возможные изменения (при необходимости), а также могут рекомендовать или ограничить список изменяемой ПП.

Рис. 3. Заявка на изменение

Сформированная заявка (рис. 3) утверждается ГИПом и рассылается всем ответственным лицам производственных подразделений, которые на ее основе принимают решение о необходимости внесения изменений в выпущенную ими ПП.

Оповещение ответственных лиц происходит по почте TDMS с прикреплением ссылок на ЗИ.

Разрешение на внесение изменений

Если с ЗИ все относительно просто, то с «Разрешением на внесение изменений» (РИ) путь немного длиннее.

На одну ЗИ формируется столько РИ, сколько Томов/Комплектов будет изменено. Специалисты производственных подразделений рассматривают заявку, выявляют необходимость внесения изменений и либо создают РИ, либо нет (рис. 4).

Рис. 4. Схема данных по вносимым изменениям

Процесс привязки новых РИ продолжается до тех пор, пока данное ЗИ не будет «закрыто» ГИПом, и тем самым будет сформирован пакет изменений по текущей заявке. Одновременно в системе может быть открыто любое количество ЗИ.

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

Рис. 5. Заполненная карточка «Разрешения на внесение изменений»

Теперь в работу вступает маршрутный движок, который на основе выбранного маршрута согласования проводит сформированное РИ по процессу, оповещая участвующих лиц и переходя от шага к шагу по изображенной на рис. 6 схеме процесса.

Рис. 6. Выбор маршрута согласования РИ

Когда ГИП на утверждающем шаге скажет: «Утвердить», РИ будет переведено в соответствующий статус, а разработчик Тома/Комплекта сможет начать вносить изменения.

Виды внесения изменений

В системе предусмотрено три вида внесения изменений в Тома/Комплекты:

• Замена (зам.) — вид внесения изменений, при котором заменяются все листы текущего Тома/Комплекта, при этом его обозначение остается прежним, а номер изменения и инвентарный номер присваиваются новые;
• Изменение (изм.) — вид внесения изменений, при котором изменяется или заменяется часть листов текущего Тома/Комплекта, при этом его обозначение и инвентарный номер остаются прежними, а номер изменения увеличивается на единицу;
• Аннулирование (анн.) — вид внесения изменений, при котором ранее выпущенный документ со всем его составом аннулируется, то есть перестает быть действующим.

При внесении изменений создается новая версия Тома/Комплекта, а документы состава «прокидываются» из предыдущей версии и также могут быть изменены в новой, при этом в предыдущей версии останется состав, актуальный до внесения текущих изменений, а в текущей будут как измененные, так и неизмененные, а также вновь созданные листы (рис. 7).

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

Рис. 7. Состав комплекта «до» и «после»

Проанализировав работу пользователей Заказчика в системе, а также их обращения в службу поддержки, мы выяснили, что самой распространенной ошибкой при внесении изменений является неверное определение вида внесения изменения («изм.» или «зам.») на начальном этапе (при разработке РИ). Данная ошибка пользователей приводит к необходимости корректировки и повторного согласования РИ с откатом всех произведенных изменений.

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

Изменение документов состава

Документы состава изменяются «поштучно», каждый отдельной контекстной командой, конечно, если это не аннулирование целого Тома/Комплекта.

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

На основе внесенных изменений ответственный проектировщик должен указать их влияние на изменение сметной стоимости в отдельном атрибуте (рис. 8).

Рис. 8. Информация о внесенных изменениях в Томе/Комплекте

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

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

Процесс сдачи документации в архив аналогичен первичной сдаче с тем лишь дополнением, что вместе со сдаваемым Томом/Комплектом по процессу шагает РИ, оформленное при взятии этого самого Тома/Комплекта. Процессный движок ведет по процессу уже два информационных объекта, а при принятии своего шага архивом закрывает РИ, переводит текущую версию Тома/Комплекта и его состав в статус «Действующий» (или «Аннулирован»), а предыдущую версию из статуса «Действующий (на изменении)» в «Недействующий».

Внесение изменений в сметную документацию

Сметная документация может изменяться как по воле сметчиков (например, если они сами обнаружили какие-то ошибки или неточности и корректировки связанных Томов/Комплектов не требуется), так и по инициативе проектировщиков, если внесенные в Том/Комплект изменения имеют конечное отражение в рублях.

В первом случае при внесении изменений в сметную документацию сметчик обычным образом создает РИ, а вот во втором случае оформления отдельного РИ для выпуска измененных сметных документов не требуется и изменение происходит по РИ измененного основного Тома/Комплекта.

Изменяя и заменяя сметы, сметчики привязывают их к актуальным «осмечиваемым» версиям Томов/Комплектов. Такая привязка позволяет отследить стоимости «до» и «после» и на основании этого рассчитать изменение стоимости по каждой из статей.

Оценка стоимости изменений

При формировании сметных документов сметчиком или сметной программой в карточку самой сметы вносится информация по следующим статьям (рис. 9):

• строительные работы;
• монтажные работы;
• оборудование, мебель, инвентарь;
• прочие расходы;
• итого.

Рис. 9. Смета к измененному комплекту

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

Итак, разместив в системе новые сметы, можно запустить формирование отчета по изменению сметной стоимости. Данный отчет формируется с ЗИ (еще не забыли, для чего мы ее вводили?) и показывает все измененные по нему Тома/Комплекты, а также позволят оценить «стоимость» изменений, внесенных по одной причине (рис. 10).

Рис. 10. Отчет по изменению стоимости для одного измененного комплекта

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

Чтобы не перегрузить вас информацией, самое время остановиться и анонсировать следующую статью. Она также будет посвящена версиям, но мы рассмотрим их уже со стороны возможностей визуальной настройки и программирования API TDMS. Там же, в следующей статье, подведем итоги обеих частей.

До скорой встречи!

Скачать статью в формате PDF — 1.89 Мбайт