Формализация, оптимизация и автоматизация банковских бизнес-процессов: время пришло?

Как известно, все говорят прозой, но не все об этом знают… Деятельность любой организации, любого банка – это совокупность проектов и процессов, но еще пару лет назад об этом знали далеко не все банки и организации. А если и знали, то не спешили использовать это знание для улучшения своей деятельности. И даже те банки, которые пытались это сделать, оптимизировали, как правило, узкий круг своих бизнес-задач, часто всего несколько процессов. Но обострение проблем снижения издержек и повышения эффективности, вызванное кризисом, побуждает банки “познавать” свои бизнес-процессы, явно определяя (формализуя) их, а затем и оптимизировать с применением ИТ. Мы попросили участников рынка обсудить проблемы формализации, оптимизации и автоматизации банковских бизнес-процессов

— Какие направления банковского бизнеса более всего нуждаются в формализации и автоматизации своих бизнес-процессов?

Марк Залан: Это, прежде всего, процессы с наибольшей массовостью и повторяемостью (так как автоматизация этих процессов позволит снизить базовую стоимость обеспечения выполнения этих процессов), например, процессы клиентского обслуживания и продаж. А также процессы, где важно следование точно заданному алгоритму действий/принятия решения — например, процесс принятия решения по выдаче кредита.

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

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

Формализация бизнес-процессов, безусловно, интересна. Всегда хочется хорошо понимать, как же действительно все работает. Но главное, чтобы за этапом формализации обязательно следовали реальные действия по оптимизации/автоматизации бизнеспроцесса. Но как показывает практика, в банках очень часто все заканчивается созданием подразделения, которое выполняет работы по актуализации описания бизнес-процессов и все.

— Каковы подходы к формализации банковских бизнес-процессов?

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

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

— ИТ-инструментарий для формализации и оптимизации бизнес-процессов довольно богат: workflow-системы, BPM-платформы с поддержкой полного цикла управления бизнес процессами (от формализации до оптимизации и мониторинга), SOA- и ECM-платформы с BPM-средствами. Может ли банк обойтись единственной системой или платформой?

Как ее выбрать?

Алексей Макеев: На мой взгляд, выбор технологии для создания решения — BPM, или ECM или обе платформы сразу — обусловлен прежде всего спецификой бизнес-процессов, которые нужно автоматизировать. Добавлю лишь, что перед внедрением подобного класса платформ может быть не лишним предварительный этап — внедрение интеграционной шины. Фундамент в виде работающего на шине набора сервисов поможет банку быстрее перейти к автоматизации сквозных бизнес-процессов. Прежде всего, это скажется на скорости создания конкретных решений. При этом архитектура SOA обеспечит максимальное использование технологических достоинств и BPM, и ECM-платформы.

Алексей Матукин: Перед выбором платформы надо внимательно посмотреть на свои ресурсы, на персонал, который будет заниматься поддержкой и развитием платформы: есть ли такие специалисты в банке, способны ли они выполнять данную работу? Надо посмотреть на рынок и оценить количество доступных специалистов, распространенность и открытость технологии данной платформы, чтобы не оказаться ее заложником. Причем надо понимать, что процесс эволюции технологий неизбежен, и однажды платформу всё равно придется поменять. Поэтому если выбор платформы уже произведен, то имеет смысл постараться использовать выбранное решение по максимуму. Что касается конкретной технологии, то наиболее предпочтительны BPM-платформы с поддержкой полного цикла управления бизнес-процессами.

Сергей Орлов: Мы долго использовали workflowсистему Business Mashups (ранее TeamTrack) компании Serena Software, Inc., работали с IBM WebSphere Process Server. Сейчас добавили две BPM-платформы IBM WebSphere Lombardi Edition и Intalio|BPMS. Пока в наших проектах мы не взаимодействуем с системами документооборота, а храним документы в своих хранилищах или в экземпляре процесса (такой функционал имеется в IBM WebSphere Lombardi Edition). Хотя интерфейсы с некоторыми системами документооборота мы уже разработали с расчетом на будущее.

Выбор платформы — это балансирование между стоимостью продукта и его функциональностью. Обе платформы, с которыми мы сейчас работаем, надежны и проверены временем. IBM WebSphere Lombardi Edition — система дорогая, с большим количеством готового встроенного функционала. Intalio|BPMS значительно дешевле, есть opensource версия этого продукта, но и разработка на нем требует больших усилий.

— Встречаются попытки использовать BPMплатформу как прикладную систему, как фронтофис банка. Насколько это перспективно?

Алексей Матукин: Бесперспективно. Можно и на Ferrari участвовать в гонках по пересеченной местности, но куда лучше для этих целей подходит джип. Основное назначение BPM-платформы — управление логикой бизнес-процесса, а это логика достаточно высокого уровня, причем бизнес-процесс может быть сколь угодно долго растянут во времени. Фронт-офисные системы могут стать инициаторами начала бизнес-процесса, являться его частью. Но использовать движок BPM-платформы для управления логикой низкого уровня фронт-офисного приложения — слишком дорогое удовольствие. Для того чтобы сравнить две цифры и показать ту или иную форму пользователю, гораздо легче (дешевле) сделать это в самом фронт-офисном приложении, чем использовать для этого BPM-платформу.

Алексей Макеев: Прежде всего, отмечу, что BPM не является прикладным программным обеспечением. Это инфраструктурное ПО, используемое для реализации логики различных бизнес-процессов. Что касается ПО для автоматизации фронт-офиса банка, то, на мой взгляд, одна из его основных задач состоит в том, чтобы предоставить удобный пользовательский интерфейс для оформления клиентских операций, причем непосредственно в момент обслуживания клиента. Все остальные функции могут быть выполнены позже (иногда даже в другое время), причем они зависят от конкретного продукта. Ведь, как мы знаем, для расчетных операций и заявок на выдачу кредита действуют разные регламенты их дальнейшей обработки. Поэтому в нашей практике мы стараемся выделять эти две задачи — автоматизацию рабочих мест по обслуживанию клиентов (front-end) и автоматизацию выполнения последующих регламентов обработки операций и, как правило, решаем их с помощью двух разных компонент.

С помощью front-end решения разумно решать только задачу автоматизации работы по вводу клиентских заявок в точках продаж, например по продаже потребительских кредитов или паев ПИФов, где главным критерием является удобство и скорость работы интерфейса пользователя. А выполнение сложных сценариев обработки по каждой заявке целесообразно предоставить решению, реализованному на BPM-платформе. Замечу сразу, что использование этой платформы дает отличный результат там, где есть большой поток операций и их сложная многостадийная обработка. К тому же не нужно забывать о частых изменениях в бизнес-процессах, которые можно сделать намного быстрее, если решение реализовано на промышленной BPM-платформе. Таким образом, front-end компонента — для ввода заявок, а компонента на BPM-платформе — для их исполнения. Каждая компонента решает свою специализированную задачу и может масштабироваться отдельно в зависимости от нагрузки на нее.

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

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

— Возможна ли в принципе формализация и автоматизация процессов без BPM и SOA?

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

— Возможна ли автоматизация сколько-нибудь больших (многошаговых) и разветвленных процессов и/или групп процессов без применения, перестроенных на принципах BPM и SOA задействованных в этих процессах прикладных систем — АБС и других бизнес-приложений банка?

Алексей Макеев: В принципе, наверное, да, но в то же время, по нашим наблюдениям, все больше компаний-разработчиков начинают использовать в своих бизнес-решениях SOA-архитектуру и промышленные ESB и BPM-платформы. Один из таких примеров — компания FICO, — мировой лидер на рынке решений класса Decision Management, партнером которой мы являемся. Мы используем решения этой компании в проектах по созданию кредитных конвейеров. Речь идет о двух системах: Capstone Decision Manager — системе для автоматизации бизнес-процессов принятия решений по кредитным заявкам и Debt Manager — системе автоматизации бизнес-процессов взыскания задолженности. В новых версиях этих продуктов для автоматизации многошаговых и разветвленных процессов взамен собственных разработок используется BPM-платформа IBM WebSphere Process Server компании IBM.

Сергей Орлов: Для автоматизации любого распределенного между различными системами процесса требуется переделка этих систем для представления их в процессе как сервисов. Это может быть действительно существенное перестроение систем или “обертывание” их кода в интерфейс, доступный со стороны BPM-системы или интеграционной шины, но переделка требуется в любом случае. Мы так и поступаем: все новые разработки и доработки выполняем на принципах SOA, старый код “оборачиваем” адаптируемым к нужному интерфейсу сервисом.

Алексей Матукин: Это крайне нетривиальная задача, так как большинство существующих АБС и бизнесприложений достаточно закрыты. Каждое из них имеет свои способы взаимодействия с внешними системами: где-то это специализированный файловый обмен, где-то — низкоуровневые средства доступа на уровне программирования взаимодействия на основе TCP/IP протокола.

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

— Формализация, оптимизация и автоматизация бизнес-процессов банка может происходить в рамках двух подходов:

а) сверхувниз — это наиболее естественно при внедрении процессного управления в банке или его части/направлении бизнеса. При этом начинают с бизнес-процессов самого верхнего уровня;

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

Каковы “за” и “против” обоих подходов?

Марк Залан: Подход «А» позволяет разработать решение стратегического масштаба, наиболее целостное и правильное с точки зрения долгосрочной перспективы. В то же время, такой подход требует воли к масштабным инвестициям и долгосрочной, кропотливой работе в рамках выбранной стратегии без четкого экономического эффекта (отдачи) по окончании проекта.

Подход «Б» позволяет быстро решить конкретную проблему и получить положительную отдачу от проекта. В то же время, такой подход всегда приводит к “лоскутности” общей инфраструктуры и существенным постоянным затратам на закрывание “лоскутного” эффекта, построение обxодныx решений, и т. д. В долгосрочной перспективе стоимость владения такой инфраструктурой будет в разы превышать стоимость решения «А» с точки зрения поддержки, внедрения, повышенной сложности внесения изменений и т. д.

Сергей Орлов: Вариант «А» наиболее желательный, потому что есть поддержка руководства банка, есть время на продумывание архитектуры, этапов, обучения персонала. Чаще всего реализация варианта «Б» завершается провалом.

— Каковы особенности разработки BPM-решения? Какие этапы наиболее понятны и просты в исполнении, какие, наоборот, непонятны и сложны?

Сергей Орлов: Цикл разработки состоит из следующих шагов: анализ, проектирование процесса, проектирование сервисов, тестирование, развертывание, снятие показателей во время работы (мониторинг), оптимизация. В случае использования некоторых платформ можно сокращать шаги для оптимизации процесса за счет возможности симуляции, т. е. можно «проиграть» процесс с различными сценариями и найти узкие места еще до запуска процесса в работу. Можно также сравнивать историческую информацию, полученную в результате работы, с моделируемыми параметрами, то есть проверять оптимизацию до запуска в работу.

— Каковы особенности формализации и оптимизации сквозных бизнес-процессов? Насколько необходим владелец сквозного процесса?

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

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

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

— Каковы особенности автоматизации процессов со значительным участием людей (human-oriented processes)?

Сергей Орлов: Особенностью автоматизации процессов со значительным участием людей является, с одной стороны, необходимость взаимодействия с разного рода системами для получения информации и умение отображать эту информацию в эргономичном виде. Т. е., если сравнивать с “безлюдными” (system-oriented) процессами, на порядки возрастает количество объектов, с которыми работаешь при разработке. С другой стороны, требования к производительности ниже.

— Что мешает российским банкам формализовать и оптимизировать (с применением ИТ) свои бизнес-процессы?

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

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

Сергей Орлов	Марк Залан	Алексей Матукин	Алексей Макеев

Скачать статью в PDF