CADmaster

ОАО «Новосибирский завод химконцентрато» — одно из крупнейших предприятий российского ядерного топливного цикла по выпуску ядерного топлива для энергетических и исследовательских реакторов, производству лития и его соединений, основанное 25 сентября 1948 года.

НЗХК сегодня — это предприятие с гармонично развитой инфраструктурой, выпускающее продукцию мирового уровня, разрабатывающее технологии завтрашнего дня.

Введение

В статье «Внедрение информационной системы как способ совершенствования бизнес-процессов предприятия» (CADmaster № 1/2005) описывалась подготовка к внедрению системы 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). Разработанные ранее файлы документа пользователь добавляет в версию основного документа, а файл с извещением — в электронный документ вида «Извещение об изменении». Файлы могут содержать как оригиналы документов (если они существуют), так и их электронные образы, т.е. сканированные изображения.

Рис. 1. Помещение в электронный архив существующего документа и извещения, по которому внесено последнее изменение

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

Рис. 2. Связи между документами и объектами БД

Примечание к рис. 2

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

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

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

Рис. 3. Электронные документы, связанные со сборочной единицей, и возможные действия конструктора при работе с ними

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

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

Рис. 5. Связь между объектами после создания ИИ при изменении одного документа

Рис. 6. Связь между объектами после создания ИИ при изменении нескольких документов и аннулирования ПИ

Примечание к рис. 6

• — обозначение аннулирующей связи между ИИ и ПИ.
• У документа 123.1234.0000 существуют две одновременно действующих в настоящий момент версии: одна соответствует подлиннику без изменений, а другая — документу с изменениями по ПИ. При этом текущей (по умолчанию) является версия, соответствующая подлиннику без изменений, поскольку предварительные изменения в рабочую документацию не вносятся.
• Электронная спецификация в данном примере имеет три версии, при этом по умолчанию разными службами предприятия используется версия 2255−2005 И0, но на пробную партию или спецзаказы можно выбрать версию 123.1747−05 ПИ с предварительными изменениями, поскольку она тоже действует. Третья версия изм1 123.1503−05 находится в статусе «В разработке», ее редактирует конструктор, и до введения в действие связанного извещения остальные службы могут только просматривать ее, но не имеют права использовать в работе.

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

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

Рис. 7. Формирование списка подписей, которые необходимо собрать в процессе электронного документооборота

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

Рис. 8. Маршрутизация документа в электронном архиве

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

Рис. 9. Маршрутизация документа в электронном архиве

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

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

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

Рис. 10. История разработки извещения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 11. Протокол электронного согласования, полученный в форме отчета из базы данных

Рис. 12. Электронные подписи извещения, собранные в процессе электронного документооборота

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 13. Версии документа и извещение, связанное с одной из них

Рис. 14. Документы, связанные с извещением

Таким образом, внедрение электронного архива TechnologiCS в ОАО НЗХК позволит упорядочить большой объем технической информации, организовать эффективное выполнение процессов КТПП и управление ими, что приведет к значительному повышению эффективности работы предприятия в целом.

Скачать статью в формате PDF — 386.5 Кбайт