Система электронного архива Д’АР — первый шаг к построению системы управления проектными данными

Ольга Галкина
Руководитель проектов компании InterCAD
Наталья Кораго
Руководитель проектов компании InterCAD
Алексей Рындин
Заместитель директора компании InterCAD по связям с общественностью
Александр Тучков
К.т.н., технический директор компании InterCAD

И снова о терминологии

Данная статья продолжает освещение темы построения систем управления проектными данными, начатое в февральском номере «САПР и графика».

В предыдущей публикации особое внимание уделялось вопросам терминологии: в общих чертах описана сложившаяся ситуация в области ИТ в проектных организациях, характеризующаяся различным трактованием одних и тех же терминов; приведены примеры подмены понятий и прочих сопутствующих бурному развитию ИТ процессов. Напомним: мы предприняли попытку дать определение системе управления проектными данными (далее СУПД), рассмотрели различные подходы к ее реализации и, опираясь на наш опыт, изложили некие теоретические и практические подходы.

Мы попытались определить «Идеальную СУПД» как систему, управляющую всеми данными, реально существующими в современных условиях (в проектных организациях РФ), учитывающую уровень автоматизации, развитие нормативной базы, принципы проведения проектных работ, ментальность, традиции, наличие двух основных подходов (2D и 3D) и прочие факторы.

Теперь уже следуя традиции начинать процесс изложения с приведения к единому пониманию терминов, подробнее остановимся на казалось бы давно всем известном понятии «Электронный архив»...

«Стоп! При чем здесь электронный архив? Тема давно известна и подробно освещена. И какое отношение это все имеет к СУПД?» — может воскликнуть читатель, упомянув «оскомину» и прочие характеризующие этот термин эпитеты... Но не будем торопиться с выводами и все же посмотрим на электронный архив «под несколько иным углом».

Для начала изложим краткую концепцию и наше понимание таких терминов, как «Электронный архив», «Электронный архив ПСД», «Электронный архив проектной организации».

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

Под термином «Электронный архив ПСД» мы будем понимать «детализацию» предыдущего термина с точки зрения предмета «хранения» — проектно­сметной документации. Проведем следующие уточнения:

• с точки зрения ГОСТ 2.051­2006 (ЕСКД. Электронные документы. Общие положения), будем вести речь об электронной документации. Напомним, что, в соответствии с указанным ГОСТом, электронный документ включает как содержательную, так и реквизитную части. То есть «просто файл» без реквизитов электронным документом с точки зрения ГОСТа не является. Есть несколько способов реализации содержательной и реквизитной частей. Все они описаны в приведенном ГОСТе. В последнее время наиболее часто реквизиты записываются в таблицы СУБД;
• при создании электронного архива ПСД, как правило, существует необходимость автоматизации ряда бизнес­процесов, связаных не только с распределением прав доступа, поиском в хранилище, но и с пополнением (сдачей электронной документации), проведением изменений в электронной ПСД, отгрузки электронной ПСД, ее тиражированием и т.д. Иными словами, существует некий «необходимый минимальный набор функционала», без которого «Электронный архив ПСД» превращается в «просто Электронный архив», определение которому дано выше.

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

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

Перечисленные типы хранимой информации часто включают проектные данные, которые могут содержаться как в структурированном, так и в неструктурированном виде. Ничего не напоминает? Для тех, кто не знаком с содержанием предыдущей статьи, напомним, что мы позволили себе дать определение «Идеальной СУПД» и сформулировать необходимые функции, ключевой из которых является «управление всеми типами проектных данных, реально существующими в современных условиях (в проектных организациях РФ)». Таким образом, понятия «Электронный архив проектной организации» и «СУПД», которые могли бы показаться изначально «совершенно не связанными», несомненно, имеют «нечто общее». Что именно? Об этом речь пойдет далее.

Об «отношениях» между электронным архивом проектной организации и СУПД...

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

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

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

Постараемся сформулировать некоторые подходы:

• система электронного архива (определение дано ранее), как правило, не представляет очень большого интереса для проектной организации в связи с отсутствием автоматизации «минимально необходимого набора» бизнес­процессов: пополнения, проведения изменений, отгрузки ПСД. Поэтому, на наш взгляд, «минимальной ступенью» автоматизации может стать система электронного архива ПСД;
• системы электронного архива ПСД и электронного архива проектной организации отнюдь не являются в полной мере СУПД;
• при внедрении и дальнейшем развитии электронного архива в проектных организациях неизбежно возникают задачи, «близкие» или полностью соответствующие задачам, решаемым СУПД;
• исходя из существующих реалий, прежде всего наличия большого количества неструктурированных проектных данных, содержащихся в электронных документах, система электронного архива ПСД является неизбежным шагом к системе электронного архива проектной организации (см. определения выше);
• система электронного архива проектной организации, в свою очередь, содержит ряд элементов СУПД и является необходимым шагом, ступенью к СУПД.

О некотором практическом опыте

Далее перейдем в практическую плоскость нашего изложения, и поговорим о реализации первой ступени СУПД.

В зависимости от объемов информации, принятых принципов проектирования, степени автоматизации, используемых САПР, и прочих факторов, существуют различные подходы к созданию СУПД. Об этом мы уже писали. Например, на соответствующих проектах можно пытаться строить полноценную СУПД, используя линейку САПР и механизм обмена данными (как правило, от производителя этой же линейки САПР). Примерами таких решений могут служить линейки от Intergraph, Bentley, Autodesk с соответствующими механизмами SmartPlant Fondation, Bentley ProjectWise, Autodesk Vault. При этом «неизбежность» эволюционного шага — электронного архива проектной организации — на первый взгляд может быть поставлена под сомнение. Однако, на наш взгляд, «отмирание» эволюционной ветви — электронного архива проектной организации — вполне возможно, но при выполнении необходимого условия: все участники процесса обеспечения всех стадий ЖЦ объекта переходят на работу с электронной информацией в рамках единой информационной модели, легитимность которой в целом и легитимность всех «отчужденных» данных и документов обеспечивается современным законодательством... Предлагаем читателям привести пример в области ПГС хотя бы одного такого объекта…

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

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

1 Подсистемы, которые, с одной стороны, необходимы, а с другой — рассказывать о них подробно смысла не имеет, поскольку их описание не является предметом статьи:

• подсистема администрирования;
• подсистема хранения. Представляет единое хранилище информации (независимо от того, как оно реализовано на физическом и/или логическом уровне);
• подсистема распределения прав доступа к разделам информации;
• подсистема поиска.

2 Подсистемы, автоматизирующие необходимый минимум процессов первой ступени создания СУПД:

• подсистема построения структур ПСД в соответствии с нормативными документами РФ;
• подсистема пополнения;
• подсистема проведения изменений;
• подсистема отгрузки заказчикам;
• подсистема отчетов;
• сервисные подсистемы:

- справочники,

- автоматизированное формирование некоторых ПСД,

- запись на CD,

- подсистема заказ­нарядов (учет работы с документацией — тиражирование, сканирование и т.д.),

- прочее.

Один из примеров реализации

Перечисленный функционал «универсален» для большинства проектных организаций в области ПГС. Поэтому в нашей компании создано базисное решение — система Д’АР, которая успешно внедряется в проектных организациях и соответствует изложенным в статье подходам. Весь функционал Д’АР реализован компанией InterCAD в среде программного комплекса TDMS (разработки компании CSoft Development).

Несомненно, даже при внедрении такого типизированного решения неизбежны некоторые корректировки процессов, но, на наш взгляд, они в масштабах организации­заказчика несущественны. Приведем небольшой пример: в большинстве проектных институтов архивный номер документа присваивается в архиве при приемке документа. В некоторых организациях (встречается в области ПГС редко) архивный номер «бронируется» проектировщиком заранее из некоего диапазона. Наш опыт позволяет уверенно утверждать следующее: для предприятия в большинстве случаев дешевле и быстрее откорректировать бизнес­процесс, обоснованием которого является лишь то, что «так исторически сложилось». Хотя при необходимости мы готовы внести изменение и в «типизацию».

Подробнее рассмотрим реализацию функционала «первой ступени» в системе Д’АР.

Справочники

Как и любая информационная система, требующая работы с классифицируемой информацией, система Д’АР имеет ряд справочников, а именно:

• контрагентов;
• договоров;
• объектов;
• прочие.

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

Построение структур ПСД

В отличие от предыдущей, на описании этой подсистемы стоит остановиться подробнее. Процессу построения структуры ПСД предшествует внесение в БД информации о договоре. Отметим, что Д’АР не содержит финансовой договорной информации. В структуру «основного дерева» пользовательского интерфейса вносятся узлы, соответствующие договорам, их этапам и/или дополнительным соглашениям.

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

На рис. 1 приведена упрощенная схема основных структур Д’АР. Любой элемент структуры документов имеет связи с любым элементом структуры договоров, что позволяет, используя эти связи, механизмы запросов и отчетов, получать необходимую аналитическую информацию.

Рис. 1. Упрощенная схема основных структур

Приведем лишь один пример, наличие которого, во­первых, представит Систему в выгодном свете в глазах ГИПа, а во­вторых, пояснит, зачем нужна информация о договорах и даст пояснения к рис. 1.

Используя связи между элементами структур, можно проследить:

• какими актами закрыт договор (дополнительное соглашение) или этап;
• какие накладные на отгрузку ПСД были сформированы (связаны с актами);
• какие из накладных были переданы;
• какие накладные возвращены;
• какие комплекты были отгружены.

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

Кроме инструментов построения структур и связей с договорами, дополнительными соглашениями и этапами, для представления ПСД структурированной, согласно требованиям Постановления № 87 от 16 февраля 2008 г. «О составе разделов проектной документации и требованиях к их содержанию», система Д’АР имеет механизм автоматического создания иерархической структуры ПСД в зависимости от стадии проведения проектных работ, с автоматизированным заполнением названий и присвоением основных обозначений. Созданная структура вполне может потребовать корректировки, если, например, она избыточна. Процесс корректировки доступен соответствующему пользователю Д’АР — ГИПу или его помощнику. Пример фрагмента структуры ПСД по «стадии Р» (доступно через пользовательский интерфейс) приведен на рис. 2.

Рис. 2. Пример отображения структуры ПСД после автоматического построения

Пополнение БД

После создания структуры документации в Д’АР используется механизм пополнения электронного архива ПСД. Процесс включает:

• непосредственно создание томов и комплектов в структуре ПСД (выполняет начальник отдела/сектора);
• «наполнение» томов и комплектов непосредственно разработанными документами;
• регистрацию в техническом архиве (выполняет пользователь, выступающий в роли работника «Электронного архива»), проведение необходимых проверок;
• передачу ПСД в группу отгрузки, на работе которой подробнее остановимся позже.

Отметим, что в процессе работы с подсистемой пополнения электронного архива ПСД в системе Д’АР используются различные механизмы, позволяющие автоматизировать ввод и исключить ошибки. К таким механизмам относятся: автоматизированное формирование ряда атрибутов, использование формализованных списков, справочников и т.д.

Наша практика показывает, что на начальном этапе внедрения Системы часто приходится решать задачи ввода не только вновь разрабатываемой ПСД, но и ранее разработанной и хранящейся в электронном виде, например на файловых серверах, DVD и т.д. Чтобы избавить заказчика от рутинного ввода, в Д’АР предусмотрен инструмент, настройка которого доступна пользователю с соответствующими правами (администратору). Этот инструмент позволяет осуществлять пакетный ввод документов в БД с заполнением карточек, используя логику наименования файлов (рис. 3).

Рис. 3. Встроенный в Д’АР механизм загрузки документов из файловой системы

Не будем подробно останавливаться на освещении вопроса. Отметим лишь следующее: существует несколько технологий, позволяющих осуществлять пакетный ввод в БД. Мы имеем опыт их использования. В Д’АР же реализована одна из них. Мы готовы предложить не только «встроенную» в Систему функцию, но и другие, наиболее целесообразные для конкретного случая.

Автоматизация отгрузки ПСД заказчикам

После поступления томов/комплектов в группу отгрузки документации в рамках Системы автоматизируются следующие процессы:

• присвоение архивных номеров;
• формирование накладных на отгрузку (автоматизированно создается бланк накладной установленной формы);
• выгрузка из Д’АР в файловую систему или запись на CD для последующей передачи заказчику.

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

Проведение изменений

Важным аспектом деятельности проектной организации является автоматизация учета проводимых изменений в ПСД. В функционал внесен специальный информационный объект — разрешение на изменение. По сути, работа по его заполнению и регистрации повторяет работу с бумажным разрешением. После оформления разрешения на изменения процессы по пополнению электронного архива ПСД будут полностью соответствовать тем, что были описаны выше. При этом система Д’АР имеет следующий функционал:

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

Рис. 4. Хранение состава комплекта и изменений; а — полный состав; б — первоначальный состав; в — измененные документы (изменение 1)

Отчеты и автоматизированное формирование некоторых документов

В случае наличия в базе данных информации и всех необходимых связей позволяет при условии грамотного использования механизма запросов возможно получение из нее любой отчетной информации. Д’АР не является исключением: аналитическая информация может представляться в виде отчетов с применением пользовательского интерфейса (переход по связям и механизм сохраненных запросов­выборок). В то же время в Д’АР реализованы некоторые функции, позволяющие автоматически получать ряд документов на бланках установленного образца: накладные, перечень основных комплектов, состав комплекта и даже такую «приятную мелочь», как этикетки для CD с отгружаемой в электронном виде ПСД.

Заключение

В заключение попытаемся сформулировать выводы:

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

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

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

Список литературы

1. Рындин А., Тучков А. Системы управления проектными данными в области промышленного и гражданского строительства: наш опыт и понимание. САПР и графика. 2013. № 2. C. 20­26.
2. Рындин А., Галкина О., Благодырь А., Кораго Н. Автоматизация потоков документации — важный шаг к созданию ЕИП // REM. 2012. № 4. С. 42­48.
3. Чиковская И., Данилова Л., Лянда А. Переход на трехмерную технологию проектирования станций Санкт­Петербургского метрополитена на основе вертикальных решений компании Autodesk, Inc. // САПР и графика. 2012. № 9. С. 108­112.
4. Малашкин Ю., Шатских Т., Юхов А., Галкина О., Кораго Н., Рындин А., Фертман И. Опыт разработки системы электронного документооборота в ОАО «Гипроспецгаз» // САПР и графика. 2011. № 12. С. 96­98.
5. Долгалев Д. Обмен данными между различными системами // САПР и графика. 2011. № 9. С. 73­75.
6. Тучков А., Максимов Н. Работа с данными на разных этапах жизненного цикла промышленных объектов с использованием SmartPlant Enterprise // САПР и графика. 2011. № 8. С. 2­5.
7. Воробьев А., Данилова Л., Игнатов Б., Рындин А., Тучков А., Уткин А., Фертман И., Щеглов Д. Сценарий и механизмы создания единого информационного пространства // CADmaster. 2010. № 5. С. 48­51.
8. Санев В., Суслов Д., Смирнов С. Использование информационных технологий в ЗАО «ЦНИИ судового машиностроения» // CADmaster. 2010. № 3(53). С. 29­32.
9. Данилова Л., Щеглов Д. Методология создания единого информационного пространства ракетно­космической отрасли // REM. 2010. № 6. С. 14­15.
10. Воробьев А., Пивоваров В., Щеглов Д., Алимов М., Ведерникова Т., Данилова Л., Рындин А., Тучков А., Фертман И. Концепция создания единой среды проектирования как первый этап обеспечения жизненного цикла изделий (опыт ОАО «КБСМ») // CADmaster. 2008. № 2. С. 18­20.
11. Грачев В. Современное состояние дел с электронными архивами // CADmaster. 2008. № 2. С. 92­97.
12. Тучков А. Внедрение электронных архивов инженерной документации // CADmaster. 2008. № 3. С. 42­49.
13. Чиковская И. Тихая революция. Электронный кульман или информационная модель здания // CADmaster. 2008. № 3. С. 88­92.
14. Рындин А., Тучков А., Фертман И. Ступени внедрения ИПИ­технологий. Опыт реализации электронного документооборота // Материалы конференции «Моринтех­практик информационные технологии в судостроении — 2006», 2006 г.
15. Ведерникова Т., Смирнов С. Использование современных достижений информационных технологий в ЦНИИ судового машиностроения // CADmaster. 2005. № 5. С. 31­33.
16. Галкина О., Рындин А., Рябенький Л., Тучков А., Фертман И. Построение информационных моделей изделий судостроения на различных стадиях жизненного цикла с элементами логистической поддержки // Сборник докладов конференции «Технологии информационной поддержки жизненного цикла сложных изделий в российской промышленности», 2004 г.
17. Голованов В., Рябенький Л., Давыденко С., Острокопытов Д., Тучков А., Фертман И. Опыт внедрения комплексных программно­аппаратных решений САПР и электронного архива инженерной документации на судостроительных предприятиях // Cборник докладов конференции «Роль и значение “Адмиралтейских верфей” в научно­техническом развитии российского и мирового судостроения», 2004 г.
18. Рындин А. Ввод сканированных документов в электронный архив предприятия // CADmaster. 2003. № 1. С. 41­43.
19. Рындин А. Архив без пыльных полок, или Способы организации архива предприятия // JetInfo. 2002. 10/113.
20. Фертман И., Тучков А., Попов К. Аппаратное обеспечение электронного технического документооборота // CADmaster 2001. № 8/3.
21. Давыденко С., Павлович М. Реализация системы конструкторского документооборота и решение проблемы тиражирования документации в ЦКБ МТ «РУБИН» // CADmaster. 2000. № 5. С. 16­19.

САПР и графика 9`2013