В настоящее время на рынке информационных систем представлено немало продуктов, использующих CALS- и PLM-технологии. Основой этих технологий является концепция информационной поддержки изделия на всех этапах его жизненного цикла. Поскольку в данной области еще не выработано соответствующих стандартов и единой, всеми принятой терминологии, на данный момент значение имеет практическая сторона вопроса, то есть обоснования и подходы к реализации информационной поддержки жизненного цикла продукта, предлагаемые тем или иным разработчиком. Компания Consistent Software SPb/Бюро ESG использует распространенный перевод термина CALS (Continuous Acquisition and Life-Cycle Support) – информационная поддержка изделия (ИПИ).
Для реализации ИПИ-технологий с использованием PDM/PLM-системы и построения информационных моделей изделий необходимо реализовать определенную логику, учитывающую реально существующие ступени развития информационного пространства на конкретном предприятии. Процесс внедрения ИПИ-технологий можно представить в виде последовательного прохождения следующих “ступеней”:
Прокомментируем коротко основные положения этого ступенчатого подхода.
Прежде всего для информационной поддержки ЖЦ изделия необходим сбор всей информации об изделии (объекте) на всех стадиях его жизненного цикла.
Кроме собранной информации об изделии (объекте) при внедрении ИПИ-технологий необходимо создание различных представлений информации о продукте для различных участников процесса обеспечения ЖЦ. Например, представление изделий судостроения на этапе строительства (когда оперируют такими понятиями, как строительные районы, секции и т. д.) сильно отличается от представления изделия на этапе его эксплуатации (палубы, платформы, отсеки, надстройки, ярусы, помещения). Эксплуатирующей организации, например, неинтересно представление информации в “строительной” иерархии. Хотя и существуют “общие” элементы представления изделия на различных этапах ЖЦ, например “системы” или “помещения” в том же судостроении, для различных участников процесса ЖЦ данные элементы представляют интерес в различных “разрезах”. Для строителя – в связях с секциями и блоками, а для эксплуатирующей организации – в связях с отсеками, палубами, платформами, надстройками, ярусами;
Реализация проекта внедрения ИПИ-технологий на предприятии является по существу эволюционным процессом, и как любая эволюция подразумевает прохождение всех необходимых промежуточных стадий. Опыт (в том числе и исторический) показывает, что система, игнорирующая последовательное прохождение ступеней эволюции, терпит крах (любая кухарка не может грамотно управлять государством). Сфера современных информационных технологий не является в этом отношении исключением. Планомерное прохождение всех стадий внедрения ИПИ-технологий является процессом неизбежным и обязательным.
Как мы отмечали выше, прежде чем пытаться управлять информацией об изделии, необходимо ее собрать. Целесообразнее накапливать информацию в единой базе данных – электронном архиве. Очевидно, что в полном объеме информация об изделии, возникающая на всех стадиях ЖЦ, может быть собрана только после того, как эти стадии будут пройдены. С другой стороны, процесс накопления информации должен происходить на протяжении всего жизненного цикла, и, соответственно, должны присутствовать механизмы, обеспечивающие этот процесс. Таким образом, чтобы пройти первую ступень внедрения ИПИ-технологий, необходимо создать базу данных информации по продукту и механизмы ее пополнения в процессе ЖЦ – другими словами, систему электронного архива. Наполнение же электронного архива информацией по изделию будет производиться по мере появления новой информации и ее изменения в процессе ЖЦ.
Следующим этапом эволюционного процесса внедрения ИПИ-технологий является создание системы электронного документооборота. Поскольку описанию этих систем посвящено множество публикаций, мы не будем подробно останавливаться на теоретических аспектах вопроса, а обратимся к практической стороне создания системы электронного документооборота.
Основным отличием системы электронного архива от системы электронного документооборота является наличие в последней не только самой базы данных информации об изделии, но и механизмов ее пополнения. На данной ступени внедрения ИПИ-технологий требуются механизмы разработки данных (проектных, административных, финансовых, маркетинговых и прочих) с учетом их маршрутизации, согласований и утверждений различными пользователями, отделами, организациями, предприятиями и прочими участниками процесса разработки информации об изделии на различных стадиях его ЖЦ.
Все работы компании Consistent Software SPb/Бюро ESG в области реализации систем электронного документооборота проводятся в среде программного комплекса TDMS, разработанного Consistent Software. О данной системе вышло достаточное количество публикаций, и мы не будем здесь повторять ранее сказанное. Отметим лишь, что система TDMS позволяет решить множество возникающих проблем на ВСЕХ стадиях внедрения ИПИ-технологий.
При практической реализации системы электронного документооборота, c точки зрения автоматизации управления административным документопотоком и документопотоком системы менеджмента качества, как правило, особых проблем не возникает. С другой стороны, поскольку мы говорим о поддержке жизненного цикла продукта, невозможно, решив лишь задачи “традиционного” или “административного” документооборота, создать механизм накопления информации об изделии. С началом стадии проектирования жизненного цикла изделия в обязательном порядке должны учитываться документопотоки электронных документов, по лучаемых в процессе использования САПР и расчетных программных пакетов.
Поговорим о современной нормативной базе, без которой внедрение системы документооборота просто бессмысленно.
Поскольку система электронного документооборота предназначена для управления электронными документами, обратимся прежде всего к официальному определению этого понятия. Согласно ГОСТ 2.051–2006, электронный документ – это “документ, выполненный как структурированный набор данных, создаваемый программно-техническим средством”. Даже исходя из этого определения, следует то, что бытующие до сих пор понятия “файл AutoCAD”, “файл Excel” и подобные входят в категорию электронных документов.
Положения указанного нормативного документа также однозначно трактуют подходы к таким терминам, как “составные документы” и “сборки”. С точки зрения, определяемой ГОСТ 2.051–2006, электронные документы могут быть простыми – состоящими из одной информационной единицы (например, чертеж AutoCAD, выполненный в одном файле), составными – содержательная часть при этом его состоит из нескольких информационных единиц, связанных ссылками, и агрегированными – состоящими из нескольких информационных единиц, информативно связанных друг с другом. При этом указанный ГОСТ допускает возможность представления составных электронных документов в виде сложных иерархических структур.
Из приведенных трактовок явно следует, что часто употребляемое понятие “сборка” (например, “сборка Autodesk Inventor”) является ничем иным, как электронным документом, кроме того, понятие “проект”, являющееся результатом работы в некоторых САПР верхнего уровня, вполне соответствует содержанию понятия агрегированного электронного документа.
Таким образом, создание системы электронного документооборота как ступени внедрения ИПИ-технологий обеспечено достаточной нормативной базой. В чем же основные проблемы организации электронного управления документами, порождаемыми в ходе работы с САПР? Обозначим некоторые из них.
Можно перечислить еще множество вопросов, без решения которых невозможна реализация полноценной системы документооборота как ступени внедрения ИПИ-технологий.
Вместе с тем, постоянно сталкиваясь с необходимостью решения проблем, связанных с построением системы электронного документооборота, в части, касающейся взаимодействия с различными САПР, специалисты компании Consistent Software SPb/Бюро ESG достигли определенных успехов. Так, ими созданы интерфейсы с 2D-средствами – AutoCAD и Компас, с 3DСАПР – CATIA, Unigraphics, Pro|ENGINEER, Autodesk Inventor, SOLIDWORKS, SolidEdge.
Являясь авторизованным реселлером Autodesk, компания Бюро ESG особое внимание уделяет решению проблем взаимодействия системы электронного документооборота с САПР ее разработки, такими как AutoCAD и Autodesk Inventor. Рассмотрим реализацию этих интерфейсов.
Схема реализованного механизма взаимодействия с AutoCAD приведена на рис. 1.
Интерфейс состоит из следующих функциональных модулей:
Приведем основной функционал перечисленных модулей:
Из специального подгружаемого меню на панели инструментов AutoCAD возможно выполнение автоматических действий по следующему алгоритму:
Основное назначение этого модуля – проводить автоматическую синхронизацию полей углового штампа электронного файла AutoCAD с атрибутивными параметрами. При изменении значений полей углового штампа и/или других областей пространства листа или/и модели чертежа AutoCAD автоматически производятся изменения в атрибутивных параметрах учетной карточки электронного документа в системе документооборота. И наоборот, изменения атрибутивных параметров учетной карточки электронного документа автоматически переносятся в соответствующие поля углового штампа и в другие области пространства листа и/или модели AutoCAD.
Основным назначением данного модуля является автоматизированное выполнение следующих процедур:
Рассмотрим организацию взаимодействия системы документооборота TDMS со средствами 3D-моделирования на примере реализованного компанией Consistent Software SPb/Бюро ESG интерфейса системы TDMS и Autodesk Inventor с использованием системы управления проектом и хранения его документов Autodesk Vault. Это решение, анонсированное осенью 2006 года, уже успело вызвать к себе заметный интерес со стороны специалистов многих проектных организаций.
Для тех, кто незнаком с системой управления проектом и хранения его документов Autodesk Vault, кратко перечислим ее основные функции:
Несмотря на то что Autodesk Vault успешно выполняет все перечисленные функции, для построения структуры “полноценного” документооборота также необходимо (как минимум!) организовать:
Все перечисленные функции выполняет система электронного документооборота, реализованная в среде TDMS.
В соответствии с вышеизложенным и с принципом “Богу–Богово, а Кесарю–кесарево”, основная идеология интерфейса состоит в следующем: функции, перечисленные для Autodesk Vault, возлагаются на него, а все вышеуказанные функции, необходимые для реализации “полноценной” среды документооборота как ступени внедрения ИПИ-технологий на стадии проектирования жизненного цикла изделия, – на среду TDMS.
В связи с этим при создании интерфейса системы TDMS и Autodesk Inventor с использованием системы управления проектом и хранения его документов Autodesk Vault были реализованы следующие функции:
Структурная схема интерфейса приведена на рис. 2.
Отметим важный момент: на рис. 1 и рис. 2 приведены лишь схемы взаимодействия системы электронного документооборота, реализованной в среде TDMS, с программными продуктами компании Autodesk, связанные с регистрацией, синхронизацией информации и получением спецификаций. На всю зарегистрированную посредством использования описанных интерфейсов информацию распространяются ВСЕ механизмы различных подсистем среды электронного документооборота TDMS, а именно:
В любой эволюции четких границ между стадиями не существует. Это правило, разумеется, справедливо и для ступеней внедрения ИПИ-технологий, перечисленных в первой части статьи. Действительно, электронный архив информации об изделии (объекте) не является чем-то статическим. В процессе его создания часто вступают в действие механизмы движения документов. Например, перед поступлением в архив электронного образа чертежа, полученного в процессе сканирования, необходимы процедуры проверки качества сканирования и обработки изображений. При этом далеко не всегда целесообразно, чтобы процессы сканирования, записи в базу данных, обработки изображений (с целью повышения их качества) и верификации осуществлялись одним человеком. В связи с этим не только “полезной”, но и необходимой является автоматизация процедур маршрутизации между пользователями, осуществляющими процесс пополнения архива сканированных документов. Такие механизмы, например, применяются в процессе создания архива сканированной конструкторской и технологической документации на ОАО “Красный Октябрь”.
Опыт показывает, что при создании архива документации проектных организаций целесообразно осуществлять “сбор” комплектов документов, производимых каждым отделом. Такой “сбор” удобнее производить “руками назначенных пользователей”. По окончании процесса формирования комплектов документации от отделов необходима их маршрутизация в электронный архив с проведением проверок, отсылкой на доработку с замечаниями и т.д. Подобная маршрутизация используется в процессе создания электронного архива информации по объектам ОАО “Гипроспецгаз”.
В процессе работы с электронным архивом после его формирования часто возникают задачи, связанные с движением документов, например, формирование заявки в центр печати. При этом должна быть произведена ее маршрутизация с целью согласования между различными пользователями. Маршрут заявки и комплекта документов, подлежащих печати, заканчивается в центре выдачи графической информации (центре печати). Опять налицо движение документов. Такие принципы управления печатью применены в системе электронного архива по верхнему строению платформы Hutton на ФГУП “ПО Севмаш” (проект “Приразломная”).
Отметим также наличие движения документов в электронном архиве в процессе проведения изменений (ревизий), когда имеют место процессы согласования извещений об изменениях, согласования измененных версий документов, рассылки и прочие, связанные с движением документов, их маршрутизацией, согласованиями и прочими “атрибутами” документооборота. Упомянутые механизмы реализованы в ОАО “Красный Октябрь” и ОАО “Гипроспецгаз”.
Таким образом, говорить о четких границах системы электронного архива и документооборота, на наш взгляд, было бы неверно.
Существует несколько подходов, навязываемых производителями той или иной системы документооборота, отдающих высший приоритет тому или иному документопотоку – административному, финансовому, техническому и др. Мы же утверждаем, что принципы и назначение документооборота должны определяться прежде всего родом деятельности организации. Так, документооборот предприятия, занимающегося торгово-закупочной деятельностью, в корне отличается от документооборота проектной организации или промышленного предприятия. В случае, когда предприятие занимается проектированием или производством, можно безошибочно утверждать следующее: любой документ, независимо от того информационного потока, в котором он создан (проектного, технологического, нормативного, административного, финансового), имеет прямую или косвенную связь с продукцией предприятия: изделиями (объектами) – для производственных предприятий или проектными документами (их комплектами) – для проектных организаций. Мы полагаем, что некорректно говорить о приоритетности автоматизации того или иного потока. Более целесообразно, особенно в процессе внедрения ИПИ-технологий, осуществлять автоматизацию документооборота всех информационных потоков.
Организация документооборота разнородных потоков (например, технического, нормативного, финансового и административного) в единой среде позволяет отображать существующие связи между техническими, административными, нормативными, финансовыми, договорными и прочими документами. Подчеркнем, что каждый документ движется в своем потоке, разрабатывается и маршрутизируется различными пользователями. Единая среда лишь отображает связи и позволяет (при наличии прав) получить информацию не только о технических данных по изделию (объекту), но и о маркетинговых, договорных, административных, финансовых и прочих документах. Кроме того, по окончании разработки документы, созданные в разных потоках на различных стадиях ЖЦ, сохраняются в единой БД. Только такая информационная среда поддержки ЖЦ объекта (изделия) может быть полной.
Стоит напомнить, что механизмы единой среды обеспечивают разграничение прав доступа к различным разделам и документам БД. Подобный подход успешно реализуется посредством использования программного комплекса TDMS разработки компании Consistent Software.
Несмотря на наличие в законодательстве нашей страны достаточно давно принятого Федерального Закона РФ об электронной цифровой подписи (Закон об ЭЦП), о реализации его на промышленных предприятиях практически никому и ничего слышать не приходилось. Это связано, по нашему мнению, с рядом причин: недостаточно адекватными формулировками, принятыми в Законе об ЭЦП; с отсутствием региональных центров, некоей инертностью мышления, мешающей принять определяемую Законом об ЭЦП подпись полным аналогом той, которая ставится “вручную” на бумаге. В связи с ограниченным объемом материала не будем подробно описывать все законодательные и технические механизмы ЭЦП.
В связи с назревшей необходимостью решения проблемы подлинности электронного документа, компанией Consistent Software был проработан вопрос о возможности “постановки” ЭЦП в среде TDMS. При этом в качестве самого средства ЭЦП был выбран сертифицированный продукт. В сотрудничестве с одной из санкт-петербургских компаний, являющейся сертифицированным поставщиком средств защиты информации, в том числе и ЭЦП, Consistent Software был создан механизм взаимодействия сертифицированного средства ЭЦП с системой TDMS. Благодаря ему теперь все документы, находящиеся в электронном виде в среде TDMS, могут подписываться ЭЦП, и, согласно Закону об ЭЦП, такая подпись приравнивается к той, которую ответственное лицо ставит на бумаге.
Несомненно, для реализации системы электронного документооборота и ЭЦП в рамках предприятия необходимы нормативные акты – СТП и положения, созданные на основе действующих нормативных документов РФ с учетом конкретной специфики деятельности предприятия. При этом очевидно, что разрабатываемые документы на предприятии не должны противоречить общегосударственным нормативным актам. Задача СТП – конкретизировать положения нормативных документов РФ с учетом рода деятельности предприятия, его организационной структуры и существующих бизнес-процессов.
Краеугольными, на наш взгляд, являются два документа: об электронном документе и об электронно-цифровой подписи. Первый документ должен однозначно определять понятие электронного документа, подлинника, копии и т.д., порядок работы с электронными документами, правила хранения, разработки, уничтожения, ведения электронного документооборота на предприятии. Второй нормативный документ (об ЭЦП) также необходим в связи с тем, что подлинность электронного документа должна быть определена либо в масштабах предприятия, либо в рамках законодательства РФ. Нормативный документ предприятия об ЭЦП должен разрабатываться на основе Закона об ЭЦП и процессов документооборота предприятия.
Примером предприятия, где подобные нормативные акты разработаны, является ОАО “Красный Октябрь”. В настоящее время там проводится работа по реализации системы ЭЦП в системе документооборота в среде TDMS.
Отметим, что в связи с отсутствием регионального центра положение об ЭЦП ОАО “Красный Октябрь” определяет подлинность документа в рамках предприятия. Удостоверяющий центр – “внутренний” и находится на территории завода. С другой стороны, организационные механизмы и используемые сертифицированные средства позволяют без проблем подключиться к региональному центру (в случае его появления).
В случае отсутствия регионального центра ничто не мешает созданию центров, объединяющих несколько предприятий отрасли или какую-либо отрасль. Главным условием при реализации системы электронного документооборота и ЭЦП должна являться возможность подключения всех организационных механизмов и применяемых средств к сети других подобных центров при их появлении. Такими механизмами как раз и обладает решение, предлагаемое компанией Consistent Software SPb/Бюро ESG в среде TDMS.
"REM" 2, 2006 г.
вернуться к
списку