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

 

Россия на пороге PLM

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

Николай Нырков

Говоря о средствах автоматизации, оставим за рамками минимальный джентльменский набор: электронную почту, офисные пакеты, ПО для бухучета. На вооружении у современной инжиниринговой компании находятся сегодня инструменты двух видов: системы планирования ресурсов предприятия (Enterprise Resource Planning, ERP), предназначенные для автоматизации управления производством, финансово-хозяйственной деятельностью предприятия; решения для управления жизненным циклом изделия (Product Lifecycle Management, PLM), позволяющие комплексно решать задачи автоматизации инженерной деятельности.

Такое функциональное разделение сложилось в ходе долгого развития ИТ. С одной стороны, процесс начался с мэйнфреймов, на которых решались ключевые ERP-задачи, а с другой — со специализированных графических станций, на которых с 80-х годов работали первые серьезные системы автоматизированного проектирования (Computer-Aided Design, CAD), ставшие впоследствии основой PLM. Затем, в 90-х, наступило время массового распространения локальных сетей и персональных компьютеров, которое привело к рождению массовых систем CAD и первых систем PLM. Сегодня мы наблюдаем масштабное проникновение глобальных сетей и развитие облаков, что открывает в глобализованном мире гигантские возможности и, безусловно, окажет влияние и на интересующий нас вопрос про одну ИТ-систему.

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

 

PLM как осознанная необходимость

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

Марина Аншина

Среди тенденций последних лет нельзя не отметить развитие систем управления бизнес-процессами (Business Process Management, BPM), в том или ином виде реализующих концепцию управления организацией на основе процессного подхода. Этот интерес вызван главным образом естественным ростом компаний — в интенсивно развивающихся организациях управленцы, преодолев определенный порог, начинают задумываться над тем, чтобы бизнес-процессы уже шли не «по понятиям» и не вручную, а по каким-то четко определенным правилам и автоматически. Рано или поздно все компании приходят к пониманию необходимости BPM.

Таким образом, сегодня имеется целый класс систем BPM и методик управления организацией. В каждой из предметных областей деятельности организации есть бизнес-процессы, которыми нужно управлять и которые нужно оптимизировать, поэтому неудивительно, что современные системы PLM и ERP, как правило, в том или ином виде содержат функционал BPM, в частности, позволяют автоматизировать процессы согласования.

Что же сегодня в этих условиях происходит с самими инжиниринговыми компаниями? Выделим несколько типов компаний.

«Традиционные» компании. В основном это большие по размеру (свыше 500 сотрудников) нерыночные организации, обслуживающие госзаказ. Циклы проектирования и производства здесь разделены во времени и организационно. Такие компании ориентируются на государственные стандарты. Разделение функций ERP и PLM тут происходит вполне естественно, в силу разрыва в процессах, в силу сложности и разнообразности задач и в силу консервативности. И у них есть деньги и на кастомизацию, и на интеграцию.

Компании, работающие по схеме «Сборка на заказ». Это компании рыночного типа различных масштабов. С одной стороны, им нужно максимально угодить потребителю по качеству и срокам, а с другой — снизить издержки. Циклы проектирования и производства здесь тоже чаще всего разделены, но есть жизненно важное отличие — необходимость быстрой постановки новых/модернизированных изделий на производство. В контексте нашего вопроса можно отметить потребность работы с конфигурируемыми изделиями, а также необходимость просчета стоимости будущего изделия на ранних этапах и с учетом сложной логистики. В таких компаниях традиционное разделение задач на PLM и ERP имеется, но им уже нужно, чтобы эти задачи решались либо в единой системе, либо была очень качественно выполнена интеграция разных систем. Если это крупная компания, она может позволить себе или «тяжелую» комплексную систему, или интеграцию нескольких систем. Но небольшие предприятия себе такого позволить уже не могут.

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

Компании, которые концентрируются на маркетинге и работают по схеме «Проектирование и размещение производства серий изделий на стороне». Ключевое отличие в том, что они изначально работают в среде глобализованных логистических цепочек и даже глобализованного проектирования. И выстраивание этих цепочек, начиная с самых ранних этапов зарождения концепта изделия, оценка их стоимости (быстрая и многократная, на различных этапах) и последующий контроль их исполнения — важнейший для них вопрос. Для автоматизации такой деятельности в идеале нужна глобальная система PLM/ERP с глобальной же подсистемой управления основными данными (Master Data Management, MDM). К сожалению, такой мегасистемы на рынке пока нет.

Таким образом, мы видим, что есть масса инжиниринговых компаний, в основном небольших, которым «традиционные» решения в области PLM и ERP не подходят. Есть также реальная потребность в сквозном, простом в освоении и не требующем доработок, недорогом и простом в обслуживании решении.

Все это не новость, и серьезные производители PLM и ERP заметили этот сегмент спроса, однако больших успехов на данной ниве не снискали. Почему? Главным образом в силу «тяжелого» методического и технического «наследия», а также слишком консервативной политики в области маркетинга ПО и сопутствующих услуг. Попытки сделать действительно сквозное решение наблюдались пока только у производителей ERP —например, у SAP и, отчасти, у «1С».

 

Синдром глобализма в ИТ

Попытки создать универсальную ИТ-систему, которая охватывала бы все аспекты управленческой и производственной деятельности, предпринимались неоднократно и, в частности, в сфере управления ресурсами предприятий. Казалось бы, чего еще можно пожелать: есть и учет, есть и планирование — но практика показала, что внедрение систем ERP настолько трудоемко (затраты на внедрение ERP многократно превосходят затраты на лицензии на ПО), что в полном объеме их функционал использовать большинству компаний просто не под силу. К тому же внедрение ERP не происходит в полном ИТ-вакууме — на момент принятия решения о развертывании такой системы в организации, как правило, уже имеются одна или несколько аналогичных систем, активно используются электронные таблицы, почта и т. п. Часто целесообразность ухода от локальных систем вообще сомнительна, но компания все же решает тратить ресурсы на автоматизацию с помощью централизованной ERP, например, еще не охваченных участков.

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

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

— Юлия Вагнер (julia@b-k.ru), начальник отдела технической поддержки компании «Бизнес-Консоль» (Москва).

 

Теперь вернемся к BPM. Следует отметить, что и при разработке, и при внедрении информационных систем, BPM часто оставляют на потом — всегда хочется создать (внедрить) в первую очередь предметный функционал. Но «потом» основательно заняться управлением бизнес-процесами так и не получается. В результате реальное управление процессами подменяется массой статических соглашений и решений (версии, состояния объектов, права доступа к ним и др.), либо решений, существующих в стороне от «предметной» системы и не облегчающих, а только затрудняющих работу пользователей (например, отдельно стоящие средства управления документооборотом или управления проектами).Этим грешат даже разработчики стандартов, описывая динамические по природе вещи статикой. В частности, можно упомянуть известную в сфере инжиниринга проблему конструкторских/технологических изменений. Придумали статичные «версии» объектов и успокоились. А ведь изменение — это и есть процесс.

Таким образом, получается, что для придания инжиниринговым компаниям динамики современной жизни требуется BPM и как подход, и как «движок» автоматизации.

Николай Нырков (nyrkov@ascon.ru) — руководитель проектов разработки информационных систем компании «АСКОН» (Санкт-Петербург).