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

При общении с поставщиками тех или иных решений очень часто доводится слышать что-нибудь вроде: «Приобретете нашу систему — и решите все или почти все свои проблемы». CAD, PDM, PLM, MRP, ERP, CRM, SCM — замечательные и правильные системы разных поколений (новейшие можно отнести к четвертому и пятому поколениям) на самых совершенных современных платформах. Кроме этого есть операционные системы, реляционные и объектно-ориентированные СУБД, структурированные кабельные системы и еще большое количество не менее важных и замечательных систем.

Но как же собрать вместе системы, которые при правильном их выборе позволят нам получить главное новое «свойство», иначе зачем было объединять системы, «закрывающие» 80% основных проблем предприятия (согласно известному соотношению 20/80)?

Эволюция управления данными

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

Рис. 1. Эволюция управления данными на предприятии

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

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

Рис. 2. Компоненты ИТ на машиностроительном предприятии (РБП — реинжиниринг бизнесс-процессов, TQM — Total Quality Management, всеобщий менеджмент качества)

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

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

Шаг за шагом

В 2000 году на заводе «Арсенал» было решено приступить к выбору системы управления данными о продукте (PDM системы), которая бы удовлетворяла двум обязательным требованиям при описании конструкторско-технологического графа: поддерживала версии описания состава изделий (поколения изделий по номеру изделия и по дате) и давала возможность оценки нескольких вариантов технологии изготовления при проработке изделия на технологичность.

В то время (шла первая половина 2000 года) отечественных разработок, удовлетворяющих этим требованиям, не было. Совместно с фирмой «БиПитрон» предприятие остановило свой выбор на семействе продуктов компании Smart Solutions — SmarTeam и SmartFlow. Для реализации пилотного проекта было решено ограничиться внедрением трех клиентских мест SmarTeam и сервера SmartVault (хранилище данных). Цель проекта — настройка полнофункциональных клиентских мест конструктора в соответствии с требованиями ЕСКД и стандартов предприятия под реорганизованные процессы создания и сопровождения конструкторской документации (модель, чертеж, конструкторская спецификация, нормоконтроль, ведение карточки архива твердых копий КД, разузлование в режиме реального времени). Попутно удалось разработать структуру классов объектов технологических процессов. Аудит проектных решений был выполнен Инжиниринговым центром СПбГТУ.

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

В рамках пилотного проекта по внедрению SmarTeam для управления процессами создания и сопровождения КД мы предложили свой вариант локализации (т. е. настройки под требования ЕСКД, отраслевых стандартов и стандартов предприятия) и начали внедрение.

Текущее состояние

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

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

Предварительные итоги

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

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

Сергей Королев — первый заместитель генерального директора ОАО «МЗ ?Арсенал?» (Санкт-Петербург)

Виктор Кучерявых — начальник управления ИС ОАО «МЗ ?Арсенал?», system@mza.spb.ru

Завод «Арсенал»

ОАО «Машиностроительный завод ?Арсенал?» является лидером российского рынка в области изготовления и поставки современного артиллерийского вооружения и пусковых установок для нужд Военно-морского флота, а именно для вооружения надводных кораблей различного водоизмещения и назначения. На основанном в 1711 году заводе сейчас развернуты заготовительное, инструментальное производство, механообработка, сборка и испытания изделий. На предприятии работает свыше 2 тыс. сотрудников. В 2001 году доход предприятия составил 31,6 млн. долл.

Моделирование операций

Генрих Саулович Альтшулер в своей теории решения изобретательских задач приводит удачное, на наш взгляд, ранжирование функций или операций, выполняемых технической системой или работником на своем рабочем месте. В соответствии с современными тенденциями реорганизации предприятия, при переходе от доставшихся по наследству структур управления к управлению проектами и процессами резонно воспользоваться ТРИЗовской классификацией операций. Рассматривается пять их типов:

  • положительные (характеризуются тем, что параметр меняется в нужную сторону и необратимо; основные операции, ранг 0).
  • обеспечивающие (вспомогательные, ранг 1, 2, 3...);
  • контрольно-измерительные (осуществление контроля параметров процесса или операции);
  • вредные (вносят отклонения в параметры, в результате чего они принимают недопустимые значения);
  • исправительные (возвращают параметрам требуемые значения; нужны лишь в случае, если есть вредные операции).

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

Понятие «операция» сводится к трем типам:

  • СОЗДАТЬ. Это слабо формализованные операции, основная задача которых - предоставление инструмента для выполнения операций и четко прослеживаемого их авторства.
  • ВЫБРАТЬ. Уровень формализации этих операций различен. В случае полного отсутствия правил формирования множества, из которого выполняется выбор, и правил выбора, эта операция превращается в предыдущую (иди туда, не знаю куда, принеси то, не знаю что). Пример максимального уровня формализации - это операция "выбрать" при следующем режиме работы пользователя-конструктора: он выполняет операцию "вставить стандартное изделие в сборку (крепеж) из уже примененных в других изделиях". Он не имеет права создать новый экземпляр объекта "крепеж".
  • ОФОРМИТЬ. Наиболее четко формализованные операции - требования по оформлению в соответствии с ЕСКД, ЕСТД и СТП документа. Форма документа, штамп, подписи, толщина линий на чертеже, условные обозначения, регламент прохождения документа определены стандартами различного уровня, в том числе и стандартами предприятия.

Операции «Согласовать», «Утвердить», «Нормоконтроль» — примеры контрольно-измерительных, обеспечивающих качество процесса.

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