BPM в роли шерифа

Рассел Кезьер

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

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

Вслед за негативом приходит взвешенная оценка. В начале этого года я был на серьезной ИТ-конференции, на которой руководитель крупной компании, занимающейся CMDB (Configuration Management Database), был в явном восторге от того, что он видит надвигающийся хаос. Он чувствует, что движение к компонентно-ориентированным композитным приложениям откроет «ящик Пандоры» с легионом своенравных основанных на веб-сервисах приложений. Плохо продуманные смешанные (mash-up) приложения – не слишком приятное зрелище, и он предвкушает, как его компания будет зарабатывать деньги, помогая наводить в этом порядок.

Быть может он прав, но есть надежда, что не все так ужасно. Без сомнения тоталитарные ERP (Enterprise Resource Planning) системы вчерашнего дня не были нацелены на нужды быстро растущей глобальной экономики и на изменчивую и непостоянную, но компьютерно-грамотную рабочую силу и клиентскую базу. Ни один из тех, кто прошел через внедрение ERP для нужд управления персоналом, бухгалтерии или управления отношениями с заказчиками, в жизни не пожелал бы снова через это пройти. Монолитные компьютерные приложения, изменять которые под силу только программистам, обещают сделать все, но в конечном итоге превращаются в нечто застывшее, похороненное внутри бизнес-подразделения. И хотя они способны масштабироваться на тысячи пользователей и, как правило, надежны и безопасны, в то же время выясняется, что такой способ автоматизации бизнеса является препятствием для его роста.

Без сомнения, стать ориентированным на потребителя и на процессное управление легче с компонентами, чем с фиксированными корпоративными приложениями, которые трудно модернизировать и изменять. В комбинации SOA (Service Oriented Architecture) и  BPM (Business Process Management) многие видят возможность сделать резкий, революционный скачок через ERP. Даже тяжеловесы рынка корпоративных приложений, такие как Oracle и SAP, ставят на это и инвестируют в Fusion и NetWeaver, чтобы застолбить для себя в этом новом мире такое же место, что и в старом.

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

У «ковбоев» SOA – собственные проблемы. Инновации и гибкость – это хорошо, но «стрельба от бедра» может привести к непредвиденным последствиям. Перспектива карьерных проблем из-за «стрельбы по своим» в загоне SOA способна охладить любой энтузиазм.

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

Модели управления SOA – SOA Governance (см. определение Википедии: https://en.wikipedia.org/wiki/SOA_Governance) сейчас только зарождаются. Искушение просто применить традиционные модели управления ИТ к миру композитных приложений SOA очевидно не имеет смысла и работать не будет. Подход, вытекающий из потребности в привычном управлении жизненным циклом, способен заморозить непрерывные усовершенствования; вновь мы видим традиционный «водопад» (waterfall), который становится тормозом, делающим невозможной быструю адаптацию, ограничивающим инновации и сбивающим с толку участников.

Одно из возможных решений – прямо у нас под носом. BPM сейчас признан в качестве необходимого элемента SOA стратегии. Используя BPM немного нестандартно, можно коротким путем прийти к приемлемому варианту управления SOA. Средствами BPM можно реализовать процесс, в рамках которого бизнес-заказчики будут формировать запросы на новые композитные приложения SOA.

Но по-настоящему большие перспективы откроются, если BPM использовать для управления SOA, когда ИТ берет его в свои руки и использует для управления работами, измерения уровня сервиса, составления отчетов по соответствию ITIL, обработки исключений и инцидентов и настройки производительности SOA. Вне зависимости от того, создается композитное приложение внутри BPM-системы (не все они являются для этого идеальными средствами), «процесс» создания композитного приложения SOA поддается более эффективному контролю и управлению, чем традиционные приложения MVC (model-view-controller).

BPM-системы с сильной интеграционной составляющей могут контролировать ESB (Enterprise Service Bus) и расширить базовые возможности обмена сообщениями, мониторинга производительности и транзакций, просмотра репозитария и UDDI-интеграции, добавляя к ним SLA (Service Level Agreements) и среду совместной работы, которая отслеживает на каком основании приложение было создано, какая польза для бизнеса от него ожидалась и окупилось ли оно, а также обеспечивает следование корпоративной политике, требованиям безопасности и регламентов. Использование для этих целей BPM имеет смысл даже там, где имеются традиционные системы мониторинга.

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

Перевод BPMS.RU