При общении с потенциальными заказчиками иногда приходится отвечать на вопрос, почему «технический» документооборот на порядок дороже обычного «офисного». В зависимости от спрашивающего, ответ может быть как простым и односложным, например, «они функционально намного сложнее», так и не совсем печатным, но вполне объясняющим разницу в весовой категории этих типов ИУС. Если отбросить плоский юмор, системы управления техническим документооборотом выделяются тем, что в них:
Еще одним ключевым отличием рассматриваемых типов систем является то, каким образом они обращаются с версиями. Именно этому посвящена данная статья: в первой ее части мы расскажем о том, как устроен механизм работы с изменениями в нашей системе технического документооборота, а во второй речь пойдет о том, как работает версионность в TDMS в целом.
В офисном документообороте версии — это копии одиночных документов, которые чаще всего организованы в виде цепочки (списка) связанных между собой версий, реже представлены в виде дерева версий. В некоторых системах версии могут быть самостоятельными сущностями, то есть допускается одновременное применение нескольких версий; в других системах во избежание путаницы пользователи работают только с активными версиями, а их «независимые» альтернативы имеют статус самостоятельных документов.
В техническом документообороте документы имеют составную, иерархическую структуру, и версии одного комплекта документов (то есть составного документа) могут иметь в своем составе не только разные версии документов, но и разное их количество. Более того, номера версий документов в составе комплекта могут сильно отличаться. Какой-то документ может оставаться неизмененным с момента создания, а другой — претерпеть несколько изменений. При этом, очевидно, система управления техническим документооборотом должна иметь возможность сравнивать не только версии «листовых» документов, но и предоставлять пользователю возможность видеть отличия изменений в составе комплекта.
К сожалению, следует признать, что в русскоязычной технической литературе и стандартах по электронному документообороту существует некоторый терминологический произвол. Согласно 2.051−2013 (ЕСКД), «версия документа — электронный документ, соответствующий определенной стадии (этапу разработки документа)». Согласитесь, более странную формулировку сложно придумать. Если сделать над собой усилие и вдуматься в написанное, можно с некоторой вероятностью понять, что хотели сказать авторы. Но это не точно. В ГОСТе 21.101−2020 (СПДС) авторы, видимо, руководствуясь «бритвой Оккама», вообще не стали давать определение версии и между строк приравняли ее к «изменениям».
Поскольку мы в рамках данной статьи хотим объяснить, как работает TDMS при внесении изменений и как это применяется на практике, нам все-таки придется дать все нужные определения. Не претендуя на абсолютную истину, просто постепенно введем здесь нужную нам терминологию.
Информационный объект — это базовая сущность информационной системы в общем случае и системы управления техническим документооборотом в частности, описывающая различные виды объектов, предметов, процессов, материальных или нематериальных явлений и обладающая определенными свойствами: графическим и текстовым представлениями в системе; типом; статусом; наборами атрибутов, файлов, подписей; а также различными связями этой сущности с другими объектами системы. Проекты, Разделы, Чертежи, Комплекты, Задачи — это в терминологии TDMS типы информационных объектов, обладающие различными свойствами, включая версионность.
Частным случаем информационного объекта является электронный документ. Большинству людей проще воспринимать слово «документ», но мы будем использовать его только когда станем говорить об электронных документах, потому что в TDMS нет каких-то особенных «документов», все они в системе являются такими же информационными объектами, как и другие сущности. К слову сказать, в большой информационной системе типов документов тоже много. Отдельные типы объектов используются для хранения информации о проектных документах, чертежах, заданиях, сметах
Итак, в контексте информационной системы версия является копией информационного объекта (в частном случае — электронного документа), созданной для фиксации его состояния. Это очень похоже на определение в ГОСТе 2.051−2013, но без использования терминов «стадия», «этап»
Версии делятся на активные (актуальные) и неактивные (неактуальные). С активными версиями работают пользователи при внесении изменений, согласовании, передаче смежникам
Версий у документа может быть столько, сколько требуется для обеспечения процесса управления его жизненным циклом. Например, регламент разработки может требовать создания версии на каждом шаге внесения изменений в документ после получения замечаний от заказчика, смежников, нормоконтроля
И наоборот, если тип информационного объекта не предполагает создания версий при его изменении, мы используем для данного объекта только один экземпляр. Одна версия создается в самом начале, и она же при необходимости модифицируется. Но это тоже версия, так как каждый экземпляр документа является версией (то есть обладает полным набором свойств версии — номером, наименованием, датой создания
Кроме версий есть еще важное понятие в техническом документообороте — «изменение», сокращенно именуемое «изм.». Важно понимать отличия версий и «измов».
«Изм.» — это версия, передаваемая заказчику. Вашему контрагенту — заказчику, подрядчику строительства, ведомственной или государственной экспертизе — все равно, сколько промежуточных версий документа у вас было создано в процессе его разработки и согласования. Их интересует только то количество изменений, которое было в вашем с ними документообороте.
В западных системах PDM используется такая же схема работы. Версии являются объектами системы. Они, например, могут создаваться каждый раз при внесении в документ изменений. А «ревизии» (revision), которые являются аналогами наших «изменений», создаются исключительно в результате определенного бизнес-процесса. То есть кто-то принимает решение о необходимости сохранения документа в текущем состоянии и запускает процесс внесения изменений.
Давайте теперь от голой теории перейдем к практике и покажем процесс внесения изменений. В этой точке наша статья как бы раздваивается. Все, что описано ниже, будет интересно всем, кто так или иначе связан с проектированием объектов промышленного и гражданского строительства. А в следующей «версии» статьи мы углубимся в физическое устройство версионности TDMS. Эта статья будет интересна ИТ-специалистам и разработчикам на платформе TDMS, число которых неизменно растет.
ГИП — главный инженер проекта.
Проектная продукция (ПП) — разрабатываемые на разных стадиях проектирования тома и основные комплекты, передаваемые Заказчику.
Группа управления проектом (ГУП) — группа пользователей и одноименная роль в системе, состоящая из ГИПа и его помощников.
Разрешение на внесение изменений (РИ) — информационный объект, содержащий информацию об изменениях и причинах этих изменений конкретной единицы ПП. Так как РИ должен быть предварительно согласован, содержит перечень согласующих групп и пользователей.
Заявка на изменение (ЗИ) — информационный объект, предназначенный для сбора всех изменений ПП, выполненных по одной первоначальной причине. Заявка на изменение, как правило, содержит входящие документы, на основании которых инициируется процедура изменения ПП, и описание причин внесения изменений. Без оформления ЗИ невозможно дальнейшее оформление РИ ни одной из дисциплин, участвующих в проекте.
Файл публикации — файл формата PDF, полученный путем преобразования редактируемой версии файла (DOC, XLS, DWG
Файл подлинника — файл в формате PDF или TIFF, полученный путем сканирования подписанных собственноручной подписью бумажных документов и предназначенный для архивного хранения, тиражирования и передачи Заказчику готовой проектной продукции в электронном виде.
На рис. 1 представлена общая схема процесса.
Процесс внесения изменений, как правило, начинается с того, что у Заказчика «поменялась концепция». Несмотря на некоторую шуточность данного утверждения, если вы считаете, что основной причиной изменений в ПП всегда являются ошибки проектирования, то вы глубоко ошибаетесь. Изменение технических требований, замена оборудования, его компоновки и расположения или просто «внезапное озарение» Заказчика часто служат основной причиной изменений.
Чаще всего процедура внесения изменений стартует с получения входящего письма с перечнем замечаний, предложений или требований Заказчика. Данный документ можно разместить непосредственно в системе для ознакомления с ним (рис. 2).
Обычно такого документа достаточно, чтобы на его основе принять решение о необходимости внесения изменений в тот или иной Том/Комплект, но необходимо учесть ряд нюансов:
Чтобы решить все вышеуказанные вопросы, мы ввели специальный информационный объект «Заявка на изменение» (ЗИ). Наиболее близким по смыслу к ЗИ в ЕСКД является «Предварительное извещение».
Составление ЗИ входит в зону ответственности группы ГИПа (ГУП), где ГИП или его помощники указывают причины внесения изменений, описывают сами возможные изменения (при необходимости), а также могут рекомендовать или ограничить список изменяемой ПП.
Сформированная заявка (рис. 3) утверждается ГИПом и рассылается всем ответственным лицам производственных подразделений, которые на ее основе принимают решение о необходимости внесения изменений в выпущенную ими ПП.
Оповещение ответственных лиц происходит по почте TDMS с прикреплением ссылок на ЗИ.
Если с ЗИ все относительно просто, то с «Разрешением на внесение изменений» (РИ) путь немного длиннее.
На одну ЗИ формируется столько РИ, сколько Томов/Комплектов будет изменено. Специалисты производственных подразделений рассматривают заявку, выявляют необходимость внесения изменений и либо создают РИ, либо нет (рис. 4).
Процесс привязки новых РИ продолжается до тех пор, пока данное ЗИ не будет «закрыто» ГИПом, и тем самым будет сформирован пакет изменений по текущей заявке. Одновременно в системе может быть открыто любое количество ЗИ.
В созданной РИ (рис. 5) необходимо описать планируемые изменения, сформировать бланк и направить РИ на согласование и утверждение.
Теперь в работу вступает маршрутный движок, который на основе выбранного маршрута согласования проводит сформированное РИ по процессу, оповещая участвующих лиц и переходя от шага к шагу по изображенной на рис. 6 схеме процесса.
Когда ГИП на утверждающем шаге скажет: «Утвердить», РИ будет переведено в соответствующий статус, а разработчик Тома/Комплекта сможет начать вносить изменения.
В системе предусмотрено три вида внесения изменений в Тома/Комплекты:
При внесении изменений создается новая версия Тома/Комплекта, а документы состава «прокидываются» из предыдущей версии и также могут быть изменены в новой, при этом в предыдущей версии останется состав, актуальный до внесения текущих изменений, а в текущей будут как измененные, так и неизмененные, а также вновь созданные листы (рис. 7).
До тех пор, пока изменяемый документ снова не будет сдан в архив, предыдущая его версия (в которую вносятся изменения) считается действующей, но помечается в системе как «Действующий (на изменении)». Такой специальный статус позволяет пользователям этого документа «аккуратнее» с ним работать, помня о том, что в скором времени документ будет изменен.
Проанализировав работу пользователей Заказчика в системе, а также их обращения в службу поддержки, мы выяснили, что самой распространенной ошибкой при внесении изменений является неверное определение вида внесения изменения («изм.» или «зам.») на начальном этапе (при разработке РИ). Данная ошибка пользователей приводит к необходимости корректировки и повторного согласования РИ с откатом всех произведенных изменений.
С целью уменьшения подобных ошибок было принято решение автоматически определять вид произведенного изменения на основании изменений документов его состава, не требуя дополнительных манипуляций от пользователя.
Документы состава изменяются «поштучно», каждый отдельной контекстной командой, конечно, если это не аннулирование целого Тома/Комплекта.
Точечное изменение документов позволяет изменять номер изменения только у тех документов, которые реально изменялись, а также документировать внесенные изменения на карточке каждого документа непосредственно в процессе изменения листа. В дальнейшем ведомость внесенных изменений собирается выборкой на Томе/Комплекте и может быть выгружена в виде отдельного документа.
На основе внесенных изменений ответственный проектировщик должен указать их влияние на изменение сметной стоимости в отдельном атрибуте (рис. 8).
Такой подход позволяет не забыть о том, что при изменении Тома/Комплекта необходимо пересчитать и сметы. И наоборот, если указать, что изменения не влияют на сметную стоимость, например, если поменялись только позиционные обозначения, в маршрут внесения изменений не попадут и без того всегда загруженные сметчики.
Перед размещением измененной документации в архив система контролирует, чтобы все измененные файлы присутствовали в системе, а файлы публикации и подлинника были пересобраны.
Процесс сдачи документации в архив аналогичен первичной сдаче с тем лишь дополнением, что вместе со сдаваемым Томом/Комплектом по процессу шагает РИ, оформленное при взятии этого самого Тома/Комплекта. Процессный движок ведет по процессу уже два информационных объекта, а при принятии своего шага архивом закрывает РИ, переводит текущую версию Тома/Комплекта и его состав в статус «Действующий» (или «Аннулирован»), а предыдущую версию из статуса «Действующий (на изменении)» в «Недействующий».
Сметная документация может изменяться как по воле сметчиков (например, если они сами обнаружили какие-то ошибки или неточности и корректировки связанных Томов/Комплектов не требуется), так и по инициативе проектировщиков, если внесенные в Том/Комплект изменения имеют конечное отражение в рублях.
В первом случае при внесении изменений в сметную документацию сметчик обычным образом создает РИ, а вот во втором случае оформления отдельного РИ для выпуска измененных сметных документов не требуется и изменение происходит по РИ измененного основного Тома/Комплекта.
Изменяя и заменяя сметы, сметчики привязывают их к актуальным «осмечиваемым» версиям Томов/Комплектов. Такая привязка позволяет отследить стоимости «до» и «после» и на основании этого рассчитать изменение стоимости по каждой из статей.
При формировании сметных документов сметчиком или сметной программой в карточку самой сметы вносится информация по следующим статьям (рис. 9):
Процесс формирования самой сметы в данной статье мы вынуждены опустить, как и рассказ о модуле интеграции со сметным ПО, позволяющем обмениваться между приложениями не только итоговыми суммами, но и рядом других параметров. Схемы работы TDMS со сметным ПО могут быть разными, наиболее продвинутые позволяют сметчикам работать в двух и более программах как в едином комплексе, минимизируя переключения между приложениями.
Итак, разместив в системе новые сметы, можно запустить формирование отчета по изменению сметной стоимости. Данный отчет формируется с ЗИ (еще не забыли, для чего мы ее вводили?) и показывает все измененные по нему Тома/Комплекты, а также позволят оценить «стоимость» изменений, внесенных по одной причине (рис. 10).
Такой отчет, всегда «желанный гость» на столе ГИПа, позволяет оперативно оценивать, куда движется смета на строительство и кто тому виной.
Чтобы не перегрузить вас информацией, самое время остановиться и анонсировать следующую статью. Она также будет посвящена версиям, но мы рассмотрим их уже со стороны возможностей визуальной настройки и программирования API TDMS. Там же, в следующей статье, подведем итоги обеих частей.
До скорой встречи!
