ЛОЦМАН — от PLM к ERP: опыт внедрения ЛОЦМАН:PLM и КОМПАС-3D на предприятии ОАО «ЭЗТМ»

Юрий Ершов

Введение

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

Идеология построения информационного пространства

Выбор программного обеспечения

ЛОЦМАН:PLM — опыт самостоятельного освоения

VISUAL ЛОЦМАН — самостоятельный путь развития

Организационные проблемы

Перспективы и пожелания

Александр Личман, продакт-менеджер компании АСКОН Опыт реализации проекта по созданию единой информационной системы для управления жизненным циклом изделий, выпускаемых ОАО «ЭЗТМ», на основе системы ЛОЦМАН:PLM наглядно продемонстрировал особенности как самого программного продукта, так и взаимоотношений между АСКОН и предприятием-заказчиком. ЛОЦМАН:PLM изначально проектировалась как система, отличающаяся гибкостью и возможностью адаптации под конкретного пользователя. В этом ее существенное отличие от «коробочных» решений. Поскольку принципы организации производства, бизнес-процессов, структуры предприятия и даже состава изделия зачастую довольно специфические, «коробочные» решения не всегда способны решить весь комплекс производственных задач. При разработке ЛОЦМАН:PLM в АСКОН это прекрасно понимали. Безусловно, существует и второе активно развивающееся направление нашей работы по развитию программного комплекса на основе ЛОЦМАН:PLM — это разработка типовых, компактных, легких в установке и развертывании решений, которые с успехом применяются малыми и средними предприятиями. Те же из наших заказчиков, кто распознал «изюминку» ЛОЦМАН:PLM — возможность кастомизации, — нагружают комплекс уникальными специфическими задачами, порой выходящими за рамки КТПП. И в этом есть своя прелесть: можно решать локальные задачи своими силами, без приобретения очередного специализированного пакета ПО. Как верно отмечает Ю.Л.Ершов, бизнес-процессы являются одним из трех китов информационной системы предприятия. Только после анализа хотя бы ключевых процессов имеет смысл запускать в работу решения класса ЛОЦМАН:PLM. Ведь первична именно автоматизация процессов. В связи с этим мы надеемся на дальнейший опыт ОАО «ЭЗТМ» в использовании системы управления потоками заданий ЛОЦМАН Workflow. Однако приобретение мощного программного обеспечения не является достаточным условием для комплексной автоматизации предприятия. Огромную роль в решении этой задачи играет команда внедрения, компетентность работников предприятия. В подавляющем большинстве случаев залогом успешного внедрения программного комплекса является инициативная команда и целеустремленный руководитель, и опыт ОАО «ЭЗТМ» — яркое тому подтверждение. В будущем роль таких специалистов будет только возрастать. Об этом свидетельствуют примеры предприятий ОАО «Курганхиммаш», ЗАО «Вагонмаш», ФГУП «ПО «Севмаш» и многих других. В завершение хочется выразить искреннюю благодарность Ю.Л.Ершову и его команде за признание системы, за энтузиазм и решимость в процессе внедрения; за постановку сложных задач и за опыт их решения. Этот ценный опыт обогатил АСКОН свежими идеями, которые лягут в основу новых и уже существующих программных продуктов. Продуктов, которые создаются для заказчиков исходя из их потребностей в решении производственных задач.

Введение

Открытое акционерное общество «Электростальский завод тяжелого машиностроения» (ОАО «ЭЗТМ») — одно из крупнейших предприятий тяжелой промышленности России.

Завод специализируется на проектировании и выпуске следующего металлургического оборудования:

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

ОАО «ЭЗТМ» — предприятие законченного цикла, включающего металлургическое, сварочное, механосборочное и вспомогательные виды производства. В составе предприятия работают научно-исследовательский, конструкторский и технологический отделы.

Производственный процесс ОАО «ЭЗТМ» может быть охарактеризован как единичное дискретное производство с синхронным циклом разработки продукции и технологической подготовки производства.

Одним из направлений развития ОАО «ЭЗТМ» до 2015 года утверждено создание единой информационной системы. Использование информационных технологий (ИТ) в совокупности с другими элементами корпоративной стратегии призвано способствовать достижению долгосрочных целей предприятия. И первоочередной среди них для ОАО «ЭЗТМ» является обеспечение конкурентоспособности предприятия через оптимизацию потребительских характеристик продукции, сроков поставки и цен. Поэтому подготовка достоверной исходной информации для контура управления производством становится ключевой задачей при комплексной автоматизации предприятия.

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

С точки зрения применения ИТ интересны следующие показатели работы предприятия:

• ежегодно создается более 100 тыс. новых (уникальных) объектов проектирования (сборочных единиц, деталей, комплектов), из них ориентировочно 30-40 тыс. идут в производство, для каждого из них разрабатывается уникальная технология;
• архив технической документации содержит 5 млн единиц конструкторских документов. В работе находится пять основных серий номеров чертежей (по 999 999 единиц каждая). По окончании серии старая документация уничтожается в плановом порядке и серия начинается заново;
• более 350 тыс. позиций в корпоративном справочнике материалов и покупных изделий. Справочник непрерывно обновляется и дополняется.

Идеология построения информационного пространства

Любая информационная система предприятия базируется, как правило, на трех китах: информационная структура (или база данных) предприятия, информационная структура (или база данных) изделия и структура бизнес-процессов. На рис. 1 представлена укрупненная схема информационной системы предприятия.

Объекты структуры предприятия  — информационные объекты, описывающие непосредственно предприятие и его структуру и содержащие в собственных атрибутах всю необходимую информацию для выходных документов системы.

Рис. 1

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

Третью группу объектов информационной системы составляют бизнес-процессы. Бизнес-процесс — это локализованный объект информационной системы, определяющий конкретный процесс над входящими материальными или информационными ресурсами, которые являются объектами структуры изделия, по определенному локализованному сценарию. Результат бизнес-процесса — также материальные или информационные ресурсы, которые тоже являются объектами структуры изделия. Непосредственными исполнителями и потребителями результатов бизнес-процесса являются объекты — структурные подразделения предприятия или конечный потребитель — заказчик.

При детализации системы, как правило, используется следующий алгоритм:

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

2. На основании полученной информации подразделение запускает локальный бизнес-процесс.

3. Окончание бизнес-процесса завершается изменением информации (или введением новой) как в базе данных об изделиях, так и, возможно, в базе данных предприятия.

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

Основные принципы построения системы:

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

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

Рис. 2

Указанная план-карта приведена в качестве примера. На практике после первичного анализа бизнес-процесса она должна быть согласована с руководителем конкретного подразделения — участником данного процесса.

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

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

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

Факт выпуска или покупки программного обеспечения недостаточен для внедрения системы. Огромную (если не определяющую) роль играют организационные вопросы.

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

На рис. 3 в таблице представлены основные пункты регламента, на которые необходимо обратить особое внимание при внедрении системы.

Рис. 3

Общий порядок внедрения может быть следующим:

1. Разработка (или приобретение) программного обеспечения.

2. Тестовый период и отладка процедур.

3. Разработка регламента и изменений в документе «Положение о подразделении и соответствующие должностные инструкции».

4. Обучение персонала.

5. Аттестация персонала.

6. Перевод сотрудников на новые должности.

7. Запуск системы, сопровождающийся соответствующим приказом руководства предприятия.

Выбор программного обеспечения

В соответствии с указанной идеологией был проанализирован регламент конструкторского подразделения ОАО «ЭЗТМ». В настоящий момент анализируется дальнейшая цепочка технической подготовки производства.

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

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

Такое положение вещей обусловливает своеобразные требования к программным продуктам CAD. Прежде всего это должна быть CAD-система 3D-моделирования с возможностью оформления технической документации по ЕСКД.

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

Мы обратили внимание на ряд «полутяжелых» и «средних» программных продуктов, таких как Mechanical Desktop, Inventor, SolidWorks. Из российских разработок наше внимание привлекли T-FLEX и КОМПАС. В полудомашних условиях мы прошлись по всем указанным продуктам.

При внимательном рассмотрении план-карты конструкторского бизнес-процесса (см. рис. 2) мы увидим, что в конструкторском документообороте, в соответствии с системой менеджмента качества, 3D-модель как контрольный документ, подписываемый автором и утверждаемый руководством, отсутствует. 3D-моделирование по своей сути является технологией получения технической документации (сборочных и детальных чертежей), а с применением ЧПУ — технологией производства деталей. Другими словами, с точки зрения ИТ 3D-модель является объектом соответствующей бизнес-процедуры. Основной же объем отчетной (контрольной) документации представляет собой 2D-документы: чертежи, табличные формы, спецификации различных типов и текстовые документы, причем оформленные в ЕСКД. Кроме того, в ОАО «ЭЗТМ» применяется так называемая расширенная форма конструкторской спецификации с дополнительными полями, несколько отличающаяся от ЕСКД (рис. 4).

Рис. 4. Форма конструкторской спецификации ОАО ЭЗТМ

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

К сожалению, во всех западных программных продуктах с небольшими замечаниями и дополнениями можно было оформить только сборочный чертеж и чертеж детали по ЕСКД. Спецификацию (или состав изделия) предлагалось выгрузить в такие продукты Microsoft Office, как Word и Excel.

Только ознакомившись с продукцией компании АСКОН, мы с удовлетворением обнаружили, что, несмотря на некоторые издержки в 3D-моделировании ранних версий, КОМПАС-3D практически полностью покрывает весь наш документооборот. После проведения опытного проекта в среде КОМПАС-3D и выдачи комплекта конструкторской документации по одному из заказов было принято решение о приобретении необходимого количества лицензий. Справедливости ради следует отметить, что в современных версиях КОМПАС-3D издержки 3D-моделирования, указанные выше, разработчиками устранены.

Работа крупного конструкторского подразделения в любой CAD-системе рано или поздно приводит к необходимости упорядочения данных и организации коллективной работы над проектом. Не избежали этой участи и мы. Специалисты компании АСКОН рекомендовали нам ознакомиться с системой управления инженерными данными ЛОЦМАН:PLM. Нами было было принято решение о проведении пилотного проекта, по итогам которого была приобретена система ЛОЦМАН:PLM и началось ее внедрение силами сотрудников ОАО «ЭЗТМ».

ЛОЦМАН:PLM — опыт самостоятельного освоения

Для непосвященных читателей отмечу, что, на мой взгляд, ЛОЦМАН:PLM — это прежде всего удобный инструмент для моделирования информационного пространства любого уровня сложности. ЛОЦМАН:PLM представляет собой набор следующих компонентов:

• сервер баз данных (MS SQL или Oracle);
• разработанная база данных в виде набора взаимосвязанных таблиц;
• файловый архив для хранения документов;
• разработанная идеология объектно-ориентированного моделирования информационного пространства на основе указанной выше базы данных;
• сервер приложений с разработанными в соответствии с идеологией методами работы с базой данных и собственным API;
• базовый инструментарий в виде приложений ЛОЦМАН-Администратор и ЛОЦМАН-Конфигуратор, которые позволяют создавать и настраивать собственное информационное пространство;
• клиентское приложение ЛОЦМАН-Клиент;
• специальный компонент ИНТЕГРАТОР, позволяющий экспортировать информацию из базы данных в различные документы, зарегистрированные в системе, и наоборот — осуществлять импорт информации из документов, разработанных в каком-либо редакторе, в базу данных.

Судя по заявленному набору компонентов, ЛОЦМАН:PLM идеально подходил под нашу идеологию построения информационного пространства, описанную выше.

С созданием собственной базы данных никаких проблем не возникло. Мы довольно быстро разобрались с конфигурированием базы данных и смоделировали свой информационный поток в том виде, как мы его себе представляли. Дальше начались сложности.

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

Рис. 5. Окно клиентского приложения ЛОЦМАН

 

Рис. 6. Окно клиентского приложения EZTM Commander

В соответствии со своей идеологией мы начали выстраивать в системе ЛОЦМАН:PLM не только информационное пространство состава изделия (как в традиционной PDM-системе), но и информационное пространство структуры предприятия. И это явно перегрузило базовое клиентское приложение ЛОЦМАН-Клиент.

Прошло какое-то время, пока мы поняли, что нагружать PDM-систему такими задачами не совсем корректно. Встал вопрос: либо искать другую готовую систему, либо самостоятельно развивать ЛОЦМАН:PLM в нужном нам направлении. Для движения по второму пути прежде всего необходимо было написать свое клиентское приложение с более близким к различным группам пользователей интерфейсом. С этим вопросом мы обратились в АСКОН. Нам порекомендовали изучить приложение ЛОЦМАН-API и прислали документацию к нему.

Во второй половине 2006 года мы получили от специалистов компании АСКОН описание API, собрались с духом перед долгой дорогой… и окунулись в «волшебный мир» Delphi. С этого момента у проекта ЛОЦМАН:PLM на нашем предприятии (да и у нас тоже) началась новая жизнь…

VISUAL ЛОЦМАН — самостоятельный путь развития

С самого начала были определены основные требования к нашему клиентскому приложению (рис. 6):

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

Мы сразу же отказались от долговременной блокировки самих объектов. В нашем случае на долгий срок блокируются только документы, с которыми пользователь работает непосредственно в данный момент. Блокировка объектов происходит незаметно для пользователя и только во время внесения изменений в базу данных (как правило, при нажатии кнопки Ok при закрытии окна).

Мы в корне изменили идеологию работы с базой данных. Обычно все CAD-системы рекомендуют следующий вариант интеграции с PDM-оболочками: сначала конструктор формирует дерево состава изделия в CAD-системе, а затем с помощью интегратора передает этот состав вместе с необходимыми атрибутами в PDM.

Мы же приняли решение, что первичной является информация в базе данных. Именно с ней изначально должен работать конструктор (или другой пользователь системы). В нашем случае конструктор сначала регистрирует необходимый ему состав изделия в базе данных и только потом создает необходимый документ в редакторе (в данном случае в КОМПАСе), используя набор шаблонов, зарегистрированных в системе. Работа ведется в окне сборочной единицы (см. рис. 8), которое визуально напоминает форму спецификации (см. рис. 4). При этом производится прямая интеграция с объектом КОМПАСа, то есть передача атрибутов объекта базы данных в объект КОМПАСа с помощью открытого COM-интерфейса. Для каждого документа разработан свой модуль интеграции.

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

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

В процессе развития нашего клиентского приложения мы обратили внимание на то, что при разработке конкретных окон для различных типов объектов их свойства и методы визуализации повторяются. В связи с этим в определенный момент разработка клиентского приложения таким «прямым» способом была приостановлена. Была поставлена задача проанализировать ситуацию и написать библиотеку визуальных и невизуальных компонентов Delphi, специально «заточенных» под ЛОЦМАН:PLM.

Через какое-то время в среде Delphi была сформирована библиотека собственных компонентов, получившая свое оригинальное, но неофициальное название Visual Loodsman. В ее состав вошли как невизуальные (в основном объединяющие методы сервера приложений через DCOM-соединение), так и визуальные компоненты. В качестве визуальных компонентов в библиотеке представлены различные поля, в свойствах которых фиксируются тип и название атрибута, таблицы, деревья, модальные и немодальные окна с привязками к вершинам базы данных, панель «В работе…» и т.д. Кроме того, сформирован шаблон клиентского приложения.

После появления такой библиотеки разработка собственных клиентских приложений превратилась в относительно простое и увлекательное занятие. Фактически работа по созданию клиентского приложения представляет собой процесс моделирования интерфейса в среде Delphi с минимальными издержками на «функциональное» программирование.

Рис. 7. Учетная карта заказа ОАО _ЭЗТМ_

 

Рис. 8. Учетная карта узла (отгрузочного комплекта), входящего в заказ

 

Рис. 9. Сквозной поиск заказов в базе данных

В результате всего этого процесс развития клиентских приложений в ЛОЦМАН:PLM значительно ускорился. Судите сами: за последние 8 месяцев EZTM Commander был перекомпонован заново и серьезно доработан, кроме того, он постоянно обновляется. В данном приложении к настоящему моменту разработаны и внедрены следующие задачи:

• регистрация производственных заказов (рис. 7 и 8);
• сквозной поиск заказов по базе данных (рис. 9);
• регистрация конструкторского состава изделия с созданием документов и интеграции с ними в среде КОМПАС (также проработана возможность работы с SolidWorks и AutoCAD) — рис. 10 и 11;

Рис. 10. Учетная карта сборочной единицы — Конструкторская спецификация

 

Рис. 11. Учетная карта детали с таблицей собственных документов

 

Рис. 12. Сквозной поиск конструкторских объектов в базе данных

• сквозной поиск конструкторских объектов в базе данных (рис.12);
• формирование перечня чертежей по заказу (рис. 13);

Рис. 13. Перечень чертежей

 

Рис. 14. Конструкторское (предварительное) извещение об изменении

 

Рис. 15. Общая подетальная спецификация — Производственный состав изделия

• регистрация конструкторского извещения об изменении (рис. 14);
• формирование производственного состава изделия по заказу (рис. 15);
• справочник стандартных изделий (нормалей) ОАО «ЭЗТМ» (рис. 16);
• регистрация данных о предприятии и его структурных подразделениях (рис. 17);

Рис. 16. Справочник стандартных изделий — Нормали ОАО _ЭЗТМ_

 

Рис. 17. Регистрация информации о предприятии и структуры подразделений

 

Рис. 18. Регистрация информации о подразделении

• регистрация информации о подразделении и конструкторских рабочих местах (рис. 18);
• регистрация информации о рабочей папке конструктора и регистрация конструкторской работы на рабочем месте конструктора (АРМ конструктора) — рис. 19;
• сканирование всей вновь выдаваемой и ранее выданной рабочей документации, ее регистрация в базе данных, хранение в электронном архиве с обеспечением сквозного поиска электронных версий архивных копий и просмотр конструкторской документации в соответствии с уровнем доступа пользователя (рис. 20 и 21).

На рис. 22-26 представлены проекты различного оборудования, разработанные и выданные в производство с помощью системы ЛОЦМАН:PLM — EZTM Commander. Сегодня в системе зарегистрировано около 160 пользователей из разных подразделений, в перспективе — более 500.

Рис. 19. Рабочая папка конструктора

 

Рис. 20. Сквозной поиск архивных (сканированных) копий конструкторской документации

 

Рис. 21. EZTM Viewer — собственная разработка для просмотра сканированных копий конструкторской документации в зависимости от уровня доступа пользователя

Задачи, стоящие на очереди:

• создание в среде ЛОЦМАН:PLM корпоративного справочника материалов;
• создание в среде ЛОЦМАН:PLM корпоративного справочника инструмента;
• создание в среде ЛОЦМАН:PLM корпоративного справочника станочного оборудования;
• формирование в среде ЛОЦМАН:PLM технологических карт маршрутной технологии;
• формирование в среде ЛОЦМАН:PLM документооборота регламента собственного литейного производства;
• формирование в среде ЛОЦМАН:PLM документооборота регламента собственного сварочного производства;
• регистрация производственных извещений об изменениях;
• реализация регламента внесения изменений в конструкторский и производственный составы изделия;
• интеграция информационного потока ЛОЦМАН:PLM с ERP-системой.

Конечно, при разработке Visual Loodsman мы решали прежде всего свои задачи и не ставили себе цель сделать этот проект коммерческим. Сегодня же мы видим, что в среде Visual Loodsman реально можно смоделировать информационную систему любого уровня сложности. И прежде всего перед нами стоит задача создать комплексную автоматизированную систему технической подготовки производства и в концентрированном виде организовать передачу информации в ERP-систему.

Рис. 22. Дробилка щековая ЩДП 12х15-Ф — количество деталей 2643

 

Рис. 23. Рабочая клеть калибровочного стана — 2120 деталей

 

Рис. 24. Стан калибровочный — 10 534 деталей

Организационные проблемы

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

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

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

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

По нашему мнению, возможны следующие варианты внедрения информационной системы:

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

В ОАО «ЭЗТМ» процессы развиваются и по первому, и по второму, и по третьему вариантам, и зачастую внедрение ИТ-проектов натыкается на различные подводные камни.

Перспективы и пожелания

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

Сегодня на рынке представлен целый ряд самых разнообразных ERP-систем. Многие предприятия начинают сами разрабатывать что-то подобное. Основные ресурсы, выделяемые на ИТ-проекты, направляются на внедрение ERP-систем, на автоматизацию управления производством. Фактически все представленные на рынке ERP-системы имеют свои PDM-модули. Конечно, они не такие развитые, как ЛОЦМАН:PLM. Однако, результативно внедрив у себя на производстве ERP-систему, менеджмент предприятия обязательно начнет продвигать соответствующий PDM-функционал.

У компании АСКОН, на мой взгляд, есть все предпосылки для того, чтобы на базе проекта ЛОЦМАН разработать собственную ERP-систему.

Кроме того, существует еще одна проблема. Выстроив конструкторский регламент в среде Visual Loodsman, мы пошли дальше по цепочке технической подготовки производства. И здесь мы столкнулись с необходимостью создания «тонкого» клиента — клиентского приложения, решающего задачу ввода и редактирования информации. Учитывая, что проект «ЛОЦМАН — КОМПАС» выстроен на базе Microsoft Windows, эта задача не так-то просто решается. В сети формируется плохо контролируемый трафик, запускаемый фоновыми службами Windows. Вместе с тем остается возможность несанкционированного использования компьютерной техники для непроизводственных нужд.

Кроме того (об этом написано уже немало), компания Microsoft ведет откровенно агрессивную политику по навязыванию пользователям новых версий своей операционной системы. Через 2-3 года многие предприятия встанут перед проблемой нового лицензирования, так как компьютерная техника перестанет воспринимать устаревшие версии. Финансовая нагрузка на российские предприятия со стороны компании Microsoft весьма ощутима.

В связи с этим создание работоспособной информационной системы действующего предприятия на базе свободной non-Windows операционной системы и non-Microsoft программных продуктов является стратегической задачей для российских ИТ-специалистов на ближайшие 2-3 года.

Тот, кто решит эту задачу и внедрит такую систему, получит серьезные преимущества на рынке ИТ. У проекта «ЛОЦМАН — КОМПАС» для этого есть все возможности.

Специалисты ОАО «ЭЗТМ» в последнее время всерьез задумываются над задачей написания клиентского приложения в среде Linux с использованием Socket-сервера. Очень хотелось бы, чтобы компания АСКОН обратила внимание на данное направление. Специалисты ОАО «ЭЗТМ» готовы оказать ей посильное содействие в решении данной задачи.

В заключение хотелось бы пожелать всем специалистам компании АСКОН успехов в их бизнесе и всего самого наилучшего!

---

Юрий Ершов

Начальник КБ станов продольной прокатки ОАО «ЭЗТМ», руководитель проекта.

САПР и графика 11`2007