Чем BPMS полезна для банковского бизнеса?
Разговор с экспертами компании SMART technologies
Российский рынок BPM-решений активно развивается, однако его потенциальная емкость гораздо выше объемов реальных внедрений. Что является барьером: проектная сложность, ошибки при выборе ИТ-инструментов или банальные завышенные ожидания бизнеса от «волшебной таблетки» для повышения эффективности бизнес-процессов? Об этом TAdviser расспросил Алексея Пархоменко, директора департамента по работе с ключевыми заказчиками, и Ивана Банцова, директора департамента комплексных проектов компании SMART technologies.
Давайте возьмем для примера финансовый сектор – близкая вам сфера, в ней накоплен, пожалуй, наиболее значительный опыт внедрения систем Business Process Management (BPMS). Понятно, что банки в последние годы активно трансформируются в финтех-компании, а управление массой быстро меняющихся услуг для клиентов требует специальных методов управления бизнес-процессами. Но это в теории. А на практике? Какие именно задачи, возникающие у банков, становятся тем «триггером», который запускает проект внедрения BPM-решения?
Алексей Пархоменко: Конечно, запрос на BPM-решение – это всегда ответ на потребности бизнеса. Эти потребности сегодня определяются растущей конкуренцией между банками в борьбе за заказчиков, ведь, с одной стороны, количество банков постоянно сокращается, а, с другой стороны, появляются новые компании, которых желательно сделать своими клиентами. Тенденция банков наращивать количество продуктов для клиентов очевидна. Однако, если для розничных клиентов банки уже реализовали много цифровых сервисов, то с корпоративными клиентами ситуация иная: по-прежнему для многих банков банальное открытие счета может занимать 2 - 3 дня. Аналогичная проблема - с получением кредита, заказом банковской гарантии под государственный конкурс и т.д. Понятно, что в ближайшей перспективе успешнее окажутся те банки, которые дают возможность получать все банковские сервисы быстро, гибко и удаленно в цифровом виде.
Звучит красиво. Однако скорость бизнес-процессов, которые вы упомянули, зависит, главным образом, не от того, что тот или иной сотрудник любит на рабочем месте отвлечься на чай с булочкой, а от того, что называется словом «compliance», то есть разнообразных проверок на предмет соответствия требованиям регулятора. Что здесь можно кардинально ускорить?
Алексей Пархоменко: Суть BPM – не в организации бизнес-процессов как таковых, а в повышении эффективности этих бизнес-процессов, в первую очередь, за счет автоматизации. Многие бизнес-функции могут быть автоматизированы: направление запроса на проверку, получение данных из партнерских источников, например, бюро кредитных историй и т.п. Образно говоря, появление BPM не заставляет сотрудника отказаться от чая с булочкой, просто в то время, когда он будет жевать булочку, его рабочие операции из разряда рутинных будут осуществляться автоматически. Причем, параллельно для многих запросов.
Иван Банцов: Понятно, что современный банк - это хорошо информатизированное предприятие. Однако каждый раз, получив заявку на открытие счета, менеджер по работе с клиентом входит в CRM, чтобы вручную проверить, не заведен ли этот клиент в систему. А офицер безопасности вручную проходит по всем необходимым базам типа «черных списков» (BlackList), проверяет потенциального клиента в АМL-системе (Anti-Money Laundering) в соответствии с федеральным законом №115-ФЗ «О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма». Для каждой операции, как правило, есть своя компьютерная база данных или специализированная информационная система. Они работают автономно, и без автоматизации их работы обычный запрос открытия счета занимает обычно три дня и пять человек сотрудников.
Кстати, задачу ускорения процессов можно решить и без всякой автоматизации. Например, увеличить штат персонала бизнес-подразделения в 10 раз. Тогда заявка клиента тоже будет обрабатываться быстрее. Но мы получим в 10 раз больше ошибок, потому что таково свойство человеческого фактора. И стоимость ускорения конкретного процесса окажется космической. Но если положить эти типовые действия персонала в BPM-систему, мы ускорим процесс без затрат в виде стоимости дополнительных сотрудников и их ошибок.
Как это будет выглядеть с участием BPM?
Алексей Пархоменко: Движок BPM-системы получит запрос, вызовет соответствующий сервис, который автоматически обратится в CRM-систему и проверит, что такой клиент в банке еще не зарегистрирован. Затем сам зайдет на соответствующий сайт, например, налоговой службы, или обратится к онлайновой базе данных, где найдет актуальные сведения о компании типа кода ОКПО, адреса и т.п., и обогатит запись о потенциальном клиенте недостающими сведениями. Сам автоматически запросит AML-систему и получит ответ, проверит «черные списки» и т.д. В результате, с учетом того, что в некоторых точках процесса требуется участие человека, на все мероприятия потребуется 2 - 3 часа.
Еще один пример - получение корпоративного кредита: вместо традиционных 3 - 5 рабочих дней - решение в течение двух часов. Или еще один важный момент – получение банковской гарантии. Немало компаний постоянно участвуют в государственных конкурсах и оформляют по 3 - 4 заявки в неделю. Для них два – три дня на получение банковской гарантии – это неприемлемый срок, а два часа – это то, что требуется от банковского партнера. По нашему опыту, после внедрения BPM можно обеспечить срок исполнения запроса банковской гарантии в 30 минут.
Радикальное повышение скорости автоматизированных бизнес-процессов – это, безусловно, важное свидетельство повышения эффективности рабочих процессов, но не единственное. Имеет значение и удобство обновленных процессов?
Алексей Пархоменко: Конечно! Можно попросить клиента заполнить заявку, подписать у генерального директора, сделать скан, отправить в банк, а затем не расставаться с телефоном в ожидании звонка от менеджера в течение двух часов. А можно нажать три кнопки в мобильном приложении и получить на электронную почту файл банковской гарантии в виде скана документа, готового к отправке на конкурс.
Дело в том, что на самом начальном этапе перед внедрением BPM мы формализуем и рисуем в виде блок-схем те бизнес-процессы, которые потом реализуем в системе BPM. Уже на этой стадии заказчик может наглядно увидеть неэффективные устаревшие бизнес-процессы или построить новые с учетом максимальной эффективности и удобства.
Иван Банцов: Я бы вообще сказал, что проект внедрения BPM, скорее, консалтинговый, чем айтишный. В этой связи важную роль играют вопросы измеримости процессов и соответствующие метрики, которые имеются в BPM-системе. Можно сказать, что с помощью BPM-систем банки могут померить все: время отработки того или иного сервиса, полное время реализации для заказчика этого сервиса, измерить все промежуточные составляющие процесса и т.д. Это позволяет, во-первых, объективно сравнивать себя с конкурентами и четко понимать, насколько привлекателен для потенциальных заказчиков твой сервис, и, во-вторых, определять узкие места, измеряя сроки работы промежуточных узлов бизнес-процесса.
Алексей Пархоменко: Имея в своем распоряжении разнообразные временные метрики, можно изучать множество вопросов: от анализа узких мест и до корреляций этих проблемных мест с бизнес-показателями банка. Скажем, если после внедрения BPM время отработки заявки на получение банковской гарантии сократилось до трех часов, то можно смотреть, как это отразилось на количестве проданных продуктов банка: за месяц или за другой период времени, сделать прогноз о том, каким образом нововведение будет влиять на продажу других продуктов банка.
Средства аналитики и моделирования процессов – это обязательный элемент популярных систем BPM?
Иван Банцов: Да, ведь внедрением BPM занимаются компании, достигшие определенного уровня зрелости в своих бизнес-процессах, те, которые хотят лучше понимать, что, как и почему происходит в их процессах. Почему произошел сбой в обслуживании? Почему заявка «зависла»? Аналитика и моделирование процессов – это те неотъемлемые результаты внедрения, которые такая компания хочет получить.
Большинство BPM-систем умеют выявлять узкие места еще на этапе описания бизнес-процессов и выдавать соответствующие предупреждения. В ходе рабочей эксплуатации за счет накопленной статистики можно увидеть точки возможного улучшения бизнес-процессов, например, увеличить численность персонала в том или ином отделе, если статистика показывает там «бутылочное горлышко». Кстати, такие ситуации можно смоделировать в системе и посмотреть, к чему это приведет на практике. В результате у нас повышается скорость изменения бизнес-процессов в ходе какого-либо нововведения, а также «стоимость» этого внедрения, включая потенциальные риски, радикально снижается. Иными словами, фактически на уровне модели силами двух человек (одного – из бизнес-подразделения и одного – из ИТ) можно смоделировать работу целого подразделения банка в течение месяца, квартала, полугодия. Это то, ради чего, в числе прочего, компании внедряют BPMS.
Алексей Пархоменко: Один из ключевых результатов внедрения BPMS – это новый уровень скорости изменения бизнес-процессов. Если бизнес-процессы оформлены по старинке - в должностных инструкциях, утвержденных генеральным директором, то любое изменение инструкции, доведение до конечных исполнителей – это процесс, который обычно занимает не меньше недели. Если же бизнес-процесс поддерживается системой BPM, то вносить изменения в процессы можно практически на лету. Условно говоря, в течение суток можно добавить новую проверку или этап согласования или, наоборот, исключить из согласования, если понимаем, что данная функция стала излишней.
Таким же образом можно реагировать на определенные рыночные вызовы или ситуации. Скажем, юрлица пошли за кредитами, и банк может оперативно посмотреть в аналитике BPM-системы, где процессы начали подтормаживать, и принять решение, например, добавить конкретной функции сотрудников либо изменить сам процесс, чтобы он стал оперативнее. На мой взгляд, именно в этом заключается основная ценность BPMS - в управлении бизнес-процессами. Не столько в поддержке их работы средствами ИТ – в монолите отлить один раз и на постаменте поставить, и они будут неизменными, как памятник, - сколько в оперативной реакции на изменения: рыночной ситуации, требований регулятора и т.д.
Что касается «монолита», то он уже в банках есть, - это АБС (автоматизированная банковская система), «сердце» современного банка. Каким образом встроить гибкую систему управления бизнес-процессами в ИТ-структуру, в основании которой лежит «монолит» АБС?
Алексей Пархоменко: Есть разные способы. Можно АБС в течение года доработать до такого состояния, что она сама будет поддерживать изменяющиеся бизнес-процессы. Очевидно, что такая модернизация – дело настолько сложное, дорогое и ответственное, что мало кто из банков на такое решится. Можно ту же самую историю реализовать средствами CRM, ведь у каждой системы CRM есть собственный движок управления процессами. А можно это сделать с помощью внедрения BPM-системы, которая будет взаимодействовать, в соответствии со своей моделью бизнес-процессов, с разными ИТ-системами. И этот подход, чаще всего, оказывается в разы быстрее – проект может быть реализован за несколько месяцев.
Иван Банцов: С точки зрения функциональности, BPMS – это некоторый процессный слой, который размещается между АБС – практически неизменным «сердцем» банка – и слоем прикладных систем, решающих те или иные прикладные задачи: AML, CRM, Black List, ЭДО и т.д. Собственно, процессный слой BPM описывает правила взаимодействия между собой разных прикладных систем. Поскольку процессный слой реализуется в виде отдельной структуры, его легко модифицировать, то есть вносить изменения в элементы и логику процессов.
Думается, одна из проблем для внедрения в банке системы управления бизнес-процессами связана с настройкой BPMS на взаимодействие с конкретными ИТ-системами, которых у современных банков немало, и они могут быть весьма специфическими. Это так?
Иван Банцов: Сегодня стандартом де-факто для корпоративных ИТ-систем банков и других организаций с высоким уровнем информатизации является системная архитектура с информационной шиной, через которую все ИТ-системы обмениваются данными. Эта архитектура очень хорошо подходит именно к ИТ-среде банков, в которой есть стабильная и надежная АБС, и есть прикладные системы: CRM, бизнес-аналитика и проч., которые живо реагируют на бизнес-ситуацию. Обмен данными в такой структуре из двух составных частей: монолитной и динамичной,- осуществляется через информационную шину данных. Здесь как раз место для BPMS, которая увязывает в единую логику все прикладные информационные системы, и использует для управления бизнес-процессами данные, передающиеся по информационной шине.
Алексей Пархоменко: С точки зрения практической реализации такого подхода, наиболее эффективно использование, так называемой, микро-сервисной архитектуры. Она предназначена как раз для ИТ-систем со сложной внутренней структурой и высокими требованиями к интеграции составных частей. Смысл в том, что в back-end ИТ-системы банка имеется множество программ, которые реализуют одну простую функцию (микро-сервис). Например, микро-сервис обращения к API телефонной станции и получение ответа с целью верификацию клиента через телефонный номер. Или микро-сервис проверки присутствия компании в «черном списке». Тогда бизнес-процесс, описанный в BPMS, будет в нужных местах вызывать тот или иной микро-сервис, а он, в свою очередь, обращаться к соответствующей прикладной системе за данными через общую шину.
В итоге получается весьма гибкая структура: набор заранее запрограммированных микро-сервисов используется для реализации конкретных элементов автоматизированных бизнес-процессов. При необходимости любой микро-сервис можно модифицировать или добавить новый, и эти манипуляции никак не затрагивают работающую систему BPM - любые изменения в архитектуру системы мы вносим на уровне микро-сервисов. Скажем, если появляется новый источник информации, откуда нужно либо забрать информацию, либо положить туда данные, то у нас появляется микро-сервис по работе с этой системой. Либо в бизнес-процессе появляется какая-то сущность, которая соответствует микро-сервису, и мы ее далее используем. При этом вся основная система, вся основная логика остается прежней.
Иван Банцов: Это описание, на мой взгляд, отлично демонстрирует роль BPMS в современной корпоративной ИТ-системе. Сами по себе бизнес-процессы в любом случае, так или иначе, работают. Задача BPMS - их унифицировать, привести их к единой нотации, единой, если хотите, философии. Иными словами, функционально связать по понятным простым правилам те ИТ-системы, которые существовали и работали ранее, заставить их работать совместно с гораздой большей эффективностью и результативностью.
Кроме того, набор микро-сервисов, написанных для одного бизнес-процесса, наверняка можно будет использовать в других ситуациях. Например, верификация клиента – это функция, которая понадобится в различных бизнес-задачах. Таким образом, в компании создается собственный банк готовых микро-сервисов, протестированных и полностью готовых к использованию в разных бизнес-процессах.
Как вы оцениваете трудоемкость и сложность процессов подключения к BPMS различных прикладных ИТ-систем, работающих в банках?
Алексей Пархоменко: В целом, если компания достаточно зрелая в плане информатизации, а банки, как правило, такие и есть, то у нее архитектура с шиной данных обычно уже реализована. Соответственно, вопрос с коннекторами к прикладным системам уже решен – используются стандартные коннекторы, которые входят в состав WebSphere Message Broker или CRM-решения Oracle Siebel, либо они написаны самостоятельно.
Гибкость и универсальность инструмента описания бизнес-процессов – это сильная сторона BPMS. И одновременно – источник потенциальной головной боли для предприятия: как организовать формализацию бизнес-процессов, где взять ресурсы для написания кода микро-сервисов и т.д.? Понятно, что на этом рынке активно работают вендоры, поставляющие закрытые проприетарные решения BPMS, которые обещают избавить клиента от этой головной боли. В то же время есть сторонники самостоятельной разработки BPMS на основе открытого кода, которого, к слову, на рынке также немало. Вы, как российский ИТ-интегратор, как делаете выбор между указанными двумя вариантами?
Иван Банцов: Ну, если посмотреть на график выхода релизов коммерческих BPM, то ключевые релизы выходят раз в год, менее значимые изменения – раз в несколько месяцев. Понятно, что за это время исправляется громадное количество ошибок, неточностей, добавляется новый функционал. Но вот вопрос: готовы ли потребители этой системы получать обновления функционала с такой скоростью? Практика демонстрирует явную тенденцию в сторону все более глубокой кастомизации решений BPM.
Вроде бы, все хорошо с закрытым вендорским решением: заказчику дали готовое ИТ-решение, интерфейсы для управления бизнес-процессами и обширный список возможностей системы. Однако этот список в одной части избыточен, в другой чего-то явно не хватает, и вообще нужно решение, которое удовлетворяет конкретным бизнес-требованиям компании. Но поскольку это закрытое решение, возможно, заказчику даже придется несколько поменять собственные бизнес-процессы в угоду тому, чтобы они соответствовали возможностям купленной коммерческой системы…
В результате зачастую компании выбирают open source решение, у которого открытый код, можно посмотреть, из чего оно состоит, внести нужные изменения, заточить систему именно под свои требования, то есть произвести персональную кастомизацию. И получить абсолютную гибкость, заплатив только за кастомизацию и за техническую поддержку впоследствии. Тогда длительность внесения изменений сокращается до длительности самой разработки, и изменения будут сделаны именно те, которые нужны данному заказчику.
Иными словами, на разработку универсальной «волшебной таблетки» BPMS никто не замахивается, потому что это будет очень долго, очень дорого и крайне неэффективно, с точки зрения внесения изменений. Вот почему любое ИТ-решение, будь то проприетарное ПО от глобального вендора или продукты open source, так или иначе придется дорабатывать и адаптировать к той информационной системе и тем реальным бизнес-процессам, которые есть у заказчика на данный момент.
Алексей Пархоменко: Мы считаем, что правильный подход – это использование open source продуктов, которые дают необходимую гибкость и возможность создать систему, максимально соответствующую требованиям заказчиков. Потому что кастомизировать и дополнительно дорабатывать под требования заказчика придется обязательно любую систему. Даже если это Pegasystems или IBM WebSphere Lombardi, то есть сложные и дорогие мировые лидеры коммерческих проприетарных решений. Ведь фактически заказчику нужно запрограммировать свои собственные бизнес-процессы, а значит, придется приложить немало усилий для кастомизации изначального программного решения. Только в случае open source не придется платить за лицензию, и вместе с open source вы получаете ту гибкость решения, которая так важна для задач BPM.
Плюс к этому, если это выбранная open source система достаточно популярна, то есть огромное количество разработчиков по всему миру, которое делится открытыми разработками с сообществом. Мы, кстати, выбрали конкретный open source продукт - BPM-платформу Camunda. Это открытая платформа для управления бизнес-процессами и автоматизации принятия решений, которая сегодня, по оценкам аналитиков, является наиболее популярным решением в мире.
Иван Банцов: Добавлю, что сегодня общепринятый стандарт описания и моделирования бизнес-процессов – BPMN 2.0, который поддерживает большинство BPM-систем, в том числе, и Camunda. В данной нотации имеется достаточное количество функциональных блоков, логических операций, с помощью которых можно описать бизнес-процесс от начала до конца. При этом легко - с помощью нажатия одной кнопки - отправить этот описанный бизнес-процесс в среду разработки, которая обеспечит его ИТ-поддержку. Иными словами, бизнес-процесс может описать человек, далекий от программирования.
Это то, что сегодня называется «low-codding» и подразумевает кардинальное снижение специфического труда по написанию кода?
Иван Банцов: Именно так. Сегодня, по большому счету, мало кто уже пишет программы с чистого листа. Их собирают, в лучшем случае, из готовых программных объектов, программных модулей в той или иной среде. Кстати, этот подход стал особенно популярен именно в банках, потому что там он дает реальную возможность договориться менеджерам банка – функциональным заказчикам – с банковскими программистами, которые отлично умеют программировать, вот только общий язык с бизнес-подразделениями находят с большим трудом. Так вот, оказалось, что гораздо проще и быстрее научить представителей бизнеса работать со стандартными формами и нотациями в стиле low-codding, чем им договориться с программистами, что именно нужно запрограммировать.
Насколько интересно бизнес-менеджеру осваивать программирование, пусть и визуальное?
Иван Банцов: Он, скорее, приобретает навыки не программиста, а аналитика, что ему точно гораздо интереснее. Смотрите: когда мы моделируем какой-либо бизнес-процесс, то сразу видим имеющиеся рассогласования. Скажем, департамент выдает на выходе один набор данных, а взаимодействующему с ним департаменту нужен иной набор данных. Или из этого департамента вышла масса документации, но так и не поступила в работу, потому что никто не может эти данные принять. Тут открывается поле для размышлений аналитика: какие есть проблемы в бизнес-процессах, и каким образом их можно разрешить? Можно пойти административным путем: закрепляем в нормативных документах, что имеющихся данных достаточно, и точка! Можно решить техническим путем: запросим недостающие данные с помощью микро-сервисов либо в ручном режиме. В любом случае единый формат описания процессов позволит всем увидеть рассогласования и договориться, каким образом их ликвидировать.
Алексей Пархоменко: В продукте Camunda есть очень удобный инструмент под названием Camunda Modeller. Он позволяет не только удобно описывать любые сквозные бизнес-процессы с использованием стандартной нотации BPMN 2.0, но созданный «на бумаге» бизнес-процесс промоделировать, проверить его работоспособность. С моей точки зрения, это самый удобный эффективный инструмент моделирования процессов среди всех BPMS. Он полезен именно бизнес-пользователю, который понимает, как должен работать бизнес-процесс, но не имеет ни малейшего представления о том, как это положить в ИТ-систему.
Получается, что, как ни крути, а бизнес компании зависит от усердия и квалификации программистов или других сотрудников, дорабатывающих базовые программные продукты…
Иван Банцов: Думаю, что к open source решению не стоит относиться с позиций «требуется много дорабатывать». Понятие «дорабатывать» обычно подразумевает исправление багов, ошибок, а для создания BPMS на основе открытого ПО характерна адаптация этой системы (не продукта, а именно готовой системы!) к бизнес-требованиям заказчика. На мой взгляд, это серьезная разница: «разработать то, чего точно не хватает», и «лучше адаптировать к желаемым деталям процесса». И это не просто различные трактовки одного понятия. В первом случае мы говорим о том, что бизнесу нужно в данный момент. А во втором – о возможности развивать и адаптировать создаваемую систему под дальнейшие потребности. В качестве иллюстрации приведу пример, как один из наших клиентов с успехом использовал BPMS для бизнес-вопросов, непосредственно не связанных с бизнесом, в частности, для обучения сотрудников.
Не стоит долго объяснять, что отправить на обучение 50 сотрудников банка – это серьезное вмешательство в бизнес-процессы. По сути, их нужно выдернуть с работы, отправить на курсы, организовать им замену, скорее всего, в виде дополнительной смены. Делать это, как обычно, вручную – страшная головная боль. А в одном из банков это сделали с помощью BPMS. Теперь у них задача организации любого обучения, тренинга любого масштаба или выездного мероприятия для сотрудников решается буквально несколькими кликами «мыши».
Алексей Пархоменко: Стоит отдельно напомнить о такой специфике современной России, как зарубежные санкции. Возьмем, например, качественное дорогое BPMS-решение IBM Lombardi. В тот момент, когда какой-нибудь банк РФ попадет под санкции, корпорация IBM немедленно отключит поддержку, возможность докупать любые апгрейды, обновления лицензий и т.д., вне зависимости от того, сколько денег потратил банк на эту систему. В случае open source системы никаких последствий от санкций не будет. Как ее изначально кастомизировал и поддерживал такой партнер банка, как компания SMART Technologies, так он будет ее поддерживать дальше, вне зависимости от происходящего на геополитической арене.
Если труд программиста больше не является проблемной точкой проекта BPM, то как можно оценить среднее время внедрения BPMS?
Алексей Пархоменко: Конечно, конкретные сроки зависят от специфики проекта. Однако есть методы ускорения проекта. В частности, в своих проектах мы используем методологию DevOps и технологию разработки Agile, а микро-сервисная архитектура, кстати, очень органично сочетается с инструментарием Agile/DevOps.
Весь программный код сразу выкладываем в репозиторий заказчика. Сразу начинаем внедрение с инструментария автоматизированной сборки и автоматизированного unit-тестинга. Это позволяет нам сразу на ходу исправлять ошибки, выявленные при тестировании, и сборку делать за несколько минут. В результате типичный бизнес-процесс банка мы можем полностью реализовать за несколько месяцев. Иными словами, через несколько месяцев банк сможет предложить клиентам кардинально обновленные условия, например, открытие счета и одобрение кредита через час после обращения.
Иван Банцов: А следующий продукт, например, банковская гарантия за час – через месяц, потому что основные ИТ-элементы уже созданы и работают, и по каждому сформирована качественная детальная спецификация. Мы, начиная с «нулевого цикла», когда еще окончательно не определены бизнес-требования к новой системе, с помощью серии интервью выявляем бизнес-требования, детализируем их и доводим до уровня подробного технического задания. Тогда, располагая детальной спецификацией каждого микро-сервиса, запрограммировать новый процесс - дело достаточно тривиальное. На этом, собственно, и основывается наша уверенность, что для любых процессов современного банка максимальный срок первичного внедрения BPMS – всего несколько месяцев.
Ранее вы упомянули, что решения BPMS нужны компаниям, достигшим определенного уровня зрелости. Вы ведь имели в виду не ИТ, а бизнес-процессы?
Иван Банцов: Именно так. Компания, даже крупная, может успешно работать, но при этом бизнес-процессы могут строиться, образно говоря, «по понятиям». Скажем, если менеджер по работе с крупными клиентами может запросто зайти в кабинет к генеральному директору и подписать договор, минуя ряд проверок, просто на доверительных отношениях, то BPM такой организации не поможет. Вдруг в договоре были заложены некоторые риски, и они потом реализовались, и банк понес финансовые потери? А случились они только потому, что кому-то показалось более эффективным в обход всех ИТ-систем и бизнес-процессов зайти в кабинет директора и быстро решить свой вопрос.
Алексей Пархоменко: Иными словами, высокий уровень информатизации – это одна составная часть зрелости компании. Вторая часть зрелости – это, образно говоря, общее понимание того, что лучше мы все будем ездить по дороге по правилам, чем кто-то поедет по обочине, и он один проедет быстрее, а все вместе поедут медленнее. Но только в этих условиях дадут плоды все усилия по внедрению BPMS: детальные интервью с сотрудниками из разных бизнес-подразделений, выявление неявных противоречий в бизнес-процессах, их купирование на начальном этапе формализации и поиск наилучших схем процессов.
Такой подход, судя по реакции рынка, адекватен ожиданиям наших партнеров – коммерческих банков. Сейчас компания ведет несколько проектов внедрения BPMS. Рассчитываем, что летом сможем рассказать о хороших результатах.
Будем ждать продолжения.