Технологию управления эффективностью бизнеса (Business Performance Management, BPM) сегодня еще нельзя назвать зрелой, хотя основные методологические и информационные компоненты, образующие ядро BPM-систем*, детально разработаны, а сами такие системы успешно применяются в иностранных и российских банках. Однако управленческие и аналитические процессы кредитных организаций непрерывно модифицируются по мере изменения нормативных требований, накопления отраслевого опыта, развития и расширения банковского бизнеса. Так, последовательное сближение российских правил бухгалтерского учета с международными стандартами заставляет банковских методологов регулярно пересматривать правила ведения управленческого учета. В свою очередь, корректировка процессов управления эффективностью требует совершенствования механизмов и наращивания возможностей информационной составляющей BPM-систем. Например, известный американский закон Сарбейнса -- Оксли (Sarbanes-Oxley Act) обязал компании, работающие в сфере финансовых услуг, в течение четырех лет хранить все первичные финансовые документы разных типов, а также письма и сообщения, которыми они обмениваются с клиентами. Чтобы быстро продемонстрировать проверяющим и инспекторам соответствие отчетных показателей первичным документам и проследить модификации любого элемента данных от момента его появления в транзакции и до попадания в отчет, финансовые организации вынуждены задуматься над повышением производительности своих хранилищ данных. Кроме того, как и в ИТ-отрасли в целом, здесь постоянно происходят изменения и обнаруживаются недостатки устоявшихся подходов.

Новый взгляд на дискуссии вокруг BPM: BI и инструменты интеграции

Поступательное развитие BPM неожиданно возродило практически забытые дебаты о взаимосвязи BI (Business Intelligence, бизнес-аналитика) и BPM и позволило по-новому взглянуть на приоритетные пути совершенствования продуктов этой категории. Уже давно не вызывает сомнений тот факт, что технология BPM явилась результатом эволюции BI, обеспечив бизнесориентированное использование аналитических инструментов для отслеживания финансовых показателей на всех этапах корпоративного управления. Что же тогда послужило основой для вновь возникших дискуссий о преимуществах комбинирования BPM и BI?

Двигающаяся в своем развитии по спирали, технология BPM в последние годы была существенно расширена за счет дополнительных процессов управления эффективностью, но при этом сохранила неизменным свое ядро. Это инициировало работы по созданию стандартов BPM 2.0, которые осенью 2006 г. начала BPM Standards Group. Подготовка очередной версии стандартов еще не завершена, но, по мнению экспертов, концепция BPM может получить дальнейшее развитие, в том числе благодаря ее применению за пределами финансовой сферы, а также в результате широкого использования финансового анализа и прогнозной аналитики.

Традиционно целью применения BPM в банке являлось управление им на основе финансовых показателей KPI (Key Performance Indicators). При этом инструменты BI использовались преимущественно на стратегическом уровне небольшой группой бизнес-аналитиков и руководителей для мониторинга показателей эффективности, которые могли повлиять на принятие управленческих решений. Наблюдаемое сегодня постепенное проникновение этой технологии в такие области деловой активности организации, как продажи, маркетинг и управление персоналом, означает выход BPM на операционный уровень работы кредитной компании. Опыт фирмы Intersoft Lab показывает, что российские банки всё чаще ставят перед разработчиками этих систем задачи, выходящие за границы финансового управления. Примером одной из таких задач может служить подготовка отчетов для принятия решений по повышению уровня продаж на основе анализа поведения клиентов. С другой стороны, скажем, для анализа движения наличности (cash flow) важна обработка данных в реальном времени. Наряду с оценкой прибыльности в разрезе банковских продуктов и клиентов исследование и прогнозирование поведения cash flow являются важнейшими задачами финансовой аналитики.

Возросшая потребность банков в принятии решений в реальном времени существенно расширяет возможности применения BI на всех уровнях управления эффективностью. Желание заказчиков отслеживать и финансовые, и операционные показатели требует того, чтобы инструменты бизнес-анализа могли одновременно обращаться к базам данных BPM-продуктов, автоматизированных банковских систем (АБС), отдельных бэк-офисных модулей, CRM-приложений и т. д. Например, для анализа клиентской базы часто требуется выводить в одном отчете информацию о переговорах с клиентом, которая хранится в CRM, и относящиеся к нему финансовые параметры из базы данных АБС и/или BPM-системы. Обработка гетерогенных источников данных невозможна без применения сложных технологий интеграции на основе сервисно-ориентированной архитектуры (Service-Oriented Architecture, SOA). И здесь не обойтись без использования BI в проектах внедрения BPM в банках. До недавнего времени применение инструментов бизнес-аналитики ограничивалось обработкой запросов и выпуском отчетов из хранилища данных BPM-системы. Появление нового качества BI разъясняет причины возродившейся полемики вокруг слияния BPM и BI. Следует признать, что пока далеко не все инструменты BI поддерживают стандарты SOA. Поэтому готовые BPM-пакеты со встроенными средствами OLAP и Data Mining на практике часто дополняются интеграционными платформами от внешних поставщиков. Так, сегодня профессиональный интерес российских банков фокусируется на решениях для интеграции, предлагаемых грандами мировой ИТ-индустрии -- Oracle (семейство продуктов Oracle Fusion Middleware) и IBM (платформа IBM WebSphere).

Особенностью внедрения BPM в российских кредитных организациях является поддержка местных регулятивных требований и стандартов подготовки обязательной отчетности, а также оценки и анализа рисков. Последняя задача еще более актуальна для банков европейских стран, которые уже в 2008 г. должны ввести в действие требования “Международной конвергенции измерения капитала и стандартов капитала”, более известной как Basel II.

Однако мировые аналитические компании еще до конца не определились с местом приложений для подготовки обязательной отчетности и риск-менеджмента в составе ИТ-продуктов. Примерно три года назад была сделана попытка выделить такие приложения в отдельную продуктовую категорию — так называемые GRCM-средства (Governance, Risk and Compliance Management, финансовое управление, риски и выполнение регулятивных требований). Большинство организаций приобретает такие продукты в целях выполнения требований и предписаний (compliance) регулятора. Известная компания Gartner определяет compliance как процесс:

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

На рис. 1 представлены компоненты, которые необходимы для реализации GRCM-решений. Их можно условно разделить на три группы:

  • автоматизация внутренней системы контроля;
  • поддержка отчетности;
  • поддержка управления рисками.

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

Перечисленный набор функций реализуется различными инструментами: системами документооборота, ERP, BPM, BI, средствами интеграции. Широкие возможности выбора программных продуктов приводят к тому, что до сих пор не существует единого технологического подхода к построению GRCM-систем. В каждом конкретном случае архитектура и конфигурация конечного решения зависят от предпочтений ИТ-руководства кредитной организации и отчасти от рыночной активности поставщика. Скорее всего рекомендации от авторитетных экспертов рынка еще последуют, а мы пока выступаем в роли свидетелей накопления опыта и “набивания шишек”. В частности, в отчете Европейской комиссии, подготовленном по результатам опроса европейских банков, указано, что одной из глобальных проблем внедрения приложений для автоматизации риск-менеджмента является их согласование с существующими финансовыми информационными системами. Причина в том, отмечается в отчете, что часто внедрение приложений для управления рисками и финансового управления проводилось без осознания учета возможностей их взаимодействия и интеграции.

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

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

В периодичности подготовки отчетов в российских и западных банках наблюдаются существенные различия. У нас в стране обязательными для представления в Банк России являются 80 отчетов, ряд из них составляется по формам для ежедневного представления, другие представляются раз в пять дней, третьи -- ежедекадно, и, разумеется, в их число входят отчеты, направляемые ежемесячно, ежеквартально, раз в полгода и раз в год. Расчет обязательных нормативов выполняется ежедневно. В то время как стандарты МСФО 37 и МСФО 39 предусматривают формирование и корректировку резервов по ссудам на возможные потери на отчетную дату (раз в месяц), положения Банка России 254-П и 232-П требуют формирования и корректировки резервов на ежедневной основе.

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

В результате ИТ-службе банка приходится выгружать данные (за предыдущей день) в хранилище ночью и потом еще “перезагружать” небольшие объемы исправлений в течение следующего дня. При этом критическим параметром становится время доставки этих данных в систему. Оно должно быть минимально. Указанная задача также может быть решена только с помощью специальных инструментов интеграции данных.

Как BPM применяется в российских банках

Ассоциация российских банков, которая регулярно осуществляет мониторинг рынка программного обеспечения для кредитных организаций, в июне 2006 г. провела интервью с ИТ-директорами банков и опубликовала “прогноз” внедрения основной и дополнительной BPM-функциональности на 2007 г. (см. рис. 2)**. Согласно полученным данным, кредитные организации планировали расходовать в нынешнем году свои ИТ-бюджеты в первую очередь на автоматизацию технологий планирования и бюджетирования, риск-менеджмента, управленческого учета и отчетности. Несколько меньший спрос был зафиксирован на инструменты прогнозирования и стратегического планирования.

В 2006 г., по сведениям компании Intersoft Lab, в России было запущено 67 проектов внедрения BPM-систем, в том числе 15 новых -- в кредитных организациях. В первом полугодии 2007 г. стартовало еще 37 проектов, из них четыре — в банковском секторе. Кроме того, продолжилось выполнение нескольких десятков ранее начатых проектов в кредитных учреждениях.

Какая управленческая функциональность на поверку оказалась наиболее востребована? В полном соответствии с прогнозом фактический рейтинг (см. рис. 3) автоматизации управленческих технологий в первом полугодии 2007 г. возглавило финансовое планирование, впервые потеснив управленческий учет, который в течение последних лет являлся самой востребованной BPM-функцией, обеспечивая прозрачность банковского бизнеса для руководителей. Финансовая консолидация, автоматизация подготовки обязательной банковской отчетности и поддержка требования регулятора для оценки рисков были востребованы значительно меньше. Только несколько российских банков открыли такие проекты в текущем году. Это значит, что оптимистичный прогноз ИТ-директоров банков относительно массового внедрения риск-приложений не оправдался. Среди объективных причин сложившейся ситуации следует назвать прежде всего сохраняющуюся неопределенность в отношении требований регулятора к отчетности по Basel II, а также полное отсутствие со стороны Банка России рекомендаций относительно подходов к автоматизации риск-менеджмента. Кроме того, “осторожничать” банки заставляет весьма ограниченный положительный опыт отечественных кредитных организаций в подготовке обязательной отчетности на основе технологии хранилищ данных. Тем временем иностранные банки отдают все большее предпочтение подобным системам отчетности, отказываясь от привычных механизмов Главной книги. Дело в том, что данные Главной книги представляют собой результат выполнения совокупности транзакций и, как правило, не содержат таких ключевых признаков, как тип клиента, тип транзакции, код продукта, валюта, страна проживания клиента или риск, составляющих основу подготовки практически всех отчетов, требуемых сегодня регуляторами разных стран. Сталкиваясь с теми же проблемами, отечественные финансовые организации не спешат отказываться от “полуручной” Excel-технологии подготовки отчетных форм, несмотря на то что она сопряжена с высокими операционными рисками и делает кредитную организацию излишне зависимой от конкретных персоналий. Проникновение в нашу страну успешной зарубежной практики ограничивается недостаточной функциональностью российских АБС, в бэк-офисных приложениях которых, в отличие от западных банковских систем, как правило, ведется минимальный учет аналитических признаков. В результате необходимая для выведения отчетных показателей “аналитика” не может быть выгружена в хранилище данных и использована для подготовки отчетности. Устранение названных противоречий требует серьезной работы по формулированию и практической реализации методологических требований к ведению учета в АБС, а также по доработке регламентов эксплуатации АБС и введению соответствующих организационных изменений внутри банка. После этого можно ожидать ощутимого увеличения внедрений приложений для финансовой консолидации, подготовки обязательной отчетности и управления рисками в российских банках.

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

Современные подходы к внедрению BPM в банках

Еще одно актуальное направление развития ВРМ-систем, на которое указывают разработчики стандартов BPM 2.0, — отраслевая специализация. Создание отраслевых линеек продуктов — естественное и привычное направление развития классов индустрии корпоративного ПО. Как правило, речь идет о построении специальных платформ и прикладных модулей, адаптированных к уникальным отраслевым особенностям. Такой подход обеспечивает более быстрое внедрение за счет использования готовых настроек, способствует снижению расходов на услуги по конфигурированию программных продуктов и приводит к сокращению сроков окупаемости.

Особенностью отраслевой специализации продуктов BPM, распространяющейся на методологические и информационные компоненты, является двухуровневая вертикализация. В частности, для финансовой индустрии она подразумевает разработку отраслевой методической модели финансового управления банком и создание ИТ-платформы, адаптированной для ее реализации.

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

Выделение методической составляющей BPM — это серьезный шаг к “тиражности” BPM-решений. Эта составляющая опирается на опыт внедрения BPM-систем в банках, а значит, ее разработка становится возможной лишь на определенном этапе развития BPM-платформы. Именно поэтому сегодня далеко не все поставщики BPM могут предложить кредитным организациям не только набор ИТ-инструментов для создания хранилища данных и разработки BPM-приложений, но и проверенную на практике отраслевую методическую модель (либо ее отдельные компоненты). Такую, например, как financial services data model (модель данных для финансовых организаций) от IBM, которая в текущей версии объединяет около 3000 отраслевых понятий (объектов, атрибутов, взаимосвязей). IBM также предлагает наборы Business Solution Templates и Application Solution Templates (шаблоны готовых и дополнительных решений), помогающие строить прикладные витрины данных и отчеты для конечных потребителей.

В банковской методической модели, разработанной отечественной компанией Intersoft Lab, отражен большой опыт (более 50 внедрений) ее применения в российских кредитных организациях. Сегодня эта модель содержит 40 информационных объектов, каждый из которых характеризуют не менее 50 атрибутов (то есть модель включает порядка 2000 отраслевых понятий), а также более десятка BPM-приложений для кредитных организаций, таких как “Управленческий учет”, “Финансовое планирование” и др. Каждое приложение включает набор прикладных настроек, расчетных алгоритмов и готовых отраслевых отчетов.

В аналогичные предложения SAP включены так называемые SAP best practices (“лучше практики SAP”) — прототипы отраслевых решений с подробной документацией, которая нередко включает описание расчетов и отчетных форм. Опираясь на эту документацию, прототипы можно быстро перевести в режим промышленной эксплуатации. Фактически они обобщают опыт компании SAP и ее партнеров. Правда, для банковской отрасли подобные “лучшие практики” отсутствуют.

Многогранная модель финансового управления, вобравшая в себя опыт множества проектов внедрения у разных заказчиков, обладает огромной потребительской ценностью, поэтому описание методической модели не поставляется отдельно от программного продукта. Заказчик получает методическую модель, адаптированную под его собственные уникальные требования, в составе услуги по внедрению программного обеспечения вполне определенного поставщика. Например, консалтинг по адаптации преднастроенной модели данных для банковской отрасли — неотъемлемая часть внедрения продуктов SAS Institute. Корпорация Teradata предоставляет в качестве услуги план построения корпоративного хранилища данных (Enterprise Data Warehouse Roadmap) на основе логической модели данных (Logical Data Model), в том числе для финансовой отрасли. При этом методические компоненты продуктов SAS и Teradata не включают алгоритмов обработки данных и альбомов отчетов.

Информационная составляющая BPM содержит:

  • БД, построенные на основе единого словаря данных, заданного в методической модели;
  • процессы, в том числе сбора данных и их загрузки в хранилище (ETL***), реализации алгоритмов, определенных в методической части BPM (для банковского управления это расчет аллокаций, трансфертов, рисков и др.), а также последовательности действий пользователя и сопутствующих им процедур;
  • средства выпуска заданных в методической модели форм отчетности.

Наличие отраслевой специализации не влияет на структуру этапов внедрения, но расставляет новые акценты в технологии развертывания BPM, меняет и четко разграничивает зоны ответственности между участниками проекта.

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

Самая сложная и дорогостоящая стадия внедрения BPM — разработка технического задания (ТЗ) на настройку системы в соответствии с методической моделью. В проектах, ведущихся компанией Intersoft Lab, например, его могут выполнять только ее собственные специалисты или сертифицированные партнеры. Этот этап требует от исполнителя очень высокой компетенции -- знания банковской методической модели и ИТ-инструментов для ее реализации. Разработчик ТЗ несет ответственность за успех проекта, поэтому он имеет право провести аудит результатов методической работы на предмет их реализуемости и технологичности и может подвергнуть ревизии методику, предложенную банком (консультантом). Затем на основе ТЗ выполняется настройка информационной модели.

Это принципиальное отличие современного подхода к внедрению BPM, который опирается на специализированную отраслевую информационно-методическую модель, от более распространенного способа создания управленческой системы на основе технических требований, сформулированных консультантом. Отсутствие у консультанта знаний методической модели и информационной основы BPM зачастую приводит к целому ряду проблем, которые невозможно разрешить ни на этапе настройки, ни позднее, в ходе эксплуатации системы. “Ахиллесова пята” подобных ИТ-решений — низкая технологичность, ограничения производительности и сложность модификации системы.

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

С автором, заместителем генерального директора по маркетингу и работе с партнерами компании Intersoft Lab, можно связаться по адресу: amiridi@iso.ru

* Состав основных технологий и приложений, которые образуют ядро BPM-систем, зафиксирован международной некоммерческой организацией BPM Standards Group в первой версии стандартов BPM. Согласно Industry Framework Document к основным процессам управления эффективностью относятся: стратегическое и оперативное планирование и бюджетирование, консолидация и отчетность, прогнозирование и анализ.

** См.: Амириди Ю., Кудинов А. Автоматизация управления доходностью как отражение бизнес-стратегии банка // Банки и технологии. 2006. № 3. С. 32—68.

*** ETL — Extract, Transform, Load (извлечение, трансформация, загрузка).