Российское авиастроение выходит из кризиса, постепенно занимая свое место в международном разделении труда. Новые условия работы диктуют новые подходы к применению информационных технологий. Корпорация «Иркут» — флагман российского авиастроения. О том, как развиваются ИТ и какие при этом ставятся задачи и приоритеты, рассказывает руководитель департамента информационных технологий корпорации «Иркут» Николай Волков.
Родился в 1967 году в Рыбинске, в 1990м закончил Рыбинский авиационный технологический институт по специальности «инженерконструктортехнолог электронновычислительной аппаратуры».
Работать в корпорацию «Иркут» пришёл в 2003 году.
С 2005 года руководит ИТдепартаментом корпорации и по совместительству является руководителем департамента ИТ ФГУП РСК «МИГ».
Intelligent Enterprise: У корпорации «Иркут» сложный и многоплановый бизнес, связанный в том числе и с международными контрактами. Каковы направления и приоритеты ИТподдержки работы компании? Из каких элементов складывается её ИТландшафт?
Николай Волков: Наша стратегия в области ИТ состоит в том, чтобы поддержать полный цикл жизни изделий. В целом ИТстратегия как документ составлена на период до 2010 года: детально — на текущий год и более крупно — на два следующих.
Если говорить о конкретных направлениях, то прежде всего это CAD/CAM/PDM. В основном используется UGS Unigraphics как базовая система CAD/CAM, а кроме того, ещё AutoCAD, SolidEdge и целый набор специализированных приложений для цифрового проектирования и конструкторскотехнологической подготовки производства. В результате дополнения ПО UGS Teamcenter нашими собственными разработками у нас сложилась своя PDMсистема, аналогов которой в России мы не знаем.
Здесь надо сказать, что мы активно участвуем в сложившейся в отрасли кооперации, поэтому наши конструкторы зачастую выполняют работы, скорее подходящие инженерному центру, нежели серийному авиационному заводу. По сути дела «Иркут» сейчас — это значительно больше, чем серийный авиационный завод. Основной продукт корпорации — самолеты СУ30. Разрабатывает их ОКБ Сухого, так что говорить, что по этому продукту у нас есть полный цикл проектирования, мы не можем. В настоящее время в электронном виде осуществляется разработка полного макета и подготовка к запуску в производство самолета ЯК130, поскольку КБ имени Яковлева, разрабатывающее его, входит в состав корпорации «Иркут». Есть сложившиеся в отрасли стандарты, и если КБ и серийный завод не входят в один холдинг, им намного сложнее договориться об интеллектуальной собственности, решить вопрос об использовании цифровых документов вместо бумажных. Следующий класс — ERPсистемы управления ресурсами и персоналом. У нас это Baan (сегодняшнее название — Infor ERP LN) и «БОССКадровик». Такая конфигурация, на наш взгляд, является наиболее оптимальной по критерию «цена/качество» решения. И, кроме того, есть большой пласт систем по управлению финансовоэкономическим блоком.
Работа корпоративного проектного офиса автоматизирована с помощью системы управления проектами Open Plan. В ней ведутся проекты всех типов — как производственные, для внешних клиентов, так и внутренние, включая ИТпроекты. Замечу, что практика управления ИТпроектами у нас разработана лучше всего, по ним есть комплексный план, который детализирован до конкретного исполнителя. Важно, что Open Plan — не только обычный рабочий инструмент сотрудников корпорации. К нему имеют доступ и наши заказчики, в том числе компания Airbus, чьи менеджеры отслеживают ведение общих с ними проектов. Это приложение мы используем с 2002 года, постепенно расширяя рамки его применения, хотя от инструмента зависит все же не так много. При проектных работах гораздо важней методология и организационная структура.
Еще один важный, новый и сложный для нас блок ПО обеспечивает автоматизацию послепродажной поддержки и логистического обслуживания. Интегрированная логистическая поддержка не сводится к тому, чтобы постоянно держать у себя комплект запчастей. Когда вы покупаете автомобиль, вы можете заранее узнать схему, сроки и стоимость эксплутационных расходов, замены запчастей, расходных материалов. То же и для самолетов, только на два порядка сложнее, но именно такую поддержку мы и должны обеспечивать. Еще перед покупкой наш заказчик должен понимать, какова будет стоимость летного часа, когда и какие типы ремонта будут нужны, какой уровень надежности мы можем гарантировать и как будет обслуживаться техника, как быстро будут поставлены необходимые запасные части и комплектующие. Без этого наши зарубежные заказчики предложения вообще не рассматривают. Поэтому у нас создано отдельное структурное подразделение, занимающееся этими вопросами, но решить их в одиночку мы, конечно, не сможем. В этой области мы сотрудничаем с ТАНТК имени Бериева, который входит в нашу корпорацию и имеет центр логистической поддержки. Если говорить об ИТподдержке послепродажного обслуживания, то нам пришлось приобрести лицензии на ПО английской фирмы LBS — практически единственного продукта нужного нам класса, который включает процессы послепродажной поддержки.
Таким образом, мы стараемся охватить все стадии жизненного цикла нашего продукта: управление проектами, проектирование и подготовку производства (CAD/CAM/PDMсистемы), собственно производство (ERP и HRсистемы, разнообразные решения по промышленной автоматизации) и системы послепродажного обслуживания.
Как вы подходили к внедрению информационной системы управления предприятием? Решение Baan традиционно славится сильным производственным блоком, а для предприятий вашего профиля это наиболее значимая часть процессов. Но опыт показывает, что внедрение данного продукта очень редко начинается с производственного модуля.
Baan на «Иркуте» имеет давнюю историю. В системе управления ресурсами предприятия самое простое — управление финансами, с них мы и начинали внедрение. Затем последовала логистика, а очередь производства пришла только теперь.
Надо сказать, что в свое время в связи с изменением стратегии работы вендора в России перед нами встал вопрос, что делать: либо найти подрядчика, способного помочь нам с Baan, либо самим развивать центр компетенции или перейти на другую систему. Когда мы вышли на компанию GMCS, готовую поддерживать нас в этом проекте на выбранной нами платформе, то для начала протестировали команду консультантов на небольшом проекте — внедрении модуля «Российские основные средства». Результатами остались довольны и решили работать с GMCS и дальше. Позже возникла задача провести апгрейд на новую версию системы — Infor ERP LN (версия Baan 6.1), без чего мы не могли модифицировать свое решение. По сути дела выхода у нас не было, переход был просто необходим. Этот проект мы провели совместно с GMCS c марта по август 2006 года, и затем у нас стартовал проект по автоматизации производства уже на базе Infor ERP LN.
Я согласен, для серийного авиационного завода автоматизация производства — самое важное в системе управления предприятием. Но производство автоматизируется тяжело, требует массы подготовительных вещей, включая создание НСИ. Не надо забывать, что идеология производства на Западе и у нас различна: западные системы рассчитаны на чисто сборочную модель, а у нас на большинстве заводов проходит почти полный цикл. Кроме того, сейчас корпорация ведет реструктуризацию, выделяет специализированные производства в отдельные компании, поскольку в системе, разбитой на множество модулей и отдельных блоков, управление можно организовать намного эффективней, чем в одной целостной структуре.
Как вы подходили к автоматизации производства? Ведь возможны разные уровни автоматизации и погружения информационной системы управления в производство.
Стратегия автоматизации производства у нас такова. Топменеджеров интересует не загрузка станков, а сроки исполнения производственной программы в целом, сроки готовности партий самолетов и потребности в необходимых для этого ресурсах. Важны и сроки поставки ключевых компонентов, двигателей, например. Но хотя это вопросы достаточно высокоуровневые, получить такую информацию без инфраструктуры сбора данных невозможно. Если не довести автоматизацию хотя бы до уровня цехового управления, включая внутрицеховую логистику и загрузку оборудования, мы получим лишь весьма прикидочные оценки.
Поэтому мы и начали с автоматизации управления производством на уровне цехов. Это прежде всего управление материалами, деталями и агрегатами на входе в цех и выходе из цеха. Тут должен быть налажен автоматический учет. Вовторых, планирование и текущая загрузка до уровня рабочих центров — не до каждого станка, а до группы оборудования, до уровня мастера. Крайне важно знать загрузку оборудования до рабочих центров, время простоев и переналадки, какими именно операциями оно было загружено и кто за каждую операцию отвечал. Это даст нам инфраструктуру для дальнейшего сбора и генерализации информации.
Следующая задача — внутрицеховая логистика. Все материалы и детали имеют код, зафиксированный в сопровождающих документах. RFID и подобные технологии нами рассматривались, но пока мы решили, что в настоящее время эта задача не является приоритетной, и оставили ее на будущее. Даже учет, основанный на стандартных документах, позволит нам наладить достоверную оперативную отчетность, точно знать, где что находится, отслеживать движение готовых деталей и агрегатов. Следующий этап — учет затрат — только что начался, но со временем он позволит нам оперативно получать информацию о реальной себестоимости.
Так мы готовим инфраструктуру для решения более комплексных производственных задач. А дальше уже пойдет планирование производства в масштабах завода. Эти высокоуровневые задачи должны решаться автоматически, на основании выполнения более элементарных работ и сбора первичных данных. Если какойто проект в целом выполнен на 60%, то должно быть ясно, почему именно на столько. Должна быть детализация до более мелких задач, по степени исполнения которых и можно судить о готовности всего проекта.
Расскажите, как организован проект внедрения системы управления производством. С каких участков и процессов вы начали, на чем обкатывали пилотное решение, как наращивали функциональность?
Предпочтительный ИТподход — внедрение методом большого взрыва. Это безусловно красиво, но ведь корпорации надо еще и работать. Значит, при автоматизации мы четко расставляем приоритеты. В автоматизации производства таким приоритетом является программа взаимодействия с Airbus, производство компонентов. На этих цепочках происходит отработка новых бизнеспроцессов. Почему именно здесь? Изменений здесь придется вносить все же меньше, чем в основном производстве, вместе с тем эти новые процессы вполне ясны, и сама Airbus требует, чтобы такая система автоматизации была внедрена. Поэтому было решено всё отработать на участках, где выполняются работы для Airbus, а в дальнейшем этот опыт распространить на все остальные производства. Реально это означает, что автоматизируются отдельные линии внутри цехов, поскольку отдельных цехов, работающих только на Airbus, у нас нет. Автоматизируются цепочки производства определенной продукции, а когда с ними становится все ясно, переходим на другие.
Переход на новую версию ПО — по сути отдельный и непростой проект. Как он проходил у вас и какие особенности вы видите в проектах такого типа?
Вендоры выпускают новые версии своих продуктов, как пирожки пекут, при этом уровень техподдержки по старым постоянно снижают. С другой стороны, новая функциональность обычно привлекает, поэтому для нас апгрейд на новую версию претерпела не только система Baan, но и «БОССКадровик», сейчас идет переход на новую версию Teamcenter. Положительный эффект любой миграции в том, что волейневолей выверяются данные и корректируется функциональность, к которой уже притерпелись.
В любом таком проекте вначале происходит выверка того, что есть. Затем необходимо отметить все ошибки и несоответствия версий. Когда переходили на Infor ERP LN (Baan 6.1), то работу мы разделили: специалисты подрядчика переписывали стандартные функции пакета, если они у нас были изменены, а наши специалисты — то, что было сделано в четвертой версии нами самими. Объем этих доработок был немалый, но в основном это отчетные формы. К примеру, при переводе на трехзвенную архитектуру «БОССКадровика» отличий было очень много, так как у нас специфичная форма оплаты.
Большой пласт работ, про который обычно забывают, в то время как он очень трудоемкий, — это исправление инструкций пользователей, здесь возможно описание новых ролей и их тестирование. При этом большая проблема — полноценное участие бизнесподразделений в тестировании. Автоматизированного функционального тестирования у нас пока нет, только ручное.
Мы решили, что в состав акта приемки ИТсистемы в эксплуатацию должны быть внесены результаты тестов работоспособности. Если чтото случается, администраторы должны просто прогнать эти тесты и убедиться, что система после сбоя восстановлена нормально. Кроме того, нужно понимать ключевые показатели производительности, для чего применяются нагрузочные тесты. Важно проверить, не случилось ли деградации производительности системы в ходе устранения неполадок, сбоев, установки патчей, увеличения объема данных. Так что нужны стандартные схемы тестирования, как нагрузочного, так и функционального. И к ним в ходе промышленной эксплуатации системы пользователи привлекаться уже не должны. Пока это у нас в полном объеме не выполняется, но мы последовательно двигаемся в данном направлении.
Большое количество эксплуатируемых систем предполагает масштабные работы по их интеграции. Какие интеграционные подходы для вас наиболее важны? Планируете ли вы использовать сервисноориентированный подход к созданию своего ИТланшафта?
Чтобы полностью обеспечить жизненный цикл изделия, мы должны срастить уже построенную PDMсистему с внедряемой системой управления ресурсами. Пока интеграция между ними от идеала далека, она ведется в основном на уровне файлов, часть операций выполняется вручную. Кроме того, для нас важны вопросы безопасности, а при обмене файлами о ней и речи быть не может.
В настоящее время мы прорабатываем вопрос применения интеграционной платформы. Пока мы говорим не о переходе на SOA, но об общей шине передачи данных. Нам необходимо снизить издержки на интеграцию систем, и я думаю, таким образом это сделать можно. Кроме названных крупных систем у нас есть еще множество других, и если не пользоваться промежуточным ПО, то схемы взаимодействия получаются крайне запутанными. Отслеживать актуальность и целостность данных становится просто нереально.
От своих подрядчиков во всех проектах мы требуем доказательства эффективности тех или иных решений именно в наших условиях. Так же мы поступаем и с выбором интеграционной платформы: вот наши приложения, вот данные; покажите, что нам даст ваша технология.
В организационном плане в интеграционных проектах центральную роль играет единая система НСИ. Насколько вам удалось продвинуться в её создании?
Задача унификации НСИ у нас в значительной мере решена: корпорация перешла на единые справочники сырья, материалов, контрагентов. Все приложения используют единые справочники. Но именно потому, что нужно было переходить на эту единую систему справочников, мы так долго занимались автоматизацией логистики в Baan. Пришлось самим разрабатывать систему кодирования номенклатуры закупаемых товарноматериальных средств, поскольку прежняя, оставшаяся с советских времен, бизнесподразделения не удовлетворяет. Было много споров, в результате мы сначала провели кодирование, причем сами разработали информационную систему для управления номенклатурой средствами Teamcenter.
Однако хотя внутри корпорации на общую систему кодирования мы перешли, проблема здесь системная: координирующего центра в масштабах отрасли нет, все производители сырья и материалов разрабатывают собственные системы НСИ, поэтому сложности при взаимодействии неизбежны. А ведь совокупная трудоемкость чудовищная: каждый заново изобретает велосипед. Есть надежда, что хотя бы в рамках объединенной авиастроительной корпорации этот вопрос будет решен.
Что еще беспокоит вас как ИТдиректора? Какие направления развития ИТ вы намечаете на ближайшее время?
Глобальную задачу представляет снижение расходов на ИТ. За эффективностью мы постоянно следим и стараемся применить подходы, которые позволяют ее повышать. Один из них — использование стандартов самого разного типа. Например, уменьшение числа применяемых платформ, переход от самописных приложений к тиражным. Такой проект мы ведем по службе поддержки: переходим к использованию тиражного продукта, скорее всего это будет система Remedy. Нам необходимо перейти к единой, централизованной системе поддержки, хотя системы у нас большей частью распределенные, есть рабочие места даже в Индии. Этот проект должен быть закончен в нынешнем году.
Другое направление снижения расходов на ИТ — переход на тонкие клиенты. Время жизни у них больше, а затраты на поддержку меньше, можно снизить расходы на оборудование и уменьшить численность администраторов. Для заводов с большой территорией, как у нас, это очень критично. Терминальные серверы — тоже не самоцель, в конструкторском бюро они практически неприменимы, но хорошо подходят там, где есть финансовые, бухгалтерские и офисные приложения. Кроме того, сотрудники используют массу переносных устройств, которые создают угрозу безопасности, и мы должны предоставить средства для их контроля, а при необходимости и ограничения на их использование, что очень эффективно может быть решено на базе аппаратных тонких клиентов. Сейчас мы проводим тестирование, а решение примем после изучения не только достоинств, но и недостатков.
С повышением уровня безопасности связано и направление ЭЦП: мы запустили в опытную эксплуатацию удостоверяющий центр ЭЦП, с осени планируется его промышленная эксплуатация. Здесь же следует упомянуть проект автоматической авторизации пользователей на основе смарткарт. Как обеспечение технологической безопасности мы рассматриваем переход на методологию RUP при разработке ПО. Причем следование этой методологии касается и наших подрядчиков по заказной разработке — заказные приложения должны быть легко передаваемы, отчуждаемы от разработчика.
