ОАО "АГРОМАШХОЛДИНГ", в структуру которого входят производственные предприятия, связанные с изготовлением сельскохозяйственной техники, уже в течение длительного времени целенаправленно ориентируется на управление жизненным циклом (ЖЦ) продукции. Накоплен достаточный опыт ИТ-поддержки данной концепции. Это в свою очередь дает специалистам холдинга собственное видение в отношении такого известного понятия, как PLM (Product Data Management). Об этом мы беседуем с ИТ-директором ОАО "АГРОМАШХОЛДИНГ" Владимиром Капустиным, имеющим большой опыт в области реинжиниринга бизнес-процессов и внедрения систем ERP, CAD/PDM на предприятиях машино- и приборостроения.
Intelligent Enterprise: Концепцию поддержки жизненного цикла изделия принято тесно ассоциировать с технологиями автоматизированного проектирования. Так ли это и что вы вкладываете в понятие PLM?
Владимир Капустин: Я думаю, всем хорошо
понятно, что этап проектирования изделия является лишь первой фазой его полного
жизненного цикла. В том же отношении, по сути, находятся и соответствующие технологии
автоматизации. Важно также понимать, что PLM напрямую не связана с пространственной
моделью изделия, полученной на этапе его дизайна, даже если таковая создается
на предприятии при помощи продуктов класса CAD, а впоследствии дополняется системами
CAE или CAM. Если вышеназванные системы и связаны с PLM, то лишь в отношении
определенных параметров, характеризующих его дальнейший жизненный цикл, - сама
же проектируемая модель может существовать в виде различных электронных форматов,
эскизов или вообще на бумаге. В принципе PLM можно ассоциировать со знаниями
о том, как изделие проектировалось, как затем планировалось его производство,
как оно происходило реально и, наконец, как осуществлялась послепродажная поддержка
изготовленного изделия. Эти четыре последовательные фазы, к примеру, всегда
рассматриваются в западной практике, когда речь идет о технологии PLM.
После того как производимый нами продукт будет спроектирован хотя бы частично,
можно приступать к планированию его производства. Здесь к нашей системе "знаний",
ассоциируемой с PLM, добавляются характеристики, связанные с технологической
подготовкой производства, а также со снабжением. Кроме того, это информация
о технологических возможностях конкретного производства, о загрузке оборудования,
о наличии материалов на собственной площадке или у поставщиков и пр.
Далее следует этап фактического производства, который в рамках технологии PLM
можно было бы, наверное, не выделять явно, если бы данный процесс всегда осуществлялся
так, как первоначально спланировано. В реальной же практике всегда идут замены
материалов, технологических маршрутов или даже самой технологии. В большинстве
случаев это вполне штатная ситуация.
При сдаче изделия заказчику или продаже его на рынке надо как минимум знать
фактический состав изделия, а впоследствии в любой момент уметь восстанавливать
эту информацию, сколь бы сложной и объемной она ни была. Это относится уже к
этапу послепродажной поддержки жизненного цикла. Я говорю как минимум, потому
что просто передача в эксплуатацию является довольно редкой ситуацией в машиностроении.
Даже, скажем, чайники, и те поступают на сервисное обслуживание. То есть опять-таки
как минимум нам необходима информация об обращениях заказчика за сервисом. Если
же рассматривать более сложные ситуации в области автомобильной или, как в нашем
случае, сельскохозяйственной техники (не говоря уже об авиа- и судостроении),
то здесь нас интересуют уже более детальные вопросы послепродажной "жизни"
изделия: какие узлы с конкретными заводскими номерами меняются, какие, где и
в течение какого времени находятся на гарантийном или послегарантийном обслуживании.
По каждому изделию крайне желательно иметь информацию о том, сколько и в каких
условиях оно эксплуатировалось, какие его компоненты заменялись и пр. Вся эта
информация также имеет прямое отношение к PLM.
Возвращаясь к стадии проектирования, могу сказать, что данный этап все же является важным компонентом PLM. Здесь информация об изделии рождается, и к этому же этапу мы постоянно возвращаемся в случае модернизации изделия. Но подчеркну еще раз, что понятие PLM несомненно шире. У нас, например, в условиях автоматизированного проектирования, осуществляемого в системе CATIA, "рождаются" только новые изделия. Разработанные давно и даже модернизируемые изделия вынесены за скобки CAD-системы. Что касается поддержки жизненного цикла, то данную технологию мы используем в отношении всей своей продукции. Это как раз характерный пример того, что масштаб использования систем CAD/CAM/CAE не совпадает с масштабом применения технологий PLM.
Если опираться на сказанное вами, то во многом информационная поддержка PLM должна осуществляться известными и хорошо знакомыми пользователю ИТ-системами корпоративной автоматизации. Такими, как системы производственного планирования, контроля производственных процессов, сервисного обслуживания и т. д. Что бы вы могли сказать по этому поводу?
Действительно, ситуация здесь отчасти запутанная и, видимо, требует пояснений.
Начнем с того, что PLM -- это не специальное приложение и не набор приложений,
а идеология управления жизненным циклом изделия. Поэтому прямой ассоциации с
конкретными приемами автоматизации здесь нет, но в то же время без ИТ-поддержки,
конечно, обойтись трудно. По этому поводу можно отметить следующее.
Очень часто ведущие поставщики программных продуктов выпускают системы класса
PDM, ориентированные на то, чтобы клиентам (как правило, из сферы сложного машиностроения)
удобно было хранить информацию о соответствующем изделии и оперативно с ней
работать. Здесь по сути мы имеем дело с технологиями хранения и работы с данными
о составе изделия. В настоящее время многие поставщики как бы плавно расширяют
свою маркетинговую экспансию, начиная утверждать, что, скажем, с очередной версией
они уже имеют PLM-продукт. Это часто не соответствует действительности и, что
еще хуже, может дезориентировать заказчика. Детальные и идеальным способом организованные
данные о конструкторском составе изделия не могут ассоциироваться с поддержкой
жизненного цикла даже в некоем идеальном случае - когда мы всё и всегда производим
именно так, как запланировали, и когда у нас ничего никогда не ломается и соответственно
не требует обслуживания. Что касается информационной поддержки технологий PLM,
то она действительно часто осуществляется за счет других систем, и это абсолютно
нормально. Проектирование изделия с помощью систем CAD/CAE помимо создания собственно
чертежей или трехмерных моделей связано с генерацией ряда важнейших параметров,
характерных для всего последующего жизненного цикла изделия, и в этом смысле
данные программные продукты являются частью информационной поддержки PLM. Далее,
как мы уже отмечали, на этапе планирования производства появляется необходимость
в данных о производственных мощностях и загрузке оборудования, что естественно
наводит мысль о ERP-системе, которая в этом смысле также является элементом
поддержки жизненного цикла. Данным элементом (скорее всего на этапе послепродажного
сервиса) вполне могут выступать и CRM-системы, и специализированные системы
класса EAM, и системы ILS (интегрированной логистической поддержки).
Иными словами, любая система, которая может выдавать информацию о состоянии изделия или эту информацию потреблять, вполне может рассматриваться как элемент поддержки жизненного цикла.
И все же можно ли как-то качественно выделить именно информационную поддержку
PLM на фоне повседневного использования всех вышеупомянутых систем в бизнесе?
Например, путем создания некоего специфического хранилища информации об изделиях,
единого для доступа со стороны всех этих систем или же за счет особым образом
выполняемой горизонтальной интеграции бизнес-систем, имеющих отношение к поддержке
жизненного цикла?
Сформулировать такую особенность однозначно в виде краткого и четкого определения,
наверное, было бы затруднительно. Можно, однако, высказать по этому поводу несколько
тезисов. На роль единого хранилища информации вполне могла бы, допустим, претендовать
и PDM-система, если таковая вообще функционирует на предприятии. Она, по сути,
и является хранилищем информации о составе любого изделия и его возможных конфигурациях.
Вместе с тем, даже если PDM-система используется, с моей точки зрения не следует
перенасыщать ее информацией, особенно не слишком характерной для ее применения.
А это иногда имеет место на практике. Например, если у нас есть нормально работающая
система сервисного обслуживания, нам нет никакой необходимости "качать"
информацию обо всех сервисных случаях в PDM-систему. В рамках единой интегрированной
системы мы и так можем, к примеру, получить всю статистику отказов. Где-то информация
о конструкторском или производственном составе изделия может храниться в ERP-системе,
а где-то для этой цели используется продукт класса PDM. Здесь, с моей точки
зрения, нет четких ориентиров, и в принципе, мне кажется, тут скорее целесообразно
комбинировать различные продукты. Например, у нас в ОАО "ПО Красноярский
завод комбайнов" производственный состав изделия хранится в ERP-системе
SSA ERP Baan. Более того, при подготовке этого решения к эксплуатации в него
были практически вручную введены и до сих пор ведутся данные о конструкторском
и производственном составе всей находящейся в производстве продукции. При этом
состав изделия по новым моделям комбайнов, которые проектируются или находятся
в освоении, мы стараемся поддерживать в рамках PDM-системы SmartTeam, которая
успешно внедряется в инженерных службах предприятия.
С другой стороны, в случае серьезного и активного использования в процессе
ИТ-поддержки производственной деятельности аналитических процедур (а такие сценарии
на практике вполне могут возникать) можно было бы избрать в качестве источника
хранения информации одну систему. Ту же PDM, например. Аналитика, как известно,
в большей степени предполагает существование единого хранилища. Однако на практике
я таких ситуаций пока не встречал, и даже во многих известных мне на сегодня
зарубежных PLM-проектах подобные функции также распределяются между различными
компонентами инфраструктуры бизнес-приложений.
Что касается горизонтальной информационной интеграции между различными продуктами, то она безусловно должна существовать. Если, к примеру, CRM-система у нас замыкается на сервис, то информация из нее может (и должна) поступать в ERP- или PDM-систему. Если мы поставляем какой-либо компонент для нашего изделия и соответственно все операции проводим через систему поддержки логистики, то нужная нам для поддержки жизненного цикла изделия информация все равно осядет в ERP-системе, так как она является ядром ИТ-поддержки оперативной деятельности. Вообще среди всех продуктов, имеющих отношение к поддержке жизненного цикла, мне кажется, можно было бы выделить системы ERP и PDM. Какой-то специфической интеграции систем, выполняемой исключительно под задачи PLM, я бы, наверное, не выделял. Необходимо также подчеркнуть, что эффект от подобной интеграции достигается, конечно, лишь тогда, когда адекватным образом выстроены бизнес-процессы.
Раз уж вы упомянули бизнес-процессы, интересно было бы узнать, какие организационные мероприятия в области построения бизнеса как такового в наибольшей степени влияют на эффективность практического использования концепции управления жизненным циклом на предприятии.
Как это ни банально звучит, прежде всего работу предприятия необходимо ориентировать на управление жизненным циклом продукции. Направлений деятельности может быть очень много. Их даже трудно классифицировать и рекомендовать какие-либо из них в первую очередь. Лично я среди конкретных мероприятий для производственных компаний (и особенно организаций, объединяющих несколько таких структур) выделил бы создание единого классификатора и каталогов нормативно-справочной информации. Для каждой номенклатурной позиции в пределах всей компании, какую разветвленную структуру она ни имела бы, должен быть единый код.
Отсутствие единой классификации приводит к тому, что у нас нет инструмента
и базы для сопоставления одних и тех же характеристик или операций. При этом
мы теряем контроль за целостностью данных, и ни о каком управлении жизненным
циклом продукции не может быть и речи. Вместе с тем такой справочник не создается
за один день. Когда на Красноярском заводе комбайнов технология PLM начала приобретать
реальные очертания, там была сделана, я считаю, титаническая работа по полному
восстановлению состава всех производственных изделий, в также всех технологических
маршрутов. Такая работа, насколько мне известно, проведена далеко не на всех
предприятиях авиастроения, а уж в производстве сельскохозяйственной техники
и подавно. Вместе с тем была сформирована единая нормативно-справочная информация.
Это, как я в очередной раз убедился, является краеугольным элементом для последующего
внедрения идеологии PLM.
Следующим важнейшим элементом организационной работы является выстраивание
бизнес-процессов, соответствующих концепции управления жизненным циклом. В России
этот вопрос стоит особенно остро, потому что PLM интересен прежде всего в машиностроении,
и именно в данной отрасли у нас во многом сохранилась старая советская традиция
чисто функционального управления. К сожалению, касается эта проблема и нашего
холдинга. Конструкторы, сдав чертежи в производство, заканчивают свою работу.
Когда я задаю конструкторскому бюро вопрос о том, с каким конкретным составом
выпущено спроектированное изделие на испытание, оказывается, что там об этом
не знают. Они не контролировали, какие изменения вносились в это изделие в процессе
технологической подготовки и при производстве. Те же недостатки чисто функционального
подхода проявляются и далее вплоть до этапа послепродажной поддержки. Функциональный
подход имеет место не только на верхнем уровне управления, он укоренился весьма
глубоко.
Для того чтобы концепция управления жизненным циклом заработала в полную силу, в компании должны существовать горизонтальные сквозные бизнес-процесы с многочисленными обратными связями, с распределением полномочий, с описанием функций. При этом должны появиться отдельные позиции сотрудников, отвечающих именно за процесс в целом, который в свою очередь касается деятельности многих функциональных подразделений. На зарубежных предприятиях, осуществляющих управление жизненным циклом, позиция владельца процесса, отвечающего за структуру, состав, стоимость того или иного изделия фактически является обязательной.
В начале беседы, говоря о стадии поддержи жизненного цикла, вы разграничили вопросы применения концепции PLM для сложной машиностроительной продукции и более или менее простых серийных изделий. По-вашему, PLM может быть востребован в обоих случаях? И если так, различается ли имплементация данной идеологии в каждом из них?
Да, PLM может быть востребован в обоих случаях, и его применение в каждом из
них обладает характерными особенностями. В одном случае мы имеем относительно
несложные в техническом отношении изделия, обладающие вместе в тем богатым потенциалом
в отношении замены отдельных компонентов. Спрос на такие продукты, как правило,
может динамично изменяться. В отношении поддержки жизненного цикла таких изделий
мы расставляем акценты следующим образом. Поскольку продукт у нас массовый и
выпускается на рынок, быть может, даже без индивидуальных серийных номеров,
то мы в данном случае скоре всего ориентированы на анализ статистики отказов,
а не на то, как "живет" каждое конкретное изделие после продажи. Зато
для нас важен контроль производства того изделия, которое мы в данный момент
выпускаем. Соответственно главная задача - обеспечить оперативный интерфейс
между проектантами, быстро формирующими новый состав изделия, и производством,
которое должно столь же быстро его осваивать. Дальше обратная связь идет уже
не на уровне поддержки отдельных проданных экземпляров, а на уровне маркетинга
- хорошо продается в целом или же плохо. Все это не в последнюю очередь именно
задача управления жизненным циклом изделия и вопрос расстановки тех или иных
акцентов при его внедрении.
Второй сценарий в определенной степени полярен только что представленной ситуации
-- это изготовление технически сложных изделий с длительным циклом производства
и эксплуатации, например, в авиастроении, тяжелом машиностроении и судостроении.
Здесь мы начинаем производство задолго до завершения процесса проектирования.
То есть нам нужен гибкий интерфейс между процессами проектирования, планирования
и производства с многочисленными обратными связями по этой цепи. Кроме того,
важнейшим элементом становится этап самого производства, поскольку в тяжелом
машиностроении то или иное изделие почти всегда представляет собой штучный товар
и нас интересует каждый произведенный экземпляр. Все элементы входят в изделие
по номеру, с возможностью отслеживания технологии изготовления, поставщика,
даты поставки и пр. Кроме того, на этапе эксплуатации приходится много дела
иметь с номерами отдельных деталей узлов и агрегатов, отслеживая ремонты, плановые
замены и т. д.
В информационном плане акцент во втором случае сильно смещается с уровня проектирования
на последующие этапы. При первом же сценарии информационное наполнение, необходимое
для адекватной поддержки жизненного цикла, скорее равномерное, если не сказать,
что оно вообще может быть смещено в строну проектирования.