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

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

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

Значительно повышая производительность труда на каждом отдельном рабочем месте, системы проектирования сборок позволяли объединять результаты работы конструкторов в рамках единой информационной трехмерной модели сборки. Однако в дальнейшем прирост эффективности информационного обеспечения и автоматизации процессов производства новой техники связывался уже с системами PDM (product data management — «управление данными об изделии»), выходящими за рамки конструкторских подразделений. Сегодня намечается переход от PDM к корпоративным системам PLM (product lifecycle management — «управление жизненным циклом изделия»), учитывающим процессы, исполнителей, этапность производства и открытым для интеграции данных из других систем и других предприятий. В этих новых условиях «стоимость» каждого шага значительно возрастает, возрастает и ответственность за решения на каждом из них. При этом усиливается стремление предприятия выбирать такую последовательность шагов создания корпоративной информационной системы («стратегию внедрения»), при которой каждый шаг, начиная с первого, имел бы самостоятельную ценность и достаточную частную функциональность.

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

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

Требования к системе «Электронный Архив»

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

Архив Технической Документации обеспечивает хранение, инвентаризацию, учет выдачи и контроль использования технической документации, полученной в результате работы приложений. К такого рода приложениям относятся системы автоматизированной подготовки данных и системы автоматизированного проектирования. САПР могут подготавливать электронное представление чертежно-конструкторской документации либо в своих внутренних форматах, либо в форматах, стандартизованных для различных САПР: IGES, STEP для трехмерных моделей и dwg для двумерных данных. Автоматизированные системы подготовки данных могут использовать СУБД, офисные приложения, текстовые форматы, форматы позиционированных полей вывода (отчеты баз данных, электронные таблицы).

Архив Распорядительной Документации обеспечивает хранение, инвентаризацию, учет выдачи и контроль использования распорядительной документации, полученной в результате работы офисных приложений. К такого рода приложениям относятся Word, Access, Excel, Outlook, Adobe Acrobat, локальные системы распорядительной документации в текстовом виде (АСУ РД). Системы такого рода могут использовать СУБД, офисные приложения, текстовые форматы, форматы позиционированных полей вывода (отчеты баз данных, электронные таблицы), формат Postcrypt.

Научно-Технический Архив обеспечивает хранение, инвентаризацию, учет выдачи и контроль использования распорядительной документации, полученной в результате работы офисных приложений и приложений работы со сканированными документами (сканирование, очистка, оцифровка и т.д.). К такого рода приложениям относятся Word, Access, Excel, Outlook, PowerPoint, Paint, CorelDraw, Adobe Photoshop. Автоматизированные системы подготовки такого рода данных могут использовать СУБД, офисные приложения, текстовые форматы, форматы позиционированных полей вывода (отчеты баз данных, электронные таблицы), форматы сканированных изображений (JPEG, GIF, TIFF, BMP), формат Postcript.

Необходимо отметить также, что во всех трех случаях в перспективе нужно ориентироваться на необходимость архивирования сетевых данных.

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

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

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

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

Электронный Архив должен реализовывать методику распределенного хранения. Это требование возникает при сетевой организации хранения данных архива и при постоянном росте объема хранимых данных.

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

Одной из основных функций Электронного Архива является организация информационно-поисковых служб. Наличие в Электронном Архиве своей собственной поисковой машины или одной из наиболее продвинутых поисковых машин других производителей в качестве встроенной — способ обеспечения качественного уровня обращения за данными к архиву.

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

Требования к системе «Документооборот с поддержкой жизненного цикла»

Современная система электронного документооборота с интегрированной поддержкой жизненного цикла изделия (Docflow + Workflow + Life Cycle Management) должна охватывать все рабочие места в корпоративной информационной среде предприятия. Средства управления потоком заданий на протяжении всего жизненного цикла (Workflow + LifeCycle) обеспечивают единые, но при этом достаточно гибкие правила управления процессом изготовления документа, разделяя его на отдельные рабочие задания. Средства управления потоком заданий современной системы документооборота позволяют значительно улучшить качество управления организационной деятельностью, а пользователи получают возможность заранее подготовиться к выполнению своих бизнес-задач.

Современная система электронного документооборота и интегрированная с ней система поддержки жизненного цикла изделия должна реализовывать следующие основные функции:

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

Требования к системе PDM

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

Cистема PDM должна реализовывать следующие функции.

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

Требования к системе управления конфигурацией

Система управления конфигурацией изделия (configuration management — CM) обеспечивает обмен данными о структуре изделия и вносимых в него изменениях, позволяет создавать и поддерживать множество взаимосвязанных спецификаций на модификации и исполнения изделия («заказные спецификации»). Благодаря этому пользователь получает согласованное представление обо всех конфигурациях изделия по ходу работы над ним. Система СM дает возможность различным корпоративным системам и пользователям определять и контролировать действия по внесению изменений в изделие, тем самым упрощая процессы совершенствования и модификации изделия. Без современной системы СМ невозможна работа крупного предприятия, выпускающего широкую номенклатуру изделий под разнообразные заказы.

Система CM должна реализовывать следующие функции:

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

Концепция объектов Электронного Архива

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

Рис.1. Схематическое представление объекта «Документ» Электронного Архива. Документ в Электронном Архиве доступен для поиска и по значениям своих свойств, и как элемент структуры Документов Электронного Архива и как контейнер контента

Для отображения ссылок, которые могут иметь документы архива, объект типа Документ Электронного Архива (рис. 1) должен иметь возможность ссылаться на другие объекты типа Документ Электронного Архива. Так, документ «Инструкция по сборке» может иметь ссылку на хранящийся отдельно и даже, возможно, в составе другой структуры документов, документ «Стандарты предприятия».

Для хранения содержимого архивов 3D-моделей деталей, сборок, узлов и агрегатов служит объект «Деталь». В полнофункциональной реализации концепции Электронного Архива контент Детали представляет собой собственно трехмерную модель. Объект Деталь может входить в структуры, образованные такого рода объектами. Например, Деталь «Сборочная единица ААА» архива технической документации может состоять из нескольких Деталей — «Подсборка ААА1», «Деталь B1», «Деталь B2» и т.д., а каждая их этих Деталей, в свою очередь из Деталей более нижнего уровня (Деталь «Подсборка ААА1» может представлять собой структуру, включающую в себя Детали «Подсборка АААА1», «Деталь С1», «Деталь С2» и т.д.). Вхождения такого рода должны иметь количественный признак, отображающий реальный состав сборок: столько-то таких-то деталей в составе одной сборки, столько-то таких-то сборок в составе изделия и т.д.

Чтобы получить дополнительную описательную информацию, не содержащуюся ни в 3D-модели, ни в структуре сборки, объекты типа Деталь должны ассоциироваться с объектами типа Документ Электронного Архива, контент которых содержит уточнения и пояснения для полного описания собственно детали.

Для отображения ссылок, которые могут иметь документы архива, объект типа Деталь Электронного Архива должен иметь возможность ссылаться на другие объекты типа Документ Электронного Архива. Так, Деталь «Винт М4х1.5» может иметь ссылку на хранящийся отдельно и даже, возможно, в составе другой структуры документов, документ «ГОСТ 14.876-78», контентом которого, в свою очередь, может являться описание стандартизованных резьбовых соединений. Схематически вид объекта Деталь в концепции современного Электронного Архива производственных данных можно представить так, как изображено на рис. 2.

Рис.2. Схематическое представление объекта «Деталь» Электронного Архива. Деталь в Электронном Архиве доступна для поиска и по значениям своих свойств, и как элемент структуры Документов Электронного Архива, и как контейнер контента и по набору своих атрибутов

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

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

Рис.3. Страница каталога электронного архива технической документации основного производства в Windchill: страница разбита на «строки», где содержится вся необходимая учетная архивная информация и ссылки для выхода на учетную архивную карточку по каждому элементу архивного хранения
Рис.4. Учетная архивная карточка в Windchill: хранится вся доступная информация как в структурном виде («дерево сборки»), так и в виде трехмерных моделей. Для получения дополнительной информации (исполнитель, разработчик, контроль, состояние и т.д.) служат ссылки
Рис.5. Учетная карточка архивного документа в Winchill. Отображаются непосредственно все необходимые учетные данные: Наименование документа, Обозначение документа, Состав (иерархическая структура, «дерево оглавления»), кем, когда и в рамках какого проекта создан, кем взят в работу и т.д. Состав документа отображает связи, запрошенного документа с другими документами, хранящимися в архивах Windchill
Рис.6. Отображение в Windchill структуры архивов корпорации: слева иерархическая структура предприятия, а справа — «взятый» в работу конкретным подразделением набор архивированных данных (данные САПР, документы, отчеты по базам данных и т.д.) с отображением по каждому из них их типа, состояния, даты последней активизации в архиве и т.д.
Рис.7. Примерный вид рабочего места пользователя-исполнителя в системе Windchill при работе в системе документооборота с управлением составом работ в рамках жизненного цикла. Пользователь получает работу вместе с инструкцией (вверху в центре), ссылками на обзор сетевого графика данного этапа жизненного цикла (позиция Process в верхнем правом углу экрана), ссылкой на сам объект данных (ссылка в центре экрана). Пользователь может принять решение по текущему содержанию или состоянию документа (например, как в данном случае: изменить или утвердить), открыть виртуальное обсуждение (Discuss) в сети, сделать пометки на будущее и даже (при наличии соответствующих прав) изменить содержание, структуру или отдельные характеристики самого документа
Рис. 8. Примерный вид сетевого графика выполнения работ и протокола прохождения документа (нижняя часть экрана: дата зафиксированного начала и окончания работы, информация о том, кто должен был ее сделать и кто в действительности выполнял и т.д.)



Рис. 9. Дерево сборки, в виде списка составляющих (позиция — количество — наименование — ссылка на учетную карточку — номер версии), в виде структуры изделия и списка составляющих, отображаемых по их месту в архиве предприятия







Одной из немногих сетевых корпоративных информационных систем управления производственными данными, позволяющих реализовать концепцию современного Электронного Архива, является система Windchill. Практическую реализацию Электронного Архива в ее среде можно проиллюстрировать последовательностью снимков экрана, полученных в работающей корпоративной информационной системе (рис. 3-9). Как видно из приведенных иллюстраций и пояснений к ним, современная система PDM может решить все базовые задачи автоматизации архивной службы предприятия, включая основные задачи архива технической документации, архива распорядительной документации, научно-технического архива. При реализации функций ведения разнотипных архивов применимость системы PDM тем выше, чем более унифицированный подход включения данных в состав архивных материалов использует эта система. Возможность использовать систему PDM при реализации практически всех задач Электронного Архива позволяет внедрять PDM и в качестве полноценной замены (если архив уже есть), и в качестве полнофункционального эквивалента Электронного Архива.

Вячеслав Климов (vklimov@ptc.com) — генеральный директор представительства PTC (Москва); Владимир Краюшкин (vkrayushkin@ptc.com) — ведущий специалист представительства РТС (Москва); Марина Пирогова (mpirogova@col.ru) — доцент МЭИ.