СПб ОАО «Красный Октябрь» специализируется на производстве, ремонте и обслуживании силовых агрегатов для вертолетов «Ми» и «Ка», коробок самолетных агрегатов (КСА), газотурбинных двигателей-энергоузлов и турбостартеров (ГТДЭ и ВК) для самолетов «МиГ» и «Су». Продукция «Красного Октября» эксплуатируется более чем в 80 странах мира. Отделение мототехники выпускает двух- и четырехтактные двигатели, мотоблоки и мотокультиваторы «Нева», мотонасосы и другие товары народного потребления. Предприятие осуществляет полный цикл создания продукции — от проектирования и опытного производства до серийного изготовления. Оно обладает полным технологическим циклом машиностроительного производства.
Информационное пространство СПб ОАО имеет ряд особенностей, обусловленных прежде всего его производственной деятельностью. Состав информационного пространства (наиболее важные образующие информационные потоки) показан на рис. 1.
К основным особенностям, характеризующим информационное пространство предприятия, можно отнести следующие:
• несколько потоков конструкторской и технологической документации (далее КД и ТД), а также нормативно-справочная документация (далее НТД):
• поток административных документов — входящей и исходящей корреспонденции, приказов, распоряжений и служебных записок — неотъемлемая часть информационного пространства. Предприятие ни в коей мере не является исключением. Сейчас теме административного документооборота в технической литературе уделяется должное (а иногда и чрезмерное большое) внимание. В задачи данной статьи не входит подробное (многократно выполненное до нас!) описание. Административный документопоток упомянут как неотъемлемая часть единого информационного пространства предприятия.
Несомненно, говоря о полном едином информационном пространстве (далее ЕИП), стоит упомянуть и о финансово-экономических, складских, закупочных и прочих аспектах деятельности. Но поскольку невозможно объять необъятное, тем более в рамках одной статьи, то ограничимся лишь следующими утверждениями:
Первым шагом в реализации централизованного хранения КД и ТД на предприятии явилось создание электронного архива документации, хранящейся на бумажных носителях.
Для перевода информации в электронный вид предприятием были закуплены сканеры. Причем для сканирования (в том числе поточного) форматов до А3 включительно используются сканеры Fujitsu, обеспечивающие неплохой результат даже при сканировании «синек» и калек.
Для широких форматов был приобретен сканер Contex, а несколько позже — репрокомплекс Océ. Поставку, инсталляцию, необходимую поддержку, а в дальнейшем и сервисное обслуживание оборудования осуществляет ООО «СиСофт — Бюро ЕСГ».
Несомненно, современное сканирующее оборудование имеет все необходимые специализированные модули коррекции, повышающие качество изображений. К сожалению, такой встроенной по умолчанию функциональности, способствующей получению удовлетворительного качества изображений, далеко не всегда достаточно. Прежде всего это связано с качеством бумажных носителей. Кальки, особенно старые и мятые, часто «бликуют» на сгибах, давая засветку, что ведет к «потере» части изображения. Электронные образы, полученные при сканировании старых «синек», в большинстве случаев также требуют дополнительной обработки.
В связи с этим было закуплено и внедрено специализированное программное обеспечение производства компании «СиСофт» — RasterID. Это ПО предназначено для повышения качества изображений. В отличие от более широко позиционируемых пакетов обработки электронных образов, RasterID является специализированным ПО, ориентированным на повышение качества изображений, прежде всего полученных при сканировании КД и ТД. Например, используются возможности устранения засветок от калек, фильтрация (в том числе и по цвету) типичной «грязи», которую все видели на «синьках». Существует множество опций по повышению качества, которые можно как вызывать для одного изображения, так и записывать. Файл, содержащий запись последовательных команд по обработке, используется для выполнения набора типизированных операций в пакетном режиме. Одной из специализированных функций ПО RasterID является распознавание полей угловых штампов с последующей записью результатов в табличные форматы, позволяющие формировать БД.
Переведенные в электронный вид документы в виде файлов требовали некого упорядоченного хранения. На первый взгляд, организовать хранение файлов и их упорядочение просто с применением вложенных в них каталогов. Большинство организаций при создании системы электронного архива не минует эта «эволюционная» стадия.
При такой организации хранения рано или поздно (по мере накопления информации) наступает день, когда возможности операционных и файловых систем по упорядочению иссякают, а поиск конкретного отсканированного чертежа требует неприемлемого времени. В такой ситуации, как правило, представители ИТ-подразделений рассматривают вопрос об использовании современных СУБД, позволяющих заметно облегчить сложившуюся ситуацию. В настоящее время взоры обращаются к СУБД, которые обычно используются в работе других систем предприятия, например бухгалтерских, складских, ERP-системах и т.д. Как правило, наиболее распространены СУБД Microsoft SQL Server и Oracle. На СПб ОАО «Красный Октябрь» — MS SQL Server.
Разработка системы электронного архива является не только интересной и полезной, но и достаточно трудоемкой задачей. По уже описанным нами причинам были рассмотрены несколько программных продуктов — надстроек над СУБД, которые позволили бы решить стоящие перед предприятием задачи.
Выбор пал на программный комплекс TDMS — специализированный продукт разработки компании «СиСофт», позволяющий решить задачи управления технической информацией и документами.
TDMS, как и большинство продуктов такого класса, представляет собой решение, в большинстве случаев требующее некой дополнительной настройки, связанной со спецификой предприятия.
В связи с этим с компанией «СиСофт — Бюро ЕСГ» был заключен договор не только на поставку программного продукта, но и на проведение необходимых работ по его настройке и внедрению.
На этапе создания электронного архива были реализованы:
К великому сожалению, базовый программный продукт TDMS по умолчанию не имеет системы веб-доступа. В связи с этим была поставлена задача организации быстрого доступа к КД и ТД, в том числе из цехов. При этом требования к функционалу рабочих мест, с которых должен осуществляться такой доступ, сводились лишь к возможности быстрого поиска и вывода на экран необходимого чертежа. Результатом выполнения такой задачи стала система веб-доступа к БД TDMS, разработанная компанией «СиСофт — Бюро ЕСГ». При этом на рабочем месте не требуется инсталляция ПО. Работа производится в окне стандартного Internet Explorer.
Следующей ступенью развития системы была автоматизация управления потоками КД и ТД, в основном в процессе ее разработки. Часто употребляется термин «конструкторский документооборот», что в целом не противоречит понятию «управление потоками КД и ТД», поэтому будем применять оба термина.
Переход на новый уровень подразумевал не только реализацию конструкторского документооборота, но и сохранение результатов работ на предыдущей ступени. Иными словами, система электронного архива является базисом, фундаментом, а система конструкторского документооборота — надстройкой. Все автоматизируемые процессы управления потоками КД и ТД на рассматриваемой ступени автоматизации (конструкторский документооборот) находят свое продолжение в системе электронного архива. Такое продолжение не является лишь логическим (КД и ТД сначала разрабатываются, потом передаются в архив). Поскольку система создана в единой среде программного комплекса TDMS, поступление в электронный архив результатов разработки КД и ТД осуществляется в единой БД.
При автоматизации управления потоками КД и ТД на предприятии особое внимание было уделено процессам разработки в следующих подразделениях:
На первый взгляд перечисленные подразделения решают совершенно разные задачи и каждое из них требует особого подхода. Тем не менее представителям предприятия совместно с «СиСофт — Бюро ЕСГ» удалось описать существующие бизнес-процессы по разработке КД и предложить оптимизированную схему работы, отражающую потребности для решения задач всех подразделений. Забегая вперед, отметим, что для успешного решения задач автоматизации (и не только на этом этапе) важным фактором успеха явилась разработка необходимой нормативной базы предприятия — стандартов (СТП), положений, инструкций.
При разработке системы управления потоками КД и ТД требуется организация интерфейсного взаимодействия между средствами разработки — САПР и системой конструкторского документооборота. При этом возникают различные задачи, позволяющие исключить дублирующие друг друга действия в САПР и системе управления потоками КД и ТД. К таким действиям, например, можно отнести заполнение информации в угловом штампе чертежа с использованием двумерных САПР и заполнение полей учетной карточки того же чертежа в системе конструкторского документооборота (поля и их значения одинаковы).
В качестве другого примера приведем создание структуры изделия в 3D-САПР и создание структуры изделия в системе конструкторского документооборота. Можно вспомнить еще множество примеров. Вместо этого сформулируем основной подход, реализованный при организации программного взаимодействия: информация вводится однократно, после чего в необходимом объеме передается в другие системы. Причем не следует забывать великий принцип «кесарю кесарево, а Богу Богово».
Иными словами, если конструкторы при работе заполняют угловой штамп в 2D-САПР и строят структуру изделия в 3D-САПР, то пусть всё так и остается. При этом информация из САПР передается в систему TDMS (в нашем случае). Если же процессы обмена конструкторской и технологической информацией, управление ее потоками умеет хорошо осуществлять система конструкторского документооборота, реализованная в среде TDMS, то пусть она это и делает с полученной от САПР информацией (файлами, атрибутивными параметрами, структурами, электронными документами и т.д.).
На основании описанного подхода реализовано программное взаимодействие со средствами разработки КД и ТД предприятия — КОМПАС и SOLIDWORKS. Для решения задач интерфейсного взаимодействия системы TDMS с САПР на предприятии используется специальное приложение «Навигатор СП».
Доселе мы умышленно не употребляли термины «PDM» и «PLM». Это связано отнюдь не с непониманием и непродвинутостью авторов в этих понятиях. Скорее наоборот. Дело в том, что, к сожалению, очень часто мы сталкиваемся с подменой понятий некоторыми поставщиками и производителями решений, когда, например, делаются громкие заявления о внедрении PLM-системы. При детальном изучении такой системы оказывается, что решены лишь задачи на стадии жизненного цикла проектирования, частично производства. При этом, как правило, такая PLM-система функционально ограничена одной САПР, являясь ее «довеском» от производителя. Компания-поставщик быстро напишет любой интерфейс. Часто такая PDM/PLM по своей идеологии далека от принятых у нас принципов разработки КД и ТД. При этом, кроме «конструкторско-технологических», нередко забывают о весьма существенных аспектах управления информацией в процессе жизненного цикла изделия. К таким аспектам относятся, например, логистическая поддержка, эксплуатационная информация и документация, расписания и описания регламентов, электронные руководства и т.д. Описанные причины заставляют нас быть более осмотрительными в своих заявлениях, и вместо употребления терминов «PDM» и «PLM» мы будем говорить лишь о некоторых функциях или элементах PDM и PLM.
Ведя речь о накоплении информации об изделии и реализации ряда PDM- и PLM-функций не на словах, а на деле, обратим внимание читателей, что помимо КД и ТД на стадиях проектирования, производства, модернизации ЖЦ изделия существует еще достаточно специфичный, но присущий высокотехнологичным отраслям пласт информации, связанный с производством. Это программы для станков с ЧПУ.
Кроме организации учета и хранения программ для станков с ЧПУ и автоматизации их «движения» (прохождения контрольных точек в процессе разработки), в системе особое внимание уделено учету обращения программ, внесению изменений, исключению брака. Подробно останавливаться на описании процесса учета изменений, учета версий программ для станков с ЧПУ под управлением системы мы не будем, поскольку бизнес-процессы во многом схожи с процессами учета, хранения, разработки, проведения изменений в КД и ТД. Подробнее рассмотрим следующую ситуацию: программа для станка с ЧПУ в любом случае перед использованием отчуждается от системы. После такого отрыва (записи на внешний носитель) программа загружается в станок. При этом в период между отчуждением и запуском станка по программе возможны следующие варианты:
Подобные ситуации ведут к браку, финансовым потерям (порча дорогостоящих заготовок) и прочим негативным последствиям.
С одной стороны, требовать от системы полного контроля над программами для станков с ЧПУ после отчуждения последних — невыполнимая задача. С другой — механизм анализа и контроля безусловно необходим. Несмотря на противоречивость задачи, решение было найдено:
Конечно, кто-то может заявить, что степень автоматизации невысока, необходима «красная кнопка», то есть некая функция, исключающая неправильное использование программы на станке.
Всё это верно, поэтому мы готовы обсудить альтернативные решения, возможные при описанных выше исходных данных…
Несколько забегая вперед, скажем, что всё автоматизировать просто не получится. Процесс ав-томатизации должен идти параллельно с серьезной работой по внедрению решения, разработке стандартов и механизмов контроля их выполнения. Причем контроль выполнения может осуществляться в том числе и с использованием средств автоматизации. Теме внедрения и стандартизации посвящен отдельный раздел нашей статьи.
Говоря о документопотоках предприятия, нельзя забывать об административном документообороте. На рынке программного обеспечения и услуг, связанных с управлением документопотоками в России, наблюдается следующая тенденция:
Поддерживать первую точку зрения и приравнивать проектно-конструкторский документопоток к административному, на наш взгляд, неправильно. Однако поддерживать позицию второй группы компаний («от САПР») тоже неверно. Но борьба между приверженцами этих двух точек зрения не столь бескомпромиссна. Несмотря на переходы от одной социальной формации к другой, всё же согласимся с автором третьей точки зрения, сформулировавшим первый закон диалектики (читателям, не постигавшим азы философии, не требуется изучать его позицию о единстве и борьбе противоположностей, достаточно прочитать нижеприведенные описания).
Точку зрения классика мы интерпретируем следующим образом:
1. О противоположности:
• на предприятии существуют два разнородных документопотока:
• процессы обработки этих потоков — различные;
• алгоритмы автоматизированного управления потоком КД и ТД и потоком приказов/распоряжений, служебных записок, входящей и исходящей корреспонденции совершенно разные.
2. О единстве:
• оба потока в той или иной мере взаимосвязаны. Некоторые примеры:
• для полной информационной картины не только полезно, но и необходимо:
• для предприятия административный и технический потоки являются разными гранями единого информационного пространства, и говорить о том, что один из потоков приоритетнее, как минимум, бессмысленно.
В связи с изложенным подходом на предприятии была поставлена задача создания системы административного документооборота. При этом предполагалась возможность установки связей между документами различных потоков с возможностью перехода от документа к документу по этим связям.
Компания «СиСофт — Бюро ЕСГ» рассматривает два основных способа решения такой задачи:
Как показывает опыт, оба пути имеют право на существование. Та или иная реализация зависит от конкретных условий и детализации задач.
На предприятии был выбран второй путь — в среде программного комплекса TDMS была разработана подсистема административного документооборота, которая не только автоматизирует процессы учета, регистрации, управления потоками приказов, распоряжений, входящей и исходящей корреспонденции и служебных записок. В рамках единой среды строятся связи между административным и техническим потоками с возможностью перехода по ним. Таким образом, в среде программного комплекса TDMS создана единая среда управления документами, показанная на рис. 2.
На предприятии применяется огромная база нормативно-технической документации и стандартов. Причем многие документы для предприятия являются внешними, а часть разрабатывается на месте. При создании единого информационного пространства должное внимание было уделено созданию БД НТД в среде ПО TDMS. С точки зрения автоматизации бизнес-процессов данная подсистема проще описанных выше. Основной задачей является систематизированное хранение НТД в единой БД с возможностью просмотра документации пользователями в соответствии с их правами и функциональными обязанностями.
Таким образом, с помощью программного комплекса TDMS решена задача обеспечения информацией и документами различных категорий пользователей предприятия. Общая схема единой среды управления документами предприятия, включающая в том числе элементы PDM и PLM, приведена на рис. 3.
Рассказывать о полученных результатах, не скроем, весьма приятно. Остановимся более подробно на вопросах, связанных с тем, как достичь желаемого. Говоря о сложных программных решениях, таких, например, как система управления КД и ТД, система административного документооборота, электронный архив, стоит обратить внимание на подходы к разработке и внедрению. Данные процедуры реализуются в такой последовательности:
1. Постановка задачи. Результаты: согласованные описания автоматизируемых бизнес-процессов с учетом необходимой их модернизации, техническое задание, функциональная спецификация на систему.
2. Непосредственно реализация системы. Результат: получена система, соответствующая описаниям, приведенным в результатах предыдущего этапа (постановка задачи).
3. Разработка документации (для пользователей и администраторов).
4. Разработка контрольных примеров.
5. Разработка программ и методик обучения.
6. Проведение обучения на контрольных примерах.
7. Сдача в опытную эксплуатацию.
8. Проведение (сопровождение) опытной эксплуатации.
9. Необходимые доработки в рамках ТЗ по результатам опытной эксплуатации.
10. Разработка необходимых нормативных документов (СТП).
11. Приемка в промышленную эксплуатацию.
12. Сопровождение системы.
13. Необходимые модернизации.
Прохождение всех пунктов приведенной последовательности — сложная совместная работа как представителей предприятия, так и компании — поставщика решения. Но есть и исключения. Остановимся на них.
Бытует мнение о том, что сдача-приемка в промышленную эксплуатацию — совместная работа компании — поставщика решения и предприятия. Заметим по этому поводу следующее:
• при прохождении всех пунктов приведенной нами последовательности до пункта «Необходимые доработки в рамках ТЗ по результатам опытной эксплуатации» включительно на предприятии имеется:
• при наличии всего перечисленного для регламентации деятельности с использованием системы на предприятии необходимаразработка СТП. Часто на предприятии считают, что разработка СТП должна проводиться силами компании — поставщика решения. Мы против подобного подхода, поскольку компания — поставщик решения выполнит эту работу заведомо хуже представителей предприятия. Участие компании-поставщика может ограничиваться лишь консультациями;
• приемка в промышленную эксплуатацию при наличии СТП, системы, обученного персонала и эксплуатационной документации — всего лишь административная процедура, к выполнению которой бессмысленно привлекать компанию — поставщика решения. Процедура выражается в издании приказа по предприятию с указанием срока обязательного начала работы в системе (может быть поэтапного — по подразделениям, проектам, изделиям и т.д.), механизмов ответственности и контроля выполнения. Самый простой пример такого механизма: в бумажный архив чертеж не принимается, если он отсутствует в электронном архиве.
В процессе прохождения приведенной последовательности создания системы возникают различные подводные камни, которые можно разделить на две основные группы:
Причиной возникновения первых, как правило, могут являться вторые, и наоборот. Например, формально утвержденное ТЗ влечет за собой массу технических проблем, а попытка технически сразу объять необъятное может привести к необходимости мгновенной серьезной реорганизации на предприятии, на которую в короткое время невозможно выделить необходимые ресурсы…
При этом технические проблемы, как правило, тем или иным образом решаемы, причем весьма успешно. Самыми трудоемкими являются организационные проблемы.
Например, не скроем, что успешное внедрение во многом зависит от человеческого фактора. Как правило, решение организационных проблем в принципе невозможно без привлечения руководителя того или иного уровня, а иногда и генерального директора предприятия. В связи с этим одним из основных факторов успешного внедрения является административная воля руководства.
Эл. версия "САПР и Графика" Август, 2012 г.
Теги: | Машиностроение, Электронный архив, TDMS, RasterID, |