Высококонкурентная среда для крупнейших западных банков уже очень давно требовала технологичного подхода к построению бизнес-процессов. В последние несколько лет с решением этой задачи тесно ассоциируется класс ИТ-инструментария, называемый BPM-системами. Он довольно новый, и практика его применения пока сопряжена с целым рядом нюансов. Об этом рассказывает директор отдела информационных технологий инвестиционного бизнеса Deutsche Bank в России, член Клуба делового общения банковских ИТ-директоров CIOBank Михаил Хасин.
Intelligent Enterprise: О системах класса BPM на российском рынке активно заговорили года два назад, и с тех пор имеющиеся публикации так до конца и не ответили на вопрос, какие все-таки задачи решаются этими системами. О чем, по-вашему, прежде всего думают корпоративные пользователи, когда рассматривают для себя возможность приобретения подобных продуктов?
Михаил Хасин: Понятие автоматизации бизнес-процессов возникло уже давно. Думаю, всем известно, как важно это для компании. Оптимизация бизнес-процессов, сопровождаемая информационной поддержкой, — это своего рода цикл, состоящий из определенных фаз, которые всегда проходятся в определенной последовательности: от формирования некоего видения новых процессов через дизайн, моделирование и имплементацию. В дальнейшем, контролируя эффективность функционирующих процессов, мы стараемся перейти к улучшенным, и таким образом цикл замыкается.
Для решения этой проблемы традиционно использовались самые разнообразные классы инструментов, и постепенно созрела потребность обеспечивать информационную поддержку всего названного цикла посредством одного продукта, включая глубокий аудит всех событий, связанных с подготовкой и функционированием бизнес-процессов.
Системы BPM явно претендуют на решение этой задачи. Наверное, корпоративных заказчиков привлекает в них ряд преимуществ. Во-первых, они хотят иметь единое приложение, в котором можно очень гибко, удобно и на основе грамотно подготовленной объективной информации управлять изменениями. Это дает возможность сократить процесс реализации данных изменений в разы, что в условиях современного бизнеса просто трудно переоценить.
Далее может стоять другая, весьма часто возникающая задача — выжать из имеющихся процессов максимум производительности. Если мы правильно спроектировали процесс, но он крайне трудоемок (например, обработка сотен тысяч однотипных документов), нужно увеличить скорость его прохождения. Образно говоря, нам удалось выстроить скоростное шоссе, и теперь наша задача — промчаться по определенному участку с максимальной скоростью. Тут нужен хороший движок (engine), что в равной степени касается и автомобиля, и BPM-системы.
Кроме того, BPM — своего рода инструмент контроля деятельности персонала. Мощные возможности аудита процесса, предоставляемые системами данного класса, позволяют всегда знать, где и когда произошло исключение, когда сообщение было поставлено в очередь сотруднику, когда он принял решение и т. д.
В результате всегда можно разобраться с причиной неблагоприятных отклонений: то ли процесс выстроен не оптимально, то ли пользовательский интерфейс недостаточно адекватен для оперативной реакции, то ли сам сотрудник крайне медлителен.
Получается, что BPM — в известном смысле комплексный инструмент, позволяющий решать единую задачу, состоящую из тесно связанных между собой, но все-таки отдельных стадий. Из каких компонентов тогда должно состоять само комплексное решение? И если такой общепринятый набор существует, насколько он принят производителями в качестве стандарта де-факто?
Использование BPM, в моем представлении, включает семь этапов. Речь идет о формировании некоторого видения проблемы — понимания, для чего мы все это затеваем. Затем мы последовательно говорим о дизайне, моделировании, имплементации, мониторинге, оптимизации и реинжиниринге бизнес-процессов.
Эти содержательные этапы BPM-решения должны отражаться и в функциональности программных продуктов. Я говорю «должны», потому что на практике, если мы планируем масштабные проекты, в которых одновременно имеем как сложные бизнес-процессы, так и очень серьезные требования в отношении их производительности, мы отчетливо видим, что пока на рынке очень сложно найти решение, которое бы в полной мере охватывало все семь фаз. Впрочем, я это воспринимаю как некий этап активного развития BPM-систем и практик различными производителями, а также как процесс формирования у пользователей понимания об области их использования. Со временем все будет выровнено, что уже не раз случалось с другими классами многофункциональных корпоративных систем, некогда тоже активно развивавшимися.
Еще один признак недостаточной зрелости — структура рынка предложения. Пока здесь совершенно не та ситуация, которая уже сложилась, скажем, на очень консервативном и устоявшемся рынке баз данных. На нем мы который год наблюдаем постоянное лидерство трех компаний, в то время как на рынке BPM неких условных лидеров, конечно, больше. Но и они пока, похоже, не вполне определились, какие именно ниши занимают. Мы, как потребители таких технологий, это хорошо видим.
Таким образом, проводя соответствующие проекты, мы чаще вынуждены интегрировать несколько продуктов. Есть у нас своего рода основные системы — это Intalio, jBPM и Tibco iProcess Suite. Но даже ими внутренний ИТ-ландшафт не ограничен. Иногда приходится использовать и другие системы.
С этой точки зрения интересно также поговорить о принципах выбора продуктов класса BPM: не технологический, а организационный ракурс использования систем той или иной категории всегда был интересен ИТ-руководителям.
У нас процесс выбора упорядочен, хотя вряд ли уникален в отношении BPM-систем. Во-первых, ориентируясь на уже упомянутый тезис о незрелости рынка, мы (по крайней мере в сегодняшней ситуации) изначально допускаем, что составлять собственное BPM-решение под конкретную задачу придется из нескольких продуктов. У нас есть Архитектурный комитет (Technology Architecture Board), где проект должен представить предлагаемое решение. Когда описывается конкретная задача, следует указать, можно ли справиться с ней за счет имеющихся решений (и тогда банк, как правило, договаривается о приобретении дополнительных лицензий) либо в силу специфических причин необходимо выбрать продукт, еще ни разу не применявшийся в банке. Последняя ситуация периодически возникает, хотя мы уже успели поработать со многими продуктами.
Хочу подчеркнуть, что организационные возможности внедрения BPMS зависят также от одной характерной их особенности. Дело в том, что эти продукты — средство разработки в широком смысле, если под термином «разработка» понимать не использование языка программирования, а некий комплексный инструментарий, позволяющий конструировать необходимый функционал на всех этапах — от дизайна и моделей до настройки BPM-движка под конкретную задачу. Занимаются всем этим очень разные специалисты. Видение и дизайн — задача бизнес-специалистов, моделирование проводят аналитики, а настройка движка остается техническим сотрудникам. Но при этом каждая категория заданий дается профессионалам в своей сфере «программирования», а не экспертам или внутренним консультантам, дающим рекомендации в абсолютно вольной форме.
Например, в Deutsche Bank создан центр компетенции по BPM-решениям, где как раз дизайном бизнес-процессов занимаются специально подготовленные и обученные бизнес-специалисты, которые предельно технологично могут справиться со своей частью задачи и затем столь же технологично передать ее на этап моделирования.
В случае BPM, для которого, как, может быть, ни для какого другого корпоративного решения, характерно вовлечение специалистов очень широкого спектра в единую методологию, сознание таких центров компетенции чрезвычайно важно. Хотя в то же время не могу сказать, что централизация в вопросе разработки BPM-систем в банке доведена до некоего абсолюта.
Поговорив об организационных вопросах внедрения BPM, хотелось бы немного детализировать и технические нюансы их применения. В отсутствие зрелости они наверняка имеют место, и о них, пожалуй, в первую очередь должны говорить те корпоративные заказчики, которые уже попробовали самые разные сценарии применения данных систем.
Такие нюансы существуют, и их немало. Могу выделить некоторые, наиболее, с моей точки зрения, заметные и важные. Пока существует некий разрыв между «верхнеуровневым» функционалом BPM-систем (включающим в себя стадию формирования видения, дизайна и моделирования) и стадией имплементации. Особенно заметен становится данный разрыв, когда остро встает задача обеспечения производительности. Или, если говорить в терминах бизнеса, когда мы, скажем, переходим от ситуации обработки десятков тысяч платежей к процессингу сотен тысяч. Отчасти это объективная проблема, поскольку BPM-движок стоит в самом конце цепочки информационной поддержки функционирующих бизнес-процессов. Ему трудно полностью подстроиться под то, что специалисты намоделировали на верхнем уровне, включая сложные ветвления процессов, потенциальные узкие места по производительности, возможные исключения и т. д.
Но, так или иначе, это проблема, и ее легче решать, имея движок с открытым кодом (как, например, jBPM) или даже разрабатывая собственный. В дальнейшем мы выходим на проблемы интеграции, о которых я говорил выше, а также на задачи управления изменениями бизнес-процессов, которые в данном случае становится труднее решить, не замечая «швов» между отдельными компонентами инструментария.
Вторая заметная и общая для всех инструментов проблема заключается в неразвитости возможностей построения пользовательского интерфейса. Бизнес-процесс, как известно, состоит из отдельных задач, и в современных BPM-системах каждая из них привязывается к отдельной экранной форме. На практике же, когда мы работаем со сложным процессом, часто необходимо либо иметь один экран на несколько задач, либо ассоциировать экранную форму не только с решением задачи, но и, скажем, с выборкой данных из других систем. Стандартными средствами BPM сейчас решать все это достаточно сложно. Впрочем, я также отношу эту проблему к классу «болезней роста». Сейчас внимание к отдельным компонентам интегрированного BPM-решения у производителей неравномерное — основной фокус они пока делают на дизайне и моделировании, а вопросы построения User Interface (UI) явно отходят на второй план. Положение осложняется еще и тем, что современный пользователь, как правило, уже очень привередлив к качеству интерфейса и не всегда готов снижать планку собственных потребностей. Да и разработчики прекрасно знают возможности действительно мощных и развитых средств создания UI, и для них внутренний инструмент BPM данного класса, прямо скажем, кажется довольно убогим.
И наконец, третий нюанс, который бы я хотел выделить, также непосредственно касается разработчиков. Средства отладки (которые опять-таки в ведущих инструментах разработки уже давно функционально развиты и эргономичны) в BPM-системах тоже явно оставляют желать лучшего. На уровне конечного результата это выливается в следующее противоречие. Нередко случается, что на уровне сквозной разработки автоматизируемых бизнес-процессов действительно возникает неочевидная проблема. Справиться с ней бывает непросто именно из-за неразвитости средств отладки.
Заканчивая разговор о функциональных характеристиках BPM-систем, хотелось бы задать один простой вопрос. К какому классу прикладного программного обеспечения вы отнесли бы BPM-инструментарий — к функциональным системам или интеграционным продуктам?
Как было вкратце уже упомянуто выше, в ходе реализации полного цикла управления бизнес-процессами часто встречаются ситуации, когда нужно выбрать данные из других систем, а может быть, впоследствии положить обработанные данные обратно. В этом смысле, наверное, можно сказать, что BPM-системы выполняют функции информационной интеграции. Хотя ни сейчас, ни даже в будущем, когда уровень их развития явно повысится, нельзя поставить их рядом с мощными интеграционными платформами, которые уже теперь, как правило, есть в арсенале крупных мировых производителей корпоративного ПО.
Функциональная их роль, мне кажется, просматривается более четко, поскольку в случаях, когда удается подобрать адекватный инструмент — от дизайна до движка, можно говорить о том, что BPMS берут на себя полную функциональную поддержку бизнес-процесса. Те ИТ-системы, которые, конечно же, применялись для автоматизации данного процесса ранее, очень часто выводятся из эксплуатации практически полностью. BPMS их заменяют. И думаю, что по мере развития BPM-платформ все это будет наблюдаться еще более явно.
В контексте обсуждения BPM-систем, и особенно англоязычных, часто упоминается целое множество ролей, которые якобы очень тесно связаны с их практическим применением. Среди них такие, например, как Chief process officer, Process architect, Business process owner, Process analyst, Process performer. Это наталкивает на мысль о необходимости некой ревизии взглядов на структуру корпоративного персонала вообще. Что бы вы могли сказать по этому поводу?
Думаю, никаких революционных изменений здесь ожидать не стоит. Классические ролевые позиции новый подход затронуть не должен. Вместе с тем роли, которые были названы (а также некоторые другие), действительно начинают выступать в общей структуре более рельефно. В аббревиатуре BPM ключевым все-таки является слово «процесс». И активности начинают группироваться именно вокруг процессов. С ними же становятся все более связаны и роли тех или иных сотрудников.
BPM-системы все-таки пока явно преобладают в таких отраслях, как банковская, страховая и телекоммуникационная. Несмотря на довольно существенные различия, их можно объединить в некое подмножество, основой принадлежности к которому будет продажа услуг (а не материальных продуктов) и выраженная клиентоориентированность. На российском рынке, где внедрение BPM-систем в основном носит точечный характер, такие индустриальные приоритеты особенно заметны. С чем это, по-вашему, связано?
Подобные объяснения, на мой взгляд, напрямую вытекают из целей, преследуемых при внедрении BPM, о которых мы говорили в самом начале нашей беседы. Если в производственных отраслях при всей важности оптимизации бизнес-процессов многое связано с физическим изготовлением продукции на том или ином оборудовании, то в нашей отрасли фактически сами оптимизированные процессы, а также возможность их быстро изменять, и являются главным рычагом конкурентного преимущества. Тут важность грамотно встроенного в бизнес BPM-решения просто трудно переоценить. То, о чем мы говорили выше, — прямое тому доказательство.
Ориентированность на клиентов, равно как и массовая работа с клиентами, в упомянутых отраслях напрямую связана с постоянно возникающей необходимостью повышать производительность бизнес-процессов, чрезвычайно насыщенных интенсивными потоками унифицированных операций. Зависимость между интенсивностью данных потоков и возможностями задействовать для их обработки человеческий потенциал в современном, все более консолидированном, бизнесе становится все более нелинейной. Иными словами, при повышении данной интенсивности, скажем, в 10 раз, задачу уже ни за что не удастся решить таким же или большим масштабированием числа сотрудников. Я уже и не говорю об эффективности. Таким образом, мы опять приходим к выводу о фактической незаменимости BPM-систем.
BPM как совокупность решений
Дмитрий Пинаев,
исполнительный директор ГК «Современные технологии управления»Автоматизации должны предшествовать диагностика организации, выработка стратегии развития, выявление и устранение проблем в ее бизнес-процессах. Эту работу необходимо провести до внедрения BPM-системы, чтобы правильно выбрать нужную функциональность и впоследствии не тратить ресурсов на ее перенастройку.
Как интегрировать несколько средств, чтобы решить задачу оптимизации бизнес-процессов? Этот вопрос эксперт поднимает в статье не случайно. Наш опыт также показывает, что наилучшим примером реализации стратегически правильного алгоритма внедрения ВРМ-платформы может служить интегрированное решение. Разработчики системы бизнес-моделирования Business Studio и ECM-системы DIRECTUM создали самостоятельный инструментарий подобного типа, сочетающий функции обоих продуктов. Благодаря интеграции средства автоматизации органично встраиваются в цикл управления: на первом этапе в Business Studio проектируется и оптимизируется система управления компании, а ECM-система обеспечивает правильное исполнение спроектированных бизнес-процессов и обратную связь для дальнейшего их совершенствования.
