Автоматизация потоков документации — важный шаг к созданию ЕИП

СПб ОАО «Красный Октябрь» специализируется на производстве, ремонте и обслуживании силовых агрегатов для вертолетов «Ми» и «Ка», коробок самолетных агрегатов (КСА), газотурбинных двигателей-энергоузлов и турбостартеров (ГТДЭ и ВК) для самолетов «МиГ» и «Су». Продукция «Красного Октября» эксплуатируется более чем в 80 странах мира. Отделение мототехники выпускает двух- и четырехтактные двигатели, мотоблоки и мотокультиваторы «Нева», мотонасосы и другие товары народного потребления. Предприятие осуществляет полный цикл создания продукции — от проектирования и опытного производства до серийного изготовления. Оно обладает полным технологическим циклом машиностроительного производства.

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

Рис. 1. Основные потоки, образующие информационное пространство

• несколько потоков конструкторской и технологической документации (далее КД и ТД), а также нормативно-справочная документация (далее НТД):
  • поток КД и ТД от внешних проектантов и производителей техники. До недавнего времени это были документы на бумажных носителях. Начиная с 2011 года ряд авиационных КБ вместо традиционной бумаги, руководствуясь новой нормативной базой, поставляет конструкторскую информацию с использованием 3D-моделей. В поток КД и ТД от внешних проектантов и производителей техники включаются извещения об изменении. Особенностью рассматриваемого потока является его тесная связь с другим, казалось бы, далеким от технической документации административным документооборотом (более подробно на данной теме остановимся далее),
  • поток КД и ТД, разрабатываемой непосредственно на предприятии. К подобной документации относятся документы, создаваемые в АКБ, ОГТ и конструкторами литейного производства. Несмотря на различное назначение разрабатываемой КД и ТД, бизнес-процессы, связанные с ее созданием в перечисленных подразделениях, можно и нужно было стандартизировать,
  • поскольку предприятие имеет парк станков с ЧПУ, существует поток, связанный с разработкой программ для этого оборудования. На первый взгляд, поскольку программа для станка — не КД и не ТД в привычном понимании, проблема автоматизации этого потока неактуальна. На практике же речь идет о необходимости, во-первых, сбора информации о жизненном цикле изделия, в том числе на стадии производства; во-вторых, на производстве необходимо, как минимум, упорядочение процессов разработки и обращения программ для станков с ЧПУ по простой причине: исключение брака при неправильно установленной программе для станка с ЧПУ или несанкционированной ее корректировке. О прочих задачах, решаемых попутно при внедрении системы управления разработкой, учетом и оборотом программ для станков с ЧПУ, мы более подробно расскажем далее, при описании соответствующей подсистемы,
  • предприятие в своей деятельности основывается на нормативно-технической базе, содержащейся в огромном объеме НТД. При этом существует как НТД внешней разработки, так и НТД, создаваемая непосредственно на предприятии. Учет, хранение и организация быстрого доступа к НТД также являются важной задачей;
• поток административных документов — входящей и исходящей корреспонденции, приказов, распоряжений и служебных записок — неотъемлемая часть информационного пространства. Предприятие ни в коей мере не является исключением. Сейчас теме административного документооборота в технической литературе уделяется должное (а иногда и чрезмерное большое) внимание. В задачи данной статьи не входит подробное (многократно выполненное до нас!) описание. Административный документопоток упомянут как неотъемлемая часть единого информационного пространства предприятия.

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

Электронный архив КД и ТД

Оцифровка КД и ТД на бумажных носителях

Для широких форматов был приобретен сканер Contex, а несколько позже — репрокомплекс Océ. Поставку, инсталляцию, необходимую поддержку, а в дальнейшем и сервисное обслуживание оборудования осуществляет ООО «СиСофт — Бюро ЕСГ».

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

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

Организация процесса хранения

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

Выбор пал на программный комплекс TDMS — специализированный продукт разработки компании «СиСофт», позволяющий решить задачи управления технической информацией и документами.

TDMS, как и большинство продуктов такого класса, представляет собой решение, в большинстве случаев требующее некой дополнительной настройки, связанной со спецификой предприятия. В связи с этим с компанией «СиСофт — Бюро ЕСГ» был заключен договор не только на поставку программного продукта, но и на проведение необходимых работ по его настройке и внедрению.

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

• централизованный учет и хранение сканированной КД и ТД в единой БД TDMS;
• процессы занесения документации;
• процессы доступа пользователей к разделам информации с учетом прав;
• процессы учета изменений (извещения на изменения, версионность, учет измененных документов).

Управление потоками КД и ТД

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

При автоматизации управления потоками КД и ТД на предприятии особое внимание было уделено процессам разработки в следующих подразделениях:

• АКБ;
• КБ литейного производства;
• конструктора оснастки.

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

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

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

На основании описанного подхода реализовано программное взаимодействие со средствами разработки КД и ТД предприятия — КОМПАС и SolidWorks. Для решения задач интерфейсного взаимодействия системы TDMS с САПР на предприятии используется специальное приложение «Навигатор СП».

Автоматизация процессов разработки и управления обращением программ для станков с ЧПУ

Ведя речь о накоплении информации об изделии и реализации ряда PDM- и PLM-функций не на словах, а на деле, обратим внимание читателей, что помимо КД и ТД на стадиях проектирования, производства, модернизации ЖЦ изделия существует еще достаточно специфичный, но присущий высокотехнологичным отраслям пласт информации, связанный с производством. Это программы для станков с ЧПУ.

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

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

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

Всё это верно, поэтому мы готовы обсудить альтернативные решения, возможные при описанных выше исходных данных…

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

Взаимодействие административного и технического потоков документов

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

Точку зрения классика мы интерпретируем следующим образом: 1. О противоположности:

• на предприятии существуют два разнородных документопотока:
  • конструкторско-технологический,
  • административный;
• процессы обработки этих потоков — различные;
• алгоритмы автоматизированного управления потоком КД и ТД и потоком приказов/распоряжений, служебных записок, входящей и исходящей корреспонденции совершенно разные.

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

Компания «СиСофт — Бюро ЕСГ» рассматривает два основных способа решения такой задачи:

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

На предприятии был выбран второй путь — в среде программного комплекса TDMS была разработана подсистема административного документооборота, которая не только автоматизирует процессы учета, регистрации, управления потоками приказов, распоряжений, входящей и исходящей корреспонденции и служебных записок. В рамках единой среды строятся связи между административным и техническим потоками с возможностью перехода по ним. Таким образом, в среде программного комплекса TDMS создана единая среда управления документами, показанная на рис. 2.

Рис. 2. Единая среда управления документами

База НТД

Таким образом, с помощью программного комплекса TDMS решена задача обеспечения информацией и документами различных категорий пользователей предприятия. Общая схема единой среды управления документами предприятия, включающая в том числе элементы PDM и PLM, приведена на рис. 3.

Рис. 3. Общая схема единой среды управления документами предприятия

Разработка и внедрение

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

2. Непосредственно реализация системы. Результат: получена система, соответствующая описаниям, приведенным в результатах предыдущего этапа (постановка задачи).

3. Разработка документации (для пользователей и администраторов).

4. Разработка контрольных примеров.

5. Разработка программ и методик обучения.

6. Проведение обучения на контрольных примерах.

7. Сдача в опытную эксплуатацию.

8. Проведение (сопровождение) опытной эксплуатации.

9. Необходимые доработки в рамках ТЗ по результатам опытной эксплуатации.

10. Разработка необходимых нормативных документов (СТП).

11. Приемка в промышленную эксплуатацию.

12. Сопровождение системы.

13. Необходимые модернизации.

Прохождение всех пунктов приведенной последовательности — сложная совместная работа как представителей предприятия, так и компании — поставщика решения. Но есть и исключения. Остановимся на них. Бытует мнение о том, что сдача-приемка в промышленную эксплуатацию — совместная работа компании — поставщика решения и предприятия. Заметим по этому поводу следующее:

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

• технические;
• организационные.

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

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

Об авторах: