Недавно Пол Хармон (BPTrends) опубликовал интересную подборку статей, в которых обсуждалась тема взаимодействия ERP и BPM. Стоит отметить, что несмотря на то, что эти обсуждения появились в прессе с того самого момента, когда появились BPM-системы, вопрос и по сей день остается открытым, и однозначного мнения на этот счет нет. Во многом эта тема обязана своей актуальностью тем, что все ERP (или платформенные) вендоры уже включили BPM в свои пакеты предложений, тем самым внеся неразбериху в сознание тех, кто до сих пор для себя четко не уяснил, что же такое BPM, для чего нужны BPM системы и чем они отличаются от учетных систем, таких как ERP или CRM. BPTrends неоднократно обращался к этой теме, и в этом обзоре Пол Хармон оглядывается на десятилетие назад, крупными штрихами обозначив основные «milestones» развития ERP систем параллельно с BPMS (Хармон пометил, что в этой теме он объединил в понятии ERP и CRM, и SCM и другие подобные системы).

(Хармон приводит все публикации, затрагивающие тему ERP. В этот обзор включены те, которые затрагивают одновременно ERP и BPMS)

Обратившись к ранним 80-м прошлого столетия, Хармон напоминает, что в то время многие крупные компании разрабатывали свои собственные приложения, большинство из которых были узкоспециализированными (например, отдельно ПО для продаж, для учета и т.д.) и не предусматривали обмена данными.  В 90-х, с движением в сторону клиент-серверных приложений, крупные компании, подобные Oracle или SAP создали наборы приложений, которые использовали уже единую базу данных, и предназначались для широкого использования внутри всей компании. К концу 90-х многие компании начали отказываться от собственных разобщенных приложений, применяя у себя программное обеспечение от крупных софтверных производителей (так называемые ERP системы).

В то же самое время Том Дэвенпорт написал книгу «Mission Critical: Realizing the Promise of Enterprise Systems», в которой он представлял ERP как способ стандартизации процессов в компании. ERP вендоры так же утверждали, что их системы поддерживают все процессы компании, хотя на самом деле явной поддержки процессов в них не было. Надежды на то, что ERP будут поддерживать процессы различных компаний обернулись для многих из них кошмаром и дорогостоящими неудачами. Многие компании продолжают использовать ERP системы, но они испытывают трудности в применении собственных уникальных процессов, которые должны обеспечивать им конкурентное преимущество. Какое-то время те, кто выступал в поддержку ERP систем и те, кто ратовал за создание уникальных процессов для получения конкурентных преимуществ, были в явной оппозиции друг к другу. Но в начале 2000-х появилась идея использовать интернет протоколы для создания систем управления бизнес-процессами (BPMS). Создание модели процесса и перевод ее в исполняемый код дали, наконец, компаниям то, что они долгое время надеялись получить от клиент-серверных ERP систем.

В 2003-2005 годах, когда интерес к BPMS начал расти, ведущие ERP вендоры начали задумываться о реинжиниринге своих систем с тем, чтобы они отвечали идеологии BPMS. Этот процесс в Oracle и SAP сейчас идет полным ходом, хотя сделать это не так-то быстро.  Многие считают, что борьба развивается между теми, кто предоставляет отдельные BPM продукты (например, IBM) и теми, кто ищет способы включить BPMS функциональность в ERP системы. Кто победит в этом споре – не известно, но, скорее всего, те, кто уже является клиентами SAP или Oracle, не откажутся от использования их ПО, и будут приобретать новые версии с элементами BPMS. Этот процесс, несомненно, займет десятилетия, но в любом случае, гораздо проще создавать, адаптировать и модифицировать mySAP (Netweaver), чем старые приложения SAP, так что тенденция все же к ускорению.

Статья ERP, CRM, and BPM, опубликованная в октябре 2005 года – одна из первых ласточек – предвестников будущих дебатов. В это время рынок программного обеспечения в большей доле принадлежал именно ERP системам, и именно крупные ERP вендоры обещали единственно верный путь к всеобщему информационному счастью. Мечта получить «все в одном флаконе» настолько прочно поразила умы и сердца пользователей, что BPMS стали возмутителями спокойствия не только в рядах ERP вендоров (как потенциальные конкуренты), но и в сердцах потребителей. Внедрение ERP, которое длилось годами, съедало огромное количество ресурсов, казалось пределом, за которым уже не о чем будет беспокоиться… и тут появились процессы, которыми надо не просто управлять, а управлять быстро, качественно и – главное – постоянно!

В статье «ERP, CRM and BPM» Пол Хармон остановился на том, как BPM системы могут сделать существующие ERP и CRM системы более гибкими и полезными. Хармон разделил тех, кто потенциально заинтересован в применении BPM систем, на две группы. Первая – это те, кто уверен, что при помощи BPMS надо создавать абсолютно новую систему, которая будет более гибкой, чем существующие пакетные приложения, такие как SAP или Oracle. Другая группа – это те, кто склоняется к использованию BPMS для того, чтобы управлять уже имеющимися приложениями. Налицо типичный для любых новых технологий конфликт целей. Но Хармон тут же отмечает, что ERP вендоры вкладываются в разработку собственных BPM компонент, планируя включать их в пакет предложений. У SAP есть NetWeaver, Oracle представил BPEL Process Manager, у Microsoft есть BizTalk. И каждый из этих вендоров спешит представить наиболее гибкие способы связать свои модули и приложения в процессы. Но в это время пакетные вендоры предлагали создавать процессные диаграммы, к примеру, в VISIO, с тем, чтобы иметь наглядное представление (в картинках) о том, как должна работать организация. Понятно, что с появлением BPM систем клиенты ERP вендоров вправе были ожидать и от своих поставщиков, чтобы эти диаграммы были как-то связаны с модулями системы. То же можно было сказать и о бизнес-правилах, которые в ERP системах были жестко описаны в каждом модуле.

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

В апреле 2006 года Пол Хармон снова обратился к этой теме. В статье A Single Instance of ERP он приводит пример предприятия, имеющего распределенные офисы продаж по всему миру. Во всех филиалах установлена одна и та же ERP система, но специфика продаж в разных филиалах различна, что привело к тому, что ERP система в них настроена по-разному. К тому же, одни филиалы продают промышленное оборудование, другие – мелкие товары. То есть различаются и процессы продаж (и не только они). Таким образом, количество филиалов, умноженное на количество различаемых процессов в несколько раз увеличивает различия и, следовательно, увеличивает стоимость поддержки и обслуживания программного обеспечения. Добавьте сюда необходимость адаптации всего этого многообразия к новым релизам вендора, и вы убедитесь, что ERP обойдется вам в копеечку.

Поставив перед собой задачу снижения затрат на содержание системы, компания приняла решение стандартизировать процессы филиалов. Но как это сделать? Сделать это в ERP системе не представляется возможным из-за непомерной стоимости таких работ. Да и требуемой гибкости достичь не удастся, поэтому филиалам придется подстраиваться под стандартные процессы. А это не вызывает восторга у менеджеров филиалов. Единственно возможным решением для компании стало внедрение BPM системы, которая позволила связать процессы филиалов с ERP системой, перенеся всю настройку процессов в BPMS. И, несмотря на то, что у компании были серьезные опасения относительно BPMS, поскольку технологии на тот момент были еще слишком новыми. Но альтернативой было только «размножение» ERP, что и обусловило выбор в пользу BPMS.

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

Что же представляют из себя эти «более интересные задачи»? Какие цели должна преследовать организация, которая действительно стремится получить конкурентное преимущество и выделиться на рынке? На эту тему в мае 2009 Хармон опубликовал интереснейшую статью Porter, ERP and BPMS. Как видно из названия, автор обращается к автору теории конкурентных преимуществ Майклу Портеру и к его книге «Competitive Advantage», а дальше очень метко связывает теорию Портера с практикой применения автоматизированных систем.

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

Операционная эффективность, в терминах Портера, достигается за счет достижения лучших результатов в выполнении каждого отдельного действия. Для этого многие компании тратят значительные средства и силы на изучение и приобретение так называемых «best practices» . Но Портер не считает это эффективной стратегией. Стремясь использовать лучшие практики, применяемые в других компаниях, компания всего лишь бежит с ними на одной дорожке, отставая или догоняя, но все же на одной. При этом то же самое будут делать и конкуренты. Поэтому применение лучших практик – это бесконечный марафон, где все участники всегда будут находиться в примерно одинаковых условиях, а затраты на копирование все лучших и лучших практик будут постоянно расти. По словам Портера, некоторые компании могут добиться успеха за счет повышения операционной эффективности, но с каждым днем им будет все труднее это делать.

Другой путь – это стратегическое позиционирование. По определению Портера, стратегическое позиционирование «означает делать то, что не делают конкуренты либо делать то же самое, но по-другому». Он продолжает, что «операционная эффективность достигается за счет блестящего исполнения отдельных действий, тогда как стратегия – это комбинирование всех действий».  Хармон обобщает мысль Портера, резюмируя, что этот путь подразумевает, что все процессы работают в цепочке создания ценности, в соответствии с поставленными целями. С точки зрения конкуренции, соперники могут копировать отдельные действия, но вряд ли им удастся воспроизвести всю цепочку так, и еще сложнее им будет воспроизвести всю дисциплину управления.

Дальше Пол Хармон обращается от теории к практике. Первые попытки воплотить идеи Портера в жизнь были предприняты в 90-х годах прошлого столетия и представляли собой не что иное, как Business Process Reengineering. Идеологи реинжиниринга предлагали интегрировать бизнес-процессы с ИТ системами в контексте цепочки создания ценности. Но в то время реализация этих идей требовала значительных инвестиций в софтверную разработку. Поэтому многие крупные компании к концу 90-х остановили свой выбор на ERP системах, которые предлагали использовать клиент-серверные приложения, связанные одной реляционной базой данных. Но, несмотря на то, что эти системы решали многие задачи, они все же не могли решить проблемы, обозначенные Портером. Ведь, в сущности, ERP – это те самые «лучшие практики»,  которые относятся к операционной эффективности, и не связаны с цепочкой создания ценности. Некоторые компании пошли по пути «подгонки» ERP систем под собственные нужды, но этот путь делает системы дорогостоящими и сложно модифицируемыми.

Ситуация усугубилась в начале 2000-х с приходом dot.com технологий. Большинство компаний в настоящее время предпочитают использовать интернет-технологии в своем бизнесе (может быть, не все так преуспели в этом, как, скажем, Amazon.com, но многие к этому стремятся).  И вот тут компании, которые «привязаны» к своим ERP системам, начинают испытывать существенные трудности, поскольку им крайне сложно изменить бизнес-модель без переделки системы.

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

Дальше Хармон предлагает статью Тома Беллинсона (Tom Bellinson) The ERP Software Promise («Обещания ERP»), вышедшую в июле 2009 . Том Беллинсон, являясь ярым приверженцем ERP систем, не соглашается с Хармоном в том, что перспектива ERP – это интеграция с BPMS. Основным аргументом против он приводит то, что репозиторий BPM-систем не является центральным хранилищем данных, и что для создание единой модели требуется интеграция. А, по утверждению Тома, то, что надо интегрировать, никогда не может быть таким же эффективным, как целое.  И что BPMS, несмотря на то, что механизмы интеграции у них достаточно сильные, все же остается еще одной точкой интеграции, которой надо управлять. Все, что, по его мнению, необходимо ERP – это упрощение процедуры согласования изменений процессов.

В качестве модели ERP будущего, он приводит следующую архитектуру:

 

И дальше приводит в пример SAP, который в настоящее время предпринимает шаги по разделению своих приложений, и делает акцент на разработке NetWeaver – ВРМ приложения. Однако здесь Беллинсон явно надевает розовые очки, потому что один NetWeaver не в состоянии решить все проблемы интеграции, поскольку для этого потребуется серьезная доработка остальных модулей. Ну и факт, который констатирует Беллинсон – это стоимость продуктов SAP.

При этом вера Беллинсона в торжество единства непоколебима. Признавая, что переделки существующих ERP систем займут годы, он допускает право BPMS на временное существование. Но в светлом будущем, по его мнению, все же победит единая система.

Точку в этом споре ставить рано, и наиболее вероятно, что она не будет поставлена никогда. Поэтому я ставлю многоточие и будем следить за развитием событий…

 =WJ

Комментарии