СПб ОАО «Красный Октябрь» специализируется на производстве, ремонте и обслуживании силовых агрегатов для вертолетов «Ми» и «Ка», коробок самолетных агрегатов (КСА), газотурбинных двигателей-энергоузлов и турбостартеров (ГТДЭ и ВК) для самолетов «МиГ» и «Су». Продукция предприятия эксплуатируется более чем в 80 странах мира. Отделение мототехники выпускает двух- и четырехтактные двигатели, мотоблоки и мотокультиваторы «Нева», мотонасосы и другие товары народного потребления. Предприятие осуществляет полный цикл создания продукции — от проектирования и опытного производства до серийного изготовления.
Информационное пространство СПб ОАО «Красный Октябрь» имеет ряд особенностей, обусловленных, прежде всего, спецификой производственной деятельности. Наиболее важные информационные потоки, образующие состав этого пространства, приведены на рис. 1. Назовем основные особенности, характеризующие информационное пространство предприятия.
Несомненно, говоря о полном едином информационном пространстве (далее «ЕИП»), стоит упомянуть и о финансово-экономических, складских, закупочных и прочих аспектах деятельности. Но, поскольку нельзя объять необъятное, тем более в рамках одной статьи, ограничимся лишь следующими положениями:
Первым шагом в реализации централизованного хранения КД и ТД на предприятии стало создание электронного архива документации, хранящейся на бумажных носителях.
Для перевода информации в электронный вид предприятие приобрело сканеры: для сканирования (в том числе поточного) форматов до АЗ включительно — сканеры Fujitsu, дающие неплохой результат и при сканировании синек и калек, для широких форматов — сканер Contex, а несколько позже репрокомплекс Oce. Поставку, инсталляцию, необходимую поддержку, а в дальнейшем и сервисное обслуживание оборудования осуществляет компания Бюро ESG.
Несомненно, современное сканирующее оборудование имеет полный набор необходимых специализированных модулей коррекции, повышающих качество изображений. Однако, к сожалению, такой встроенной по умолчанию функциональности далеко не всегда бывает достаточно. Это связано, прежде всего, с качеством бумажных носителей. Кальки, особенно старые и мятые, часто бли-куют на сгибах, давая засветку, ведущую к потере части изображения. Электронные образы, полученные при сканировании старых синек, также в большинстве случаев требуют дополнительной обработки.
В связи с этим было закуплено и внедрено программное обеспечение RasterlD производства компании CSoft Development. В отличие от других пакетов обработки электронных образов, RasterlD является специализированным ПО, ориентированным на повышение качества изображений, полученных, прежде всего, при сканировании КД и ТД. Например, оно позволяет устранять засветки от калек, фильтровать (в том числе и по цвету) ставшую привычной на синьках «грязь». Множество опций можно использовать не только для одного изображения, но и для выполнения набора типизированных операций в пакетном режиме, создав соответствующий файл с записью последовательных команд обработки. Одной из «специализированных» функций ПО RasterlD является распознавание полей угловых штампов с последующим переносом результатов в табличные форматы, позволяющие формировать БД.
Переведенные в электронный вид документы в виде файлов требовали некоего упорядоченного хранения. На первый взгляд, эта задача достаточно простая: следует лишь использовать систему каталогов и вложенных в них каталогов.
Большинство предприятий при создании системы электронного архива не минуют такой «эволюционной» стадии.
Однако при подобной организации хранения по мере накопления информации рано или поздно наступает день, когда возможности операционных и файловых систем «по упорядочиванию» иссякают, а поиск конкретного отсканированного чертежа занимает неприемлемое время. В такой ситуации представители IT-подразделений обычно рассматривают вопрос об использовании современных СУБД, позволяющих разрешить сложившуюся ситуацию. В настоящее время, как правило, взоры обращаются к СУБД, которые применяются в работе других систем предприятия, например, бухгалтерских, складских, ERP-системах
Разработка системы электронного архива является не только интересной и полезной, но и достаточно трудоемкой задачей. В частности, по описанным выше причинам необходимо было выбрать программные продукты — надстройки над СУБД, которые позволили бы решить стоящие перед предприятием задачи.
После тщательного анализа представленного на рынке ПО выбор был остановлен на программном комплексе TDMS — специализированном продукте разработки компании CSoft Development, позволяющим решить задачи управления технической информацией и документами.
Как и большинство продуктов своего класса, TDMS представляет собой решение, требующее некоей дополнительной настройки, связанной со спецификой предприятия. Поэтому СПб ОАО «Красный Октябрь» заключило c компанией Бюро ESG договор не только на поставку программного продукта, но и на проведение необходимых работ по его настройке и внедрению.
На этапе создания электронного архива были реализованы следующие функции:
К великому сожалению, базовый программный продукт TDMS не имеет системы web-доступа к КД и ТД по умолчанию. Данный недостаток следовало устранить. При этом требования к функционалу рабочих мест (в том числе и из цехов), с которых должен был осуществляться такой доступ, сводились лишь к возможности быстрого поиска и вывода на экран необходимого чертежа. В результате компания Бюро ESG разработала систему web-доступа к БД TDMS, которая не требует инсталляции специального ПО: работа производится в стандартном окне Internet Explorer.
Следующей ступенью развития системы стала автоматизация управления потоками КД и ТД, в основном в процессе их разработки. Поскольку на практике часто употребляется термин «конструкторский документооборот», что в целом не противоречит понятию «управление потоками КД и ТД», мы будем применять оба эти термина.
Переход на новый уровень подразумевал не только реализацию конструкторского документооборота, но и сохранение результатов работ, произведенных на предыдущей ступени. Другими словами, система электронного архива является базисом, фундаментом, а система конструкторского документооборота — надстройкой. Все автоматизируемые процессы уп рав ле ния по то ка ми КД и ТД на рас -сматриваемой ступени автоматизации (конструкторский документооборот) находят свое продолжение в системе электронного архива. Такое продолжение не является лишь логическим, когда КД и ТД сначала разрабатываются, а затем передаются в архив. Поскольку система создана в единой среде программного комплекса TDMS, поступление в электронный архив результатов разработки КД и ТД осуществляется в единой БД.
При автоматизации управления потоками КД и ТД на предприятии должное внимание было уделено следующим подразделениям:
На первый взгляд, перечисленные подразделения решают совершенно разные задачи и требуют своего особого подхода. С другой стороны, представителям предприятия и компании Бюро ESG удалось совместно описать существующие бизнес-процессы по разработке КД и предложить оптимизированную схему работы для решения задач всех подразделений.
Забегая вперед, отметим, что важным фактором успеха при этом стало формирование необходимой нормативной базы предприятия — стандартов (СТП), положений, инструкций.
При разработке системы управления потоками КД и ТД возникает необходимость организации интерфейсного взаимодействия между средствами разработки — САПР и непосредственно системой конструкторского документооборота. При этом следует решить ряд задач, позволяющих исключить дублирующие действия в САПР и системе управления потоками КД и ТД. Например, к таким действиям можно отнести заполнение информации в угловом штампе чертежа с использованием двумерных САПР, а также заполнение полей учетной карточки того же чертежа в системе конструкторского документооборота (поля и их значения одинаковы). Или же создание структуры изделия в 3D-САПР и в системе конструкторского документооборота… Примеров можно приводить множество. Вместо этого сформулируем основной подход, реализованный при организации программного взаимодействия: однократно введенная информация в необходимом объеме передается в другие системы. При этом учитывается великий принцип о «Боге и кесаре». Иными словами, если конструкторы при работе заполняют угловой штамп в 2D-САПР и строят структуру изделия в 3D-САПР, то пусть все так и остается. Информация из САПР передается в систему TDMS (в нашем случае). Если же обмениваться конструкторской и технологической информацией, управлять ее потоками хорошо умеет система конструкторского документооборота, реализованная в среде TDMS, то пусть она это и делает, получив от САПР соответствующие данные (файлы, атрибутивные параметры, структуры, электронные документы
На основании описанного выше подхода была реализована интеграция со средствами разработки КД и ТД предприятия — КОМПАС и SOLIDWORKS. Для решения задач интерфейсного взаимодействия системы TDMS с САПР на предприятии используется специальное приложение «Навигатор СП».
До этого места нашего изложения мы умышленно не употребляли терминов «PDM» и «PLM». Это связано отнюдь не с непониманием этих понятий или «непродвинутостью» авторов. Скорее наоборот. Дело в том, что, к сожалению, очень часто мы сталкиваемся с подменой понятий некоторыми поставщиками и производителями решений, делающими громкие заявления, например, о внедрении PLM-системы. При детальном же изучении такой системы оказывается, что решены лишь задачи, касающиеся стадии жизненного цикла проектирования, частично — производства. При этом, как правило, подобная PLM-система функционально ограничена одной САПР, являясь ее «довеском» от производителя. Компания-поставщик «быстро напишет любой интерфейс». Часто такая PDM/PLM далека по своей идеологии от принятых у нас принципов разработки КД и ТД. При этом, кроме конструкторско-технологических, часто просто «забываются» достаточно существенные аспекты управления информацией в процессе ЖЦ изделия, такие, например, как логистическая поддержка, эксплуатационная информация и документация, расписания и описания регламентов, электронные руководства
Рассуждая о накоплении информации об изделии и реализации ряда PDM- и PLM-функций, обратим внимание читателя, что кроме КД и ТД на стадиях проектирования, производства и модернизации ЖЦ изделия существует еще достаточно специфичный, но присущий высокотехнологичным отраслям пласт информации, связанный с производством. Это — программы для станков с ЧПУ.
Кроме организации учета, хранения, а также автоматизации «движения» (прохождения контрольных точек в процессе разработки) таких программ, в системе важное внимание уделено контролю над обращением программ, внесением изменений, исключением брака. Не будем подробно останавливаться на описании процесса учета изменений, а также версий программ для станков с ЧПУ под управлением системы. Эти бизнес-процессы во многом схожи с процессами учета, хранения, разработки, проведения изменений в КД и ТД.
Рассмотрим подробнее следующую ситуацию: в любом случае программа для станка с ЧПУ перед использованием отчуждается от системы, записывается на внешний носитель и загружается в станок. При этом в период между отчуждением и запуском станка по программе возможны следующие варианты:
Подобные ситуации ведут к браку, финансовым потерям (порча дорогостоящих заготовок) и прочим отрицательным последствиям. С одной стороны, требовать от системы полного контроля над программами для станков с ЧПУ после отчуждения — невыполнимая задача. С другой — необходимость механизма анализа и контроля не вызывала сомнения. Задача противоречива, но решение было найдено:
Конечно, кто-то может сказать, что степень автоматизации невысока, необходима «красная кнопка», то есть некая функция, исключающая неправильное использование программы на станке. Здесь мы не будем спорить и готовы обсудить иные решения, возможные при описанных выше исходных данных…
Несколько забегая вперед, отметим, что «автоматизировать все» просто невозможно. Поэтому процесс автоматизации должна сопровождать серьезная работа по внедрению решения, разработке стандартов и механизмов контроля их выполнения. Причем контроль выполнения может осуществляться в том числе и с использованием средств автоматизации. Теме внедрения и стандартизации посвящен отдельный раздел статьи.
Говоря о документопотоках предприятия, несомненно, не упомянуть административный документооборот было бы неправильно. На рынке отечественного программного обеспечения и услуг, связанных с управлением документопотоками, наблюдается следующая тенденция:
Несомненно, поддерживать первую точку зрения и отождествлять проектно-конструкторский и административный документопотоки, на наш взгляд, неправильно. С другой стороны, и придерживаться второго мнения (компаний «от САПР») — также неверно. Однако борьба между приверженцами этих двух взглядов не столь бескомпромиссна. Несмотря на переходы от одной социальной формации к другой, все же позволю согласиться с автором третьей точки зрения, сформулировавшим первый закон диалектики (читателям, не постигавшим сии азы при освоении общественных наук, не стоит начинать изучать теорию о единстве и борьбе противоположностей, достаточно прочитать нижеприведенные описания).
Точку зрения классика в нашем преломлении интерпретируем следующим образом.
О противоположности:
О единстве:
Данный подход был положен в основу создания системы административного документооборота на предприятии. При этом предполагалась возможность установки связей между документами различных потоков, позволяющих переходить от документа к документу.
Компания Бюро ESG рассматривает дить от документа к документу. Компания Бюро ESG рассматривает два основных способа решения такой задачи:
Как показывает опыт, оба эти пути имеют право на существование. Та или иная реализация зависит от конкретных условий, детализации задач.
На предприятии был выбран второй путь: в среде программного комплекса TDMS была разработана подсистема административного документооборота, которая не только автоматизирует процессы учета, регистрации, управления потоками приказов, распоряжений, входя-щей/исходящей корреспонденции и служебных записок. В рамках единой среды строятся связи между административным и техническим потоками с возможностью перехода по этим связям. Таким образом, на базе программного комплекса TDMS была создана единая среда управления документами (рис. 2).
В СПб ОАО «Красный Октябрь» используется огромная база нормативно-технической документации, стандартов, часть из которых разрабатывается непосредственно на предприятии, а часть — вне его. При формировании единого информационного пространства должное внимание было уделено созданию в среде TDMS БД НТД для обеспечения систематизированного хранения документации с возможностью ее просмотра пользователями в соответствии с их правами и функциональными обязанностями.
Та ким об ра зом, с по мо щью про грамм, но -го комплекса TDMS различные категории пользователей предприятия были обеспечены необходимой информацией и документами (рис. 3). При этом были использованы, в том числе, элементы PDM и PLM.
Не скроем, говорить о достигнутых результатах, описанных в предыдущих разделах, весьма приятно. Остановимся подробнее на вопросах, связанных со способами достижения желаемого. Говоря о таких сложных программных решениях, как, например, система управления КД и ТД, система административного документооборота или электронный архив, стоит обратить внимание на подходы к их разработке и внедрению. Наверное, мы не изобретем велосипед, приводя следующую последовательность:
Прохождение всех пунктов приведенной последовательности — сложная совместная работа представителей как предприятия, так и компании-поставщика решения. Однако и здесь есть исключения. Рассмотрим их.
Бытует мнение, что процесс сдачи/приемки в промышленную эксплуатацию — совместная работа компании-поставщика решения и предприятия. Заметим по этому поводу следующее:
В процессе прохождения приведенной последовательности создания системы возникают различные «подводные камни», которые можно разделить на две основные группы:
При этом, как правило, причиной возникновения первых могут являться вторые — и наоборот. Например, «формально» утвержденное ТЗ влечет массу технических проблем, а попытка технически сразу «объять необъятное» может привести к необходимости мгновенной серьезной реорганизации на предприятии, на которую в короткое время невозможно выделить необходимые ресурсы…
Технические проблемы обычно тем или иным образом решаются, причем достаточно успешно. Самыми же трудными для преодоления являются организационные проблемы. Например, успех внедрения в значительной степени зависит от человеческого фактора. Как правило, решение организационных проблем в принципе невозможно без привлечения руководителя того или иного уровня, иногда — и уровня генерального директора предприятия. В связи с этим административная воля руководства — один из основных факторов успешного внедрения.