CADmaster

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

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

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

Рис. 1. Основные потоки, образующие информационное пространство СПб ОАО Красный Октябрь

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

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

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

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

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

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

Для перевода информации в электронный вид предприятие приобрело сканеры: для сканирования (в том числе поточного) форматов до АЗ включительно — сканеры Fujitsu, дающие неплохой результат и при сканировании синек и калек, для широких форматов — сканер Contex, а несколько позже репрокомплекс Oce. Поставку, инсталляцию, необходимую поддержку, а в дальнейшем и сервисное обслуживание оборудования осуществляет компания Бюро ESG.

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

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

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

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

Большинство предприятий при создании системы электронного архива не минуют такой «эволюционной» стадии.

Однако при подобной организации хранения по мере накопления информации рано или поздно наступает день, когда возможности операционных и файловых систем «по упорядочиванию» иссякают, а поиск конкретного отсканированного чертежа занимает неприемлемое время. В такой ситуации представители IT-подразделений обычно рассматривают вопрос об использовании современных СУБД, позволяющих разрешить сложившуюся ситуацию. В настоящее время, как правило, взоры обращаются к СУБД, которые применяются в работе других систем предприятия, например, бухгалтерских, складских, ERP-системах и т.д. Чаще всего это такие распространенные продукты, как Microsoft SQL Server и Oracle. В СПб ОАО «Красный Октябрь» в качестве такой СУБД была выбрана MS SQL Server.

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

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

Как и большинство продуктов своего класса, TDMS представляет собой решение, требующее некоей дополнительной настройки, связанной со спецификой предприятия. Поэтому СПб ОАО «Красный Октябрь» заключило c компанией Бюро ESG договор не только на поставку программного продукта, но и на проведение необходимых работ по его настройке и внедрению.

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

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

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

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

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

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

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

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

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

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

При разработке системы управления потоками КД и ТД возникает необходимость организации интерфейсного взаимодействия между средствами разработки — САПР и непосредственно системой конструкторского документооборота. При этом следует решить ряд задач, позволяющих исключить дублирующие действия в САПР и системе управления потоками КД и ТД. Например, к таким действиям можно отнести заполнение информации в угловом штампе чертежа с использованием двумерных САПР, а также заполнение полей учетной карточки того же чертежа в системе конструкторского документооборота (поля и их значения одинаковы). Или же создание структуры изделия в 3D-САПР и в системе конструкторского документооборота… Примеров можно приводить множество. Вместо этого сформулируем основной подход, реализованный при организации программного взаимодействия: однократно введенная информация в необходимом объеме передается в другие системы. При этом учитывается великий принцип о «Боге и кесаре». Иными словами, если конструкторы при работе заполняют угловой штамп в 2D-САПР и строят структуру изделия в 3D-САПР, то пусть все так и остается. Информация из САПР передается в систему TDMS (в нашем случае). Если же обмениваться конструкторской и технологической информацией, управлять ее потоками хорошо умеет система конструкторского документооборота, реализованная в среде TDMS, то пусть она это и делает, получив от САПР соответствующие данные (файлы, атрибутивные параметры, структуры, электронные документы и т.д.).

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

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

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

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

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

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

• несанкционированные и неучтенные изменения с использованием ПК;
• несанкционированные и неучтенные изменения параметров обработки изделия в программе на станке.

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

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

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

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

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

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

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

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

Точку зрения классика в нашем преломлении интерпретируем следующим образом.

О противоположности:

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

О единстве:

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

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

Компания Бюро ESG рассматривает дить от документа к документу. Компания Бюро ESG рассматривает два основных способа решения такой задачи:

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

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

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

Рис. 1. Основные потоки, образующие информационное пространство СПб ОАО Красный Октябрь

База НТД

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

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

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

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

Не скроем, говорить о достигнутых результатах, описанных в предыдущих разделах, весьма приятно. Остановимся подробнее на вопросах, связанных со способами достижения желаемого. Говоря о таких сложных программных решениях, как, например, система управления КД и ТД, система административного документооборота или электронный архив, стоит обратить внимание на подходы к их разработке и внедрению. Наверное, мы не изобретем велосипед, приводя следующую последовательность:

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

Прохождение всех пунктов приведенной последовательности — сложная совместная работа представителей как предприятия, так и компании-поставщика решения. Однако и здесь есть исключения. Рассмотрим их.

Бытует мнение, что процесс сдачи/приемки в промышленную эксплуатацию — совместная работа компании-поставщика решения и предприятия. Заметим по этому поводу следующее:

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

В процессе прохождения приведенной последовательности создания системы возникают различные «подводные камни», которые можно разделить на две основные группы:

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

При этом, как правило, причиной возникновения первых могут являться вторые — и наоборот. Например, «формально» утвержденное ТЗ влечет массу технических проблем, а попытка технически сразу «объять необъятное» может привести к необходимости мгновенной серьезной реорганизации на предприятии, на которую в короткое время невозможно выделить необходимые ресурсы…

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

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