Во всех современных системах класса PDM, рассматриваемых как системы управления проектными данными и технического документооборота, имеется ряд функций, обеспечивающих непротиворечивость данных при их постоянной актуализации. Информация, хранящаяся в системе, непрерывно обновляется и дополняется, поэтому крайне важно не просто складировать её в электронном виде, а обеспечить пользователю возможность оперативно извлекать необходимые данные по определённым запросам.
В классическом представлении информация может быть новой, т. е. появиться в системе впервые — это самый простой случай. Информация может быть обновлённой, т. е. заменять предыдущую новой версией. Для этого применяется механизм версионности, когда по неизменённому имени файла ведётся учёт порядкового номера версии обновления в системе. Самый сложный случай, когда данные перестают быть актуальными, но не должны физически удаляться из системы. Для этого варианта предусматриваются специальные метки на удаление или размещение в архив.
В любой системе технического документооборота предусмотрен механизм создания папочной структуры проекта для организации хранения данных. SODIS Building отличается от большинства систем тем, что в ней не предусматривается «классическая» папочная организация проекта. Вместо фиксированной папочной структуры создаётся «динамическая» структура проекта, состоящая из специально настроенных «смарт-папок», представляющих собой систему запросов данных из общей базы проекта. Более подробно механизм «смарт-папок» был описан в предыдущей статье. В итоге мы получаем адаптированную папочную структуру под нужны конкретного пользователя или роли пользователей.
Рис. 1. Пример организации структуры проекта в SODIS Building на основе «смарт-папок».
Рис. 2. Пример настройки поискового запроса через инструмент «смарт-папок».
Можно предположить, что папочная организация хранения и система учёта версионности файлов даёт достаточно возможностей для управления потоком данных.
Рассмотрим случай, когда идёт согласование определённого раздела проектной документации. Заказчику от проектной организации периодически поступает новая порция обновлённых файлов, которые несут в себе исправления по предъявленным замечаниям. Предположим, что проектировщик не меняет названия файлов, что позволяет нам управлять версионностью, и не разделяет или объединяет файлы по содержимому. Но даже в этом случае, мы накапливаем набор файлов, среди которых можно выделить следующие:
- новые файлы, которых не было в предыдущих итерациях;
- файлы, которые подлежат удалению, но должны сохраняться в системе;
- N-я версия согласованного файла;
- N-я версия файла, который будет отредактирован в следующей версии по полученным замечаниям;
- файл, замещающий собой другой файл с другим именем;
- N-я версия файла, который необходимо рассмотреть и согласовать или дать замечания;
- любые вспомогательные файлы (схемы, чертежи, скриншоты), относящиеся к другому файлу;
- массив всех предыдущих версий файлов, если они никак не отделены от последних (самых свежих) версий.
Таким образом, при прохождении нескольких итераций согласования и соответствующего обновления данных в системе мы получаем огромный набор файлов, в котором невозможно разобраться. Механизмы версионности и папочной организации получаются недостаточными для управления изменениями в наборах данных по согласованию документации. Добавим сюда «вспомогательные» файлы от заказчика, организацию хранения и управления замечаниями и ответами на них — в итоге получаем неуправляемый поток неорганизованных файлов.
Что такое редакции и как работает механизм редакций
Для решения данной задачи в определённых конфигурациях SODIS Building CM для пользователей был предложен механизм редакций. Напомним, что данные в SODIS Building хранятся в специальных объектах — карточках, описываемых набором атрибутивной информации. Категорий карточек может быть множество — это сами документы, задачи, замечания, материалы, помещения, элементы списков и прочее. Для документов разрабатываются отдельные типы карточек документации — редакции, которые по сути являются вложениями в карточки документов.
Редакции представляют собой контейнеры для фиксации состояния документации на определённом шаге согласования. Хранение файлов и замечаний к ним теперь осуществляется во вновь созданной редакции, входящей в карточку, а не в самой карточке, где остаётся только общее атрибутивное описание. При прохождении множества возможных итераций согласования допускается обновление данных в редакции — здесь активно работает механизм версионности и разделения «самых последних версий» от всех остальных. Когда редакция окончательно согласовывается, она закрывается на редактирование и «фиксируется» в карточке.
При необходимости внесения каких-либо изменений в ранее согласованную документацию создаётся новая редакция в составе той же самой карточки и процесс согласования запускается снова. Важно учесть, что для сохранения «автономности» редакции предусматривается механизм копирования последних согласованных версий файлов в новую редакцию при её создании.
Концепция редакций рассматривает каждую следующую редакцию независимо от предыдущей, хотя по желанию заказчика можно фиксировать только изменения в каждой новой редакции. Но перенос всех актуальных файлов в новую редакцию позволяет «стартовать» с предыдущего состояния документации и видеть, что остаётся актуальным, а что уже меняется и требует согласования повторно. Кроме того, файлы, помеченные как удалённые, не переносятся в новую редакцию, что тоже очень удобно. Проектировщик видит перенесённые файлы из предыдущей согласованной редакции и добавляет в неё только новые изменённые файлы, которые заказчику необходимо согласовать. Система распознаёт, какие данные были скопированы, а какие загружены пользователями, поэтому заказчику наглядно видны все изменения.
Как организованы и работают редакции на абстрактном примере
Например, у нас есть несколько итераций согласования с различными форматами файлов и разной глубины версионности по результатам корректировок. Сразу обозначим эти итерации как наши будущие редакции документации.
Рис. 3. Пример развития редакций в процессе нескольких этапов согласования.
Нам необходимо разделить эти массивы данных в независимые редакции. Предположим, что мы условно разделили их по «контейнерам», которые назовём редакциями и опишем рядом атрибутов.
Рис. 4. Пример разделения данных по редакциям-«контейнерам».
Далее разместим наши «контейнеры»-редакции в «ящик»-карточку документации, например, определённый раздел архитектуры какого-либо проекта. Помним, что редакции и карточка описываются атрибутами. Часть атрибутов карточки может быть наследована атрибутами редакций, например, наименования проекта и раздела.
Рис.5 Пример карточки-«ящика» с редакциями-«контейнерами».
Таким образом, мы получаем распределённую по редакциям совокупность данных с учётом их версионности и актуальности. Пользователи видят всю историю изменений по каждой итерации согласования редакции и изменение документации между редакциями. Выдаваемые замечания относятся к редакциям, могут содержать в себе атрибуты номера редакции и статус закрытия замечания.
Работа с редакциями в системе SODIS Building
Рассмотрим, как работа с редакциями выглядит в интерфейсе системы SODIS Building.
Рис. 6. Пример карточки с тремя редакциями.
Карточки, сгруппированные по «смарт-папкам», отображаются в виде списка или таблицы. При выборе определённой карточки из списка можно открыть подсписок, состоящий из редакций данной карточки. Если идёт работа через редакции, то обязательно наличие первой редакции, чтобы разместить в неё данные. При последующих изменениях создаются следующие. Список редакций можно увидеть и в самой карточке через отдельную одноимённую вкладку. Если выбрать редакцию, то на первой закладке можно сразу увидеть список актуальных файлов последних версий. Все файлы размещаются на одноимённой закладке файлов.
Рис. 7. Размещение всех файлов всех версий на отдельной закладке.
Информация по согласованию данной редакции актуализируется на собственной закладке. Напомним, что вся атрибутика, закладки (кроме системных) может быть гибко адаптирована под задачи и бизнес-процессы заказчика. Информация по статусу актуальности и статусу согласования может быть включена в имя редакции.
Статусы актуальности, например, могут быть следующие:
- актуальная: согласованная действующая редакция;
- черновик: согласуемая в настоящий момент редакция, но ещё не замещающая собой актуальную;
- неактуальная: согласованная или несогласованная редакция предыдущих итераций.
Статусы согласования могут быть следующие:
- согласовано: завершён процесс согласования без замечаний;
- согласовано с замечаниями: завершён процесс согласования с замечаниями;
- в процессе согласования: редакция проходит согласование, результат ещё не определён;
- не согласовано: завершён процесс согласования с критичными замечаниями, либо согласование прервано.
Приведённые примеры статусов могут быть гибко адаптированы под настраиваемые бизнес-процессы. Также многое зависит от организации таких процессов. Например, может предполагаться, что редакция в конечном итоге согласуется после снятия всех замечаний и всегда будет иметь статус согласованной. При появлении новой согласованной редакции она будет уже неактуальной, но всё-таки согласованной. Можно организовать процесс, когда редакция проходит единственный круг и при наличии замечаний все изменения формируются в новой следующей редакции. С одной стороны, пропадает версионность файлов внутри редакции и работать проще, но появляется большое число самих редакций.
С помощью инструмента «смарт-папок» можно организовать отбор и группировку исключительно редакций для более детального анализа и управления документацией. Например, необходимо отфильтровать только выданную в производство работ рабочую документацию определённого проекта. В этом случае создаётся «смарт-папка» только из соответствующих редакций. Карточки, которые являются отдельными объектами системы не попадут в эту папку, что позволяет гибко фильтровать нужные данные, исключая всё остальное неактуальное.
Подводя итоги данной статьи, хочется отметить мощный и гибкий механизм редакций, решающий многие вопросы по управлению изменениями данных проекта. При его разработке и внедрении нужно тщательно продумать общую концепцию ведения изменений, все процессы согласования, определить нужные атрибуты и настройки «смарт-папок». При детальной подготовке эта полезная функция оказывается очень необходимой, наглядной и удобной.
