Конструкторская подготовка производства

Начиная с версии TechnologiCS 4.34, существенно расширены возможности по применению штрих-кодирования для решения самых разнообразных задач. Ниже приведены несколько примеров работы со штрих-кодами применительно к задачам инженерного документооборота.

Генерация штрих-кода

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

Назначаемый штрих-код сохраняется в буфере обмена. Если затем открыть документ на редактирование с помощью соответствующей CAD-системы, то можно (например, посредством стандартной командой "Вставить") поместить присвоенный штрих-код на поле чертежа (Рис. 2).

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

Если штрих-код размещается, как описано выше, непосредственно на электронном документе, то он, естественно, просто распечатывается вместе с чертежом (Рис. 3).

Поиск по штрих-коду

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

Затем достаточно просто поднести сканер к штрих-коду на бумажном чертеже – на экране мгновенно откроется электронный документ, посредством распечатки которого был получен данный бумажный чертеж (Рис. 5). В карточке электронного документа содержится полная информация о нем:

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

Более подробные примеры использования некоторых из этих свойств электронных документов приведены в книге-учебнике «TechnologiCS. Информационная поддержка производственных процессов. Пример настройки и использования системы. Подготовка производства».

На Рис. 5 показано, как открыть для просмотра или редактирования файл электронного чертежа.

Отметим один очень важный момент. Как мы уже говорили, штрих-код, распечатанный на бумажном чертеже, уникален. Кроме того, он присвоен в TechnologiCS не просто электронному документу, а конкретной версии этого документа. Здесь же уместно вспомнить и о том, что система TechnologiCS предоставляет широкие возможности по управлению состояниями и версиями электронных документов, а именно:

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

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

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

Существует возможность расширять область применения описанной выше функции "Поиск по штрих-коду" (Рис. 4) за счет возможностей самой системы TechnologiCS. Помимо электронного чертежа, в базе данных может содержаться множество различной информации. Использование закладки "Связанная номенклатура" карточки электронного документа позволяет, например, поднеся сканер к бумажному чертежу, сразу открыть на экране техпроцесс изготовления соответствующей детали и 3D-модель для наглядного представления (Рис. 6) и при помощи стандартных средств TechnologiCS посмотреть применяемость и т.д.

Чтобы открыть на одном экране структуру справочника, модель детали, техпроцесс изготовления, дополнительную технологическую информацию (трудоемкость, эскиз применяемого инструмента), используются уже исключительно стандартные функции TechnologiCS, применение которых подробно описано в книге-учебнике.

Изменение состояния электронного документа по штрих-коду

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

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

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

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

В качестве возможного способа решения указанных проблем предлагается описанная ниже простая технология организации работы.

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

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

Все описанные примеры включены в ознакомительную версию системы TechnologiCS V6. Чтобы воспроизвести их на своем рабочем месте, достаточно:

• установить ознакомительную версию TechnologiCS;
• подключить к компьютеру стандартный сканер штрих-кодов. Мы использовали широко распространенную модель сканера Zebex, которая при стоимости около $70 подключается к USB-порту и не требует никакого специального программного обеспечения или драйверов;
• распечатать из электронного архива ознакомительной версии TechnologiCS бумажные чертежи с присвоенными штрих-кодами – любой чертеж из раздела архива «КБ-1 – Детали». Поскольку наиболее распространенными печатающими устройствами остаются различные офисные принтеры формата А4, чтобы быстро собрать в ознакомительной версии TechnologiCS документы для печати и просмотра примеров, можно воспользоваться уже настроенной (для пользователя «Администратор») выборкой из архива (Рис. 8). Мы использовали обыкновенный лазерный принтер HP формата A4.
  
  
• Рис. 8. Выборка документов из электронного архива в ознакомительной версии TechnologiCS

<< К содержанию

Новая технология работы с электронным архивом:

Приложение "TCS Explorer"

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

Остановимся для начала на нескольких типичных проблемах практической работы с электронным архивом при его использовании, например, конструкторами. В соответствии с наиболее распространенной сегодня идеологией, внедрение системы управления электронными документами влечет за собой достаточно существенные изменения порядка работы рядового пользователя. Конструктор должен сначала зайти в систему документооборота, создать или найти в ней документ, выполнить определенные действия, а уже затем перейти непосредственно к своей работе в системе автоматизированного проектирования (CAD). В то же время:

• большинство пользователей привыкли работать с приложениями (CAD-системами, MS Word и т.д.), а также с папками и файлами именно на своем компьютере. Необходимость использовать для создания каждого нового файла (документа) какую-то дополнительную систему обычно не вызывает у них особого энтузиазма, тем более что это не относится к их прямым обязанностям;

• большая часть современных Windows-приложений (в том числе всевозможные CAD/CAM/CAE-системы) изначально ориентирована на работу в локальном режиме, то есть с конкретными файлами и папками на конкретном компьютере. Попытка корректно организовать взаимодействие, скажем, CAD-системы и некой сетевой системы управления документами (особенно если проект состоит не из одного, а из множества взаимосвязанных файлов) неизбежно ведет к необходимости применять специальные стыковочные модули и интерфейсы. В свою очередь это порождает различные технические трудности, замедляет работу или требует нестандартного порядка работы с приложениями (CAD-системами), использования специальных программ и функций и т.д.;

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

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

Отдельно можно отметить проблемы работы с большими проектами – например, со сборками, включающими сотни и тысячи деталей. В таких случаях применение единой системы централизованного защищенного хранения электронных документов почти всегда ведет к замедлению работы – из-за необходимости передавать файлы по сети. Как правило, чем больше размеры и количество файлов в одном проекте, тем ощутимее замедление, например, при открытии проекта из архива на компьютере пользователя. Увеличение числа пользователей, одновременно работающих с электронным архивом, еще заметнее ухудшает скоростные характеристики системы. Кроме того, судя по дискуссиям, периодически разворачивающимся на Internet-форумах, сегодня нет какой-либо общепринятой методики организации коллективной (параллельной) работы множества пользователей с единой системой электронного архива в рамках больших проектов. В основном можно видеть вопросы, как именно такую работу организовывать, – причем не на уровне общих слов, а более конкретно, на примерах.

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

В основу технологии положены следующие принципы:

• работа пользователя в общей информационной среде внешне, насколько это возможно, приближена к привычной работе с файлами и папками в MS Windows. Иными словами, для специалиста, который работает на своем компьютере, нет большой разницы между файлами на жестком диске и документами электронного архива. Он работает с ними единообразно, но при этом может использовать дополнительные сервисы системы электронного документооборота;

• пользователь самостоятельно управляет своей работой с электронным архивом: сам определяет, какой файл из проекта, над которым он работает, регистрировать в архиве как документ, а какой нет, в какой момент это делать, требуется ли обновить файлы в архиве и т.п.

Для реализации этих принципов разработано небольшое бесплатно распространяемое приложение "TCS Explorer". Рассмотрим его работу на примере.

В локальной сети предприятия пользователь (конструктор) работает в единой информационной среде со своими коллегами. Электронный архив и общезаводская база данных по изделиям доступны ему при необходимости в системе TechnologiCS (конфигурация PDM). Основная же его работа заключается в проектировании узлов и деталей, оформлении конструкторской документации, для чего он использует обычную САПР – например, AutoCAD. Для просмотра прочих документов в электронном виде (записок, распоряжений и др.) и работы с ними применяются широко распространенные программы, такие как MS Word, Excel и т.д.

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

В процессе работы он как обычно создает новые файлы, копирует, переименовывает и дорабатывает старые, но в любой момент может перейти от обычной работы в локальном режиме к работе в единой информационной среде. Для этого ему достаточно выбрать интересующую папку на своем диске и в обычном контекстном меню проводника вызвать команду "Показать как документы TechnologiCS" (рис. 1).

Используя контекстное меню, открываем на просмотр папку на диске в представлении системы электронного архива и документооборота

Если в этот момент TechnologiCS не запущен, система попросит для аутентификации пользователя ввести имя и пароль (рис. 2).

Для подключения к электронному архиву нужно ввести свое имя и пароль

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

Содержимое папки на локальном диске при подключении к электронному архиву

Рассмотрим рисунок поподробнее. Если файл зарегистрирован как документ в электронном архиве, то в средней части окна показываются обозначение и наименование соответствующего документа. Конечно, при этом сам документ в любом случае находится не у пользователя, а в специальном защищенном хранилище, где-то на серверах в сети. У пользователя на диске – его копия. Таким образом, сразу видно, какие файлы проекта уже помещены в электронный архив (или из него и были взяты), а какие нет.

Коллективная работа подразумевает возможность одновременной работы над одним проектом множества пользователей. При этом конструктор, выполняя свою часть этой работы, какие-то файлы заимствует из общего архива, а какие-то сам создает, редактирует и помещает в архив. Если файлы на диске и в документах электронного архива отличаются, то в правом столбце выводится информация, где сейчас находится более новая версия соответствующего файла. Данное представление называется "кратким". Если, как показано на рис. 4, включить "подробный" вид, на экране отобразится полная информация о документе электронного архива: его текущее состояние, у кого он в данный момент находится на редактировании, номер и наименование текущей версии и т.д.

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

Как мы уже отмечали, часть файлов для своей текущей работы пользователь может заимствовать из общего электронного архива. Для этого достаточно, работая с папкой на своем компьютере, вызвать правой кнопкой контекстное меню и выбрать команду "Открыть" → "Документы архива" (рис. 5).

Работая с проектом на своем компьютере, можно взять нужные документы из единого электронного архива

По этой команде открывается стандартное окно подсистемы электронного архива TechnologiCS, в котором отображаются:

• структура архива (только разделы, доступные данному пользователю);

• документы, хранящиеся в соответствующем разделе архива, и информация о них: обозначение, наименование, автор, дата создания, текущее состояние, номер и название версии и др.;

• любая дополнительная информация о документе по выбору пользователя: файлы документа (как показано на рисунке), требуемые и уже проставленные электронные подписи, история изменения состояния документа, дополнительные атрибуты и т.д.

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

Таким образом, если пользователь не просто создает новый файл на диске, а берет его из электронного архива, действуют следующие простые правила:

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

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

Когда требуется представить картину более наглядно, включается расцветка "По доступности документов" (рис. 6).

Цвет наглядно показывает, какие файлы взяты из документов, которые пользователь не может редактировать

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

Все указанные цвета каждый пользователь может настроить для себя по своему усмотрению.

Другой вариант отображения – "Цвета по соответствию файлов" (рис. 7).

В этом режиме цветом выделяются файлы, версии которых различаются в архиве и на локальном диске

Этот режим удобен, например, при параллельной работе группы конструкторов над одним проектом. Он позволяет наглядно представить соответствие файлов рабочего проекта на локальном диске и в общем централизованном хранилище. Красным цветом выделены файлы, версия которых в электронном архиве новее той, что находится на диске пользователя. Зеленым – файлы, которые уже были зарегистрированы как документы в электронном архиве, но в настоящий момент на локальном диске находится их более новая версия. Черный цвет маркирует файлы, одинаковые в архиве и на диске либо вообще не зарегистрированные в архиве. Отличия соответствующих файлов на диске и в электронном архиве можно просмотреть визуально. Чтобы открыть свою локальную копию файла, достаточно дважды щелкнуть на нем мышкой – как в обычном проводнике. Чтобы открыть файл из соответствующего документа в электронном архиве, нужно использовать контекстное меню и команду "Показать документ", как показано на рис. 8. При этом откроется окно электронного архива, а курсор будет установлен на соответствующем документе. Рисунок иллюстрирует применение стандартной команды из контекстного меню TechnologiCS для просмотра файлов документа.

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

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

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

• минимальная нагрузка на сеть: между сервером и пользователем передаются только обновленные файлы (по запросу или по команде);

• вне зависимости от используемой CAD-системы минимизируются проблемы, связанные с коллективной работой: сама САПР фактически работает в штатном режиме, с файлами на жестком диске пользователя;

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

• права доступа к различным частям проекта и невозможность корректировки «чужих» файлов автоматически обеспечивает подсистема документооборота TechnologiCS – посредством разграничения прав доступа к документам в едином электронном архиве. И в то же время творческая свобода конструктора не ограничивается искусственно: в локальном режиме он при необходимости может редактировать любые файлы, но при этом знает, какие изменения сможет сохранить в рамках общего проекта, а какие нет.

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

Обновление файлов на диске и в электронном архиве

В режиме "Автоматически" более старая версия файла заменяется более новой независимо от того, где какая из них находится. Если файл в архиве новее, чем на диске пользователя, последний автоматически заменяется первым и наоборот. Можно принудительно задать «направление» обновления: из архива на диск или с диска в архив – в этом случае при попытке заменить файл более старым его вариантом выдается предупреждение, а замена производится только после подтверждения. Появляется предупреждение и при попытке сохранить в архиве файл, взятый из документа, недоступного пользователю для редактирования (рис. 10).

Предупреждение о том, что измененный файл невозможно сохранить в электронном архиве

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

Сохранение файла как документа в электронном архиве

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

Обратите внимание, что предлагаемая технология работы с системой электронного архива и документооборота совершенно не зависит от используемого пользователем приложения (CAD/CAM/CAE-системы или какой-либо другой программы). Основное преимущество этого подхода, с нашей точки зрения, заключается в разумном совмещении положительных сторон работы в локальном режиме и в системе электронного документооборота.

<< К содержанию

Электронный документооборот в TechnologiCS:

Результаты внедрения на крупном предприятии

Введение

В начале 2005 года в журнале CADmaster (№ 1/2005) была опубликована статья "Внедрение информационной системы как способ совершенствования бизнес-процессов предприятия", где описывалась подготовка к внедрению системы TechnologiCS в ОАО «Новосибирский завод химконцентратов» (ОАО НЗХК). К настоящему моменту основной объем подготовительных работ уже выполнен и процесс внедрения перешел к стадии запуска системы в промышленную эксплуатацию. В данной статье мы более подробно остановимся на применении TechnologiCS в ОАО НЗХК в качестве системы электронного документооборота технической документации (по западной терминологии – Technical Data Management, TDM).

Хотя процессы конструкторско-технологической подготовки производства (далее КТПП) ОАО НЗХК можно считать типовыми для предприятий машиностроительной отрасли, они имеют одну существенную особенность, связанную с высокими требованиями к обеспечению безопасности выпускаемой продукции. ОАО НЗХК – один из крупнейших производителей топлива для атомных станций, поэтому все конструкторские и технологические документы здесь проходят постоянный и жесткий контроль со стороны внутренних контролирующих служб предприятия, потребителей и государственных органов контроля. В таких условиях все стадии жизненного цикла технического документа должны быть четко прослеживаемы, а качество документа управляемо.

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

С учетом вышеприведенных задач и условий был разработан и осуществлен план процессно-ориентированного внедрения автоматизированной системы конструкторско-технологической подготовки производства на базе программного обеспечения TechnologiCS. В этой статье мы ограничимся описанием полученных результатов одной из стадий проекта – этапа реализации.

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

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

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

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

Настройка TechnologiCS для реализации процессов КТПП

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

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

1. «Виды документов» – содержит используемые в ОАО НЗХК виды электронных документов с их атрибутами, маршрутами проверки/согласования;
2. «Атрибуты» – содержит список возможных атрибутов для электронных документов;
3. «Типы файлов» – содержит типы используемых файлов с настройкой для каждого типа соответствующих ему команд и внешних приложений обработчиков;
4. «Способы обработки документов» – содержит шаблоны маршрутов, в соответствии с которыми происходит изменение статуса документа в процессе электронного документооборота;
5. «Статусы» – содержит все возможные статусы, которые может иметь документ в электронном архиве, с настройкой доступных действий над документом в каждом статусе;
6. «Виды связей документов» – содержит список возможных связей, которые могут устанавливаться между версиями документов;
7. «Виды подписей» – содержит список всевозможных видов подписей, которые могут быть проставлены на документе в процессе различных проверок и согласований;
8. «Рабочие группы» – содержит список рабочих групп. Рабочие группы объединяют пользователей с различными ролями при работе с одними и теми же документами. Выполняемая в рабочей группе роль определяет права доступа пользователя к данному документу, например, просмотр документа и простановка/отмена соответствующей подписи;
9. «Роли» – содержит список ролей с настроенными шаблонами прав;
10. «Шаблоны прав» – содержит список шаблонов прав с настроенными возможными действиями над документом;
11. «Справочные таблицы» – в зависимости от отдела разработчика, вида документа и объекта, к которому он относится, содержат сведения для автоматического размещения документа в электронном архиве (используются при создании документов с помощью соответствующих скриптов);
12. «Скриптовые модули» – содержит модули со специально разработанными скриптами. Такие скрипты, состоящие из последовательно вызываемых стандартных действий, по окончании работы обеспечивают создание необходимых взаимосвязанных записей в различных режимах системы, не позволяя пользователю забыть сделать все необходимое.

Управление информацией в электронном архиве TechnologiCS

Документы электронного архива условно можно разделить на основные и управляющие. В основных документах хранится техническая информация (чертежи, спецификации, техпроцессы, технологические инструкции) и они имеют версии (изменение 1, изменение 2 и т.д.). Управляющие документы (извещения¹) содержат информацию о характере изменений в основных технических документах, условия и период действия данных изменений. Таким образом, извещение выступает в роли документа, управляющего состоянием связанных с ним объектов, которыми могут являться как версии основных технических документов, так и версии объектов базы данных (электронные спецификации и электронные техпроцессы) или то и другое одновременно. В нашем проекте методику работы пользователей с электронным архивом было решено построить таким образом, чтобы любое создание/изменение любого технического документа сопровождалось выпуском извещения и созданием соответствующей версии, вводимой в действие данным извещением. В электронном архиве системы TechnologiCS документы можно связывать различными типами связей, которые в дальнейшем используются для автоматизации выполнения различных функций, а также для оперативного доступа пользователей к связанным документам. Каждому типу связи может соответствовать своя логика выполнения автоматических действий над связанными документами при каком-либо событии. Например, после утверждения ИИ необходимо сменить статус всех связанных с ним версий технических документов. Виды соответствующих связей определяют, какие документы аннулировать, а какие ввести в действие.

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

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

Разработка документов в электронном архиве TechnologiCS

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

До внедрения электронного архива на предприятии, конечно, уже существовало множество документов, многие из которых были неоднократно изменены. Поэтому, прежде всего, требовалось корректно разместить их в электронном архиве, т.е. создать текущие образы документов и соответствующие извещения с организацией связей между ними. При этом размещать абсолютно все извещения и версии документов не было необходимости (тем более что в традиционной практике, когда изменения вносятся прямо в бумажный подлинник, версий у документов просто не существует). Следовало включить в электронный архив только действующие и актуальные на текущий момент образы документов и соответствующие им извещения. Для этого был разработан скрипт «Создание документа РКД по ИИ»: система запрашивает обозначение извещения, информацию о техническом документе и номер последнего изменения, осуществленного по этому извещению (рис. 1), а затем автоматически создает извещение об изменении и связанный с ним технический документ (рис. 2). Разработанные ранее файлы документа пользователь добавляет в версию основного документа, а файл с извещением – в электронный документ вида «Извещение об изменении». Файлы могут содержать как оригиналы документов (если они существуют), так и их электронные образы, т.е. сканированные изображения.

Для всех новых документов, помещенных в электронный архив со своей первой версии (соответствующей подлиннику без изменений), разработчики используют скрипт «Создание документа РКД “с нуля”». При этом система автоматически создает и помещает в нужный раздел архива документ вида «Извещение 0». Обозначения для таких извещений генерируются системой автоматически. Затем создается технический документ, автоматически именуется его версия (в соответствии с оговоренным шаблоном), которая связывается с извещением. Оба документа связываются с деталью или сборочной единицей, к которой они относятся (рис. 2). Файл документа добавляется в версию основного документа или разрабатывается непосредственно в электронном архиве.

Внесение изменений в документы в электронном архиве TechnologiCS

При необходимости внесения в документы изменений используется скрипт «Создание ИИ РКД» (для изменения документов по извещению об изменении) или скрипт «Создание ПИ РКД» (для проведения предварительных изменений в документах).

Разработчик запускает скрипт (рис. 3), в котором система запрашивает обозначение извещения, список меняющихся по этому извещению документов и список документов, аннулирующихся извещением (рис. 4). Пока извещение находится в разработке, эти списки можно изменять. Затем создается собственно извещение и новые версии технических документов с учетом внесенных изменений. Извещение связывается с соответствующими версиями технических документов управляющей связью, а с документами, которые аннулируются при введении в действие данного извещения – аннулирующей связью (рис. 5, 6).

Документооборот в архиве TechnologiCS

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

После определения списка подписей разработчик отправляет документ на проверку (рис. 8).

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

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

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

Когда документ прошел все проверки и согласования, утвержден, зарегистрирован и введен в действие, перевести его в статус «В разработку» уже невозможно. Для внесения в действующие документы изменений следует создавать новые версии и согласовывать соответствующие ИИ. Конечно, перевод документа на доработку логичнее поручить опять-таки именно разработчику, а не проверяющему, поскольку именно разработчик решает, изменять проект документа или не изменять, а также дает дополнительные разъяснения, способствующие принятию именно этого варианта и/или изменению другого проекта документа.

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

• разработчик избавлен от необходимости лично обходить подразделения предприятия, которые территориально могут находиться далеко друг от друга;
• не требуется создавать лишние копии для рассылки проекта документа в подразделения, хотя при необходимости каждый пользователь может распечатать документ;
• общение между разработчиком и проверяющими может осуществляться в режиме реального времени посредством почтового сервиса системы TechnologiCS или любых других средств связи;
• правка и обсуждение нового проекта документа может осуществляться непосредственно после поступления замечаний.

Нормоконтроль и электронный документооборот

Если преимущества использования электронного документооборота по сравнению с бумажным на этапах проверки/согласования очевидны, то на этапах утверждения и нормоконтроля, как показывает практика, они никак не проявляются. Во-первых, работа с документом здесь ведется в строгой последовательности в соответствии с ЕСКД. Во-вторых, подписи нормоконтролера и утверждающего имеют юридическую силу лишь на бумажном подлиннике, поэтому проставлять их сначала на электронном документе в базе данных, а затем на соответствующем бумажном носителе (или наоборот) – это значит дублировать одни и те же действия и дополнительно загружать персонал. Поэтому при внедрении электронного документооборота в ОАО НЗХК было принято компромиссное решение, которое предусматривало не полное замещение традиционного бумажного документооборота электронным, а их совместное использование.

Рассмотрим значение каждой подписи, поставленной на документ в процессе согласования и определим, чем отличаются подписи проверяющих и согласующих от подписей нормоконтролера и утверждающего.

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

В соответствии с ГОСТ 2.111-68 (Изм. № 3), одной из задач нормоконтроля является соблюдение в конструкторской документации норм, требований и правил, установленных в стандартах ЕСКД и в других нормативных документах. Таким образом, при проведении нормоконтроля проверяется не только содержание, но и оформление документа. Осуществление нормоконтроля электронного оригинала документа вызывает определенные трудности.

Во-первых, электронный образ документа, воспроизводимый на экране монитора разработчика документа, может не соответствовать электронному образу на экране монитора нормоконтролера из-за:

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

Во-вторых, оформление электронного оригинала может соответствовать необходимым нормам, а полученный с него отпечаток – нет из-за:

• версии программного обеспечения;
• установленных драйверов и шрифтов печатающего устройства;
• технических возможностей печатающего устройства;
• настроенного текущего масштаба печатающего устройства.

Таким образом, электронная подпись нормоконтролера не может заменить подлинную, а следовательно, ее не имеет смысла проставлять в процессе электронного документооборота.

Именно на бумажном носителе следует ставить и подпись утверждающего, поскольку она завершает процесс разработки и придает бумаге юридическую силу.

Итак, сбор всех проверяющих/согласующих подписей документа осуществляется на его электронном оригинале с помощью электронного документооборота. Затем разработчик на своем рабочем месте распечатывает файл из электронного архива и несет его нормоконтролеру, который осуществляет нормоконтроль уже ставшего подлинником бумажного документа и именно его визирует.

В соответствии с ГОСТ 2.111-68 (Изм. № 3), нормоконтроль конструкторских документов рекомендуется проводить в подлинниках при наличии всех подписей лиц, ответственных за их содержание и выполнение, кроме утверждающей подписи руководителя организации или предприятия. При этом «документацию, утверждаемую руководителем организации или предприятия, нормоконтролер визирует до передачи на утверждение и подписывает в установленном месте после утверждения».

Внедрение электронного документооборота – довольно сложный и растянутый во времени процесс. Невозможно в одночасье заменить традиционный документооборот во всех подразделениях предприятия. Какой-то период времени должны сосуществовать оба подхода. В это время возникает необходимость в переносе на бумажный документ всех подлинных подписей на основе отчета «Протокол электронного согласования…» из базы данных (рис. 11). Просмотреть список подписей и историю разработки документа пользователь (проверяющий) может в электронном архиве TechnologiCS (рис. 12). В дальнейшем, после внедрения электронного документооборота на стадиях проверки/согласования, можно будет отказаться от формального сбора подписей проверяющих и согласующих документ лиц и в подлиннике собирать только необходимые, предусмотренные стандартами, контрактами и прочими нормативными документами подписи, избегая дублирования и ускоряя процесс разработки документа.

Таким образом, к моменту простановки подписи утверждающего на бумажный подлинник, существует два информационных объекта: документ в электронном архиве с электронными подписями проверяющих/согласующих и документ на бумажном носителе с тем же составом подлинных подписей и визой нормоконтролера. Затем в соответствии с ЕСКД подлинник, подписанный утверждающим и нормоконтролером, сдается в архив, а соответствующий электронный документ нормоконтролер переводит в статус «На учете». Так обеспечивается одинаковое состояние электронных и бумажных носителей идентичной информации.

Учет документов и актуализация информации в электронном архиве

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

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

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

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

Преимущества TechnologiCS при использовании в качестве системы электронного документооборота

На сегодняшний день ни у кого не вызывают сомнений преимущества использования данных из централизованных хранилищ электронных документов, обеспечивающие:

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

Перед пользователями электронного архива TechnologiCS дополнительно открываются следующие возможности:

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

Для разработчиков:

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

Для руководителей проектов:

• возможность оперативного получения информации о состоянии каждого документа проекта без необходимости обращения к исполнителям или сторонним согласующим лицам.

Для предприятия как юридического лица:

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

<< К содержанию