Рынок Вusiness Performance Management (BPM) с легкой руки авторитетного мирового эксперта Крейга Шиффа повернулся к потребителям своей новой гранью: в фокусе — культурный аспект управления эффективностью, или, если коротко, культура эффективности. Что это — очередной маркетинговый ход или уже сигнал о том, что пришло время снять розовые очки и по-новому взглянуть на результаты ВРМ-проектов последних лет?
По данным Gartner, объем мирового рынка ВРМ по итогам 2010 г. составил 2,167 млрд. долл., а его рост — 12,8%. На фоне крепнущей зрелости этого ИТ-сегмента за рубежом отечественная статистика свидетельствует, что как минимум каждый третий российский банк из Топ-50 имеет негативный опыт внедрения хранилищ данных/ВРМ-систем, а в каждом четвертом банке одновременно эксплуатируется несколько хранилищ/витрин данных от разных поставщиков, отвечающих за решение отдельных прикладных задач. Это означает, что по крайней мере половину из реализованных ВРМ-проектов нельзя считать полностью успешными.
Однако успех — категория относительная, и канонических критериев его измерения попросту нет. Поэтому каждый заказчик соотносит сначала планы, а потом и достигнутые результаты проекта с собственным пониманием того эффекта, который может принести банку автоматизированная система управления эффективностью бизнеса. Потребительские ожидания опираются на существующий уровень понимания методологических, технологических и организационных аспектов ВРМ, т. е. на культуру эффективности.
Рассмотрим гипотетический случай: банк приобрел мощную в технологическом смысле ВРМ-систему, но у заказчика не принята методика аллокаций накладных расходов. Какой бы продвинутой ни была функциональность для прямого и косвенного разнесения затрат на центры прибыли, без методологии она не будет востребована, и задействовать систему на полную мощность не получится.
Недостаточный уровень проработки управленческих методологий — только один из примеров дефицита культуры эффективности. Устранение подобных недоработок будет способствовать извлечению максимальной выгоды от применения ВРМ-системы. Факторы успеха ВРМ-проекта не ограничиваются качеством программного продукта и авторитетом его поставщика, успешность всего комплекса работ в значительной мере определяется именно культурой эффективности. Среди ее слагаемых — и степень подготовленности заказчика к проекту, и “правильность” клиентских ожиданий в отношении результатов создаваемого решения, и понимание необходимости выстраивать наряду с ИТ-составляющей проекта методологии и регламенты управленческих процессов, а также много других важных моментов.
Стратегическое видение и детальный план
Как известно, концепция ВРМ охватывает комплекс управленческих процессов — от планирования стратегии, выраженной в значениях KPI, до их мониторинга и контроля с помощью измерения эффективности на тактическом, и операционном уровнях. При этом центральная задача ВРМ — обеспечить прямую и обратную связь управления на всех уровнях.
Последние годы в российских банках, по оценке компании Intersoft Lab (см. рисунок), были наиболее востребованы элементы управления эффективностью на тактическом уровне. Речь идет о бюджетировании, финансовой консолидации и подготовке регуляторной отчетности. Сегодня спрос акцентирован на управлении операционной эффективностью, т. е. оценке и контроле доходности бизнес-направлений, подразделений, банковских продуктов. Инструменты управления на стратегическом уровне — решения для долгосрочного планирования, моделирования и контроля ключевых показателей эффективности (Key Performance Indicators, KPI) — не пользуются спросом и практически не развиты. В итоге оценки эффективности, полученные на операционном и тактическом уровнях, не согласуются с KPI.
В проектной практике это выглядит как решение локальных задач ВРМ. Например, открывается проект по автоматизации подготовки управленческой отчетности. Инициатором выступает конкретное подразделение, например отдел подготовки управленческой отчетности в составе финансового департамента банка. Получив нужный ему функционал, “локальные заказчики” считают задачу выполненной. В результате внедренное решение остается в пользовании исключительно этого одного небольшого структурного банковского подразделения и не распространяется дальше.
Как достичь интеграции всех аспектов ВРМ и получить максимальную пользу от системы? Для этого необходимо еще до старта проекта видеть будущую ситуацию с управлением эффективностью в банке в целом, а не только в том небольшом “круге света”, который ограничен интересами одного конкретного отдела банка. Чтобы сформировать гармоничное стратегическое видение, требуется выяснить ожидания от проекта разных банковских подразделений и согласовать их. Как правило, такая задача решается в рамках предпроектного обследования, которое целесообразно поручить внешнему по отношению к банку исполнителю. В отчете по итогам предпроекта фиксируется текущее состояние методологий и технологий управления эффективностью в банке (“как есть сейчас”) и взаимоувязанные ожидания потенциальных пользователей и топ-менеджеров от внедрения ВРМ (“как должно быть”). Именно сложностью взаимоувязывания продиктована рекомендация пригласить для решения этой задачи внешнюю компанию, которая может стать своеобразным громоотводом при принятии решений, затрагивающих интересы разных подразделений.
Важнейший результат обследования — план реализации проекта, который рассчитан в среднем на 2—4 года. Целесообразно выделять в плане два уровня: стратегический — для лиц, принимающих решения, и детальный — для ответственных исполнителей. План стратегического уровня позволяет “единым взглядом” оценить технологическую карту воплощения стратегического видения в жизнь, последовательность и сроки получения значимых для банка результатов проекта. В детальном плане отражены все шаги практической реализации проекта.
Применение подобного подхода позволит избежать ошибки, которая может стать губительной для масштабного проекта. Я говорю о нестыковке потребительских ожиданий и восприятия результатов проекта. Осознание того, какая пропасть их разделяет, наступает, к сожалению, уже после внесения львиной доли инвестиций и выполнения большей части работ. Комплексное стратегическое видение и четкий план реализации ВРМ-проекта должны быть актуальны на всех его этапах — это фундамент успеха. Если в ходе выполнения проекта придет новое видение, его необходимо также зафиксировать, реструктурировать проект и откорректировать план на стратегическом и детальном уровнях.
Диагностика и документирование методологий управления
Промежуточным слоем между видением проекта и его воплощением в настройки ВРМ-системы является методология финансового управления банком, т. е. набор положений, инструкций, регламентов и других внутренних нормативных документов банка, определяющих организацию управления эффективностью.
Несмотря на то что управленческие процессы исполняются постоянно, изо дня в день, методологические наработки часто не документируются, знания распылены между сотрудниками и Excel-таблицами, с которыми они работают. Каждый исполнитель знает о каких-то определенных узких местах в алгоритмах, отчетных формах, организационных регламентах, но в повседневной текучке расшивать их им просто некогда. А когда дело доходит до автоматизации, то всякого рода мелкие методологические пробелы оборачиваются серьезной причиной пробуксовки проекта.
В то же время многие банки связывают с ВРМ-проектом свои ожидания в отношении разработки и внедрения новых методик управления и выпуска внутренней отчетности либо модификации существующих. Это естественное и своевременное пожелание, однако следует помнить, что ВРМ-платформа — только инструмент для ИТ-поддержки управленческих процессов, а один инструмент, сколь бы совершенен он ни был, не создаст правильный управленческий процесс. Здесь важнее опыт и навыки исполнителей, а не характеристики ИТ-системы.
Подготовка методологической базы банка к автоматизации — отдельная задача, к решению которой следует приступать на стадии предпроектного обследования. Наряду с изучением ИТ-инфраструктуры банка и разработкой предложений по интеграции в нее ВРМ-системы, в ходе предпроекта нужно оценить управленческие процессы и уровень их документирования. Диагностика начинается с исследования действующих нормативных документов и проведения глубинных интервью с руководителями и сотрудниками финансовых департаментов с целью формулирования требований к будущим методологиям финансового управления банком и подготовки плана перехода от текущего состояния методологий к целевому. Одновременно необходимо учитывать возможности конкретной ВРМ-платформы по поддержке будущей методологии. Оказать банку такую услугу могут квалифицированные консультанты-методологи, профессионально владеющие выбранными банком инструментами автоматизации ВРМ.
Парадокс ситуации на российском рынке заключается в том, что на фоне количественного роста ВРМ-проектов круг специалистов, сочетающих перечисленные навыки, очень ограничен. Консалтинговые компании не владеют ИТ-инструментарием, а знаний внедренческих фирм недостаточно для методологического консультирования. Исключение составляют специализированные компании-разработчики ВРМ, причем только в том случае, если в их арсенале имеется достаточный практический опыт проектного сотрудничества с отечественными банками.
Распределение задач между АБС и ВРМ
Неожиданно, но факт: российские банки по-прежнему испытывают трудности при распределении функциональности между автоматизированной банковской системой (АБС) и ВРМ-системой на основе хранилища данных (ХД). Казалось бы, никто не спорит, что создание исходных данных — традиционная функция систем оперативного учета, а хранение данных и подготовка различной банковской отчетности — прерогатива решений на основе ХД. Неоднозначность возникает в связи с активным переходом банков к использованию централизованных АБС, а также сложностями в обеспечении качества данных для отчетности.
Действительно, при эксплуатации в банке централизованной АБС от одного поставщика несложно представить в одном отчете данные из разных учетных модулей, например по операциям с юридическими и физическими лицами. Однако доступ к тем же данным, но за архивные периоды либо вообще отсутствует в АБС, либо будет неприемлемо медленным. В ХД надлежащий срок отклика системы достигается за счет партиционирования данных по времени.
Проблемы с производительностью АБС возникнут также при использовании ресурсоемких алгоритмов расчетов. Например, чтобы выполнить в АБС поэтапную обработку разнородных данных для расчета обязательных нормативов банка, необходимо блокировать весь состав данных на период выполнения всех этапов расчетов. Это приведет к остановке работы пользователей АБС по внесению изменений в данные. Поэтому сложные формы финансовой отчетности целесообразно переносить на платформу ХД. А вот оперативную отчетность по требованиям Положения Банка России № 302-П, для формирования которой необходимы только данные Главной книги, разумнее выпускать непосредственно из АБС. Это сэкономит время получения результата, ведь ХД чаще всего работает с данными, дата актуальности которых “Д+1”.
АБС, ориентированная на поддержку текущей деятельности банка, не обеспечит сохранения истории данных и метаданных, которые нужны для построения сложных форм регуляторной и финансовой отчетности. А вот ХД фиксирует состояние данных, их структур, расчетных алгоритмов и отчетных форм на каждый момент времени. Так, если в правила трансформации данных в регистры управленческого учета изменения внесены со II квартала, то в апреле можно выпустить управленческую отчетность за январь — март по действовавшей ранее методологии, а отчетность за текущие даты будет соответствовать актуализированным требованиям.
Действительно сложной и практически всегда индивидуальной является выработка правил заполнения атрибутов данных для более детального раскрытия информации в отчетах. Практически всегда исходным данным, поступающим в ХД из АБС, недостает аналитических признаков, необходимых для подготовки отчетов. Их можно вводить как в АБС, так и в ХД — главное, чтобы в АБС проставление дополнительной аналитики не повлияло отрицательно на скорость обслуживания клиентов и выполнение основных операций. Так может произойти, если, например, поручить операционистам при вводе лицевых счетов маркировать их признаками статей управленческого учета. Такой подход, особенно при внесении изменений в методологию управленческого учета, потребует работы по смене признаков в АБС, что существенно усложнит ее эксплуатацию. Заложить основу для формирования требований к ведению учета в АБС также стоит в рамках предпроектного обследования.
Если ошибки, вызванные недостаточным качеством данных, обнаруживаются на заключительных этапах подготовки отчетности, то правильнее будет использовать механизмы оперативного внесения корректировок непосредственно в готовые отчеты в ХД с последующим сохранением значений корректировок и “правленых” версий отчетов.
Таким образом, еще на предпроектном этапе необходимо выработать оптимальный подход к распределению функциональности по сбору, хранению и обработке данных для подготовки отчетов между АБС и ХД. Это позволит выпускать банковскую отчетность в минимальные сроки, с минимальными затратами на создание и сопровождение решения, с минимальными операционными рисками.
Технологические компоненты ВРМ
Недавняя консолидация рынка BI и BPM, насаждавшая моновендорный подход к построению систем управления эффективностью, сегодня уступает место концепции best of breed, которая предполагает комбинирование лучших в своем классе программных продуктов при создании экземпляра ВРМ-системы для конкретного заказчика.
Напомним, что укрупненная архитектура ВРМ-системы включает три слоя (снизу вверх): слой консолидации и хранения данных, слой ВРМ-приложений и слой инструментов бизнес-аналитики и подготовки отчетности . Если использование разных BI-инструментов в составе комплексной системы стало уже нормой в большинстве крупных организаций, то разделять требования к поставщикам хранилищ данных и прикладных решений готовы далеко не все. Вместе с тем немногие поставщики предлагают весь комплекс ВРМ-приложений, в то время как их специализированные решения могут быть лучшими в своем классе (как, например, приложения SAS OpRisk Management). Не секрет, что до сих пор в мире ограничено число поставщиков приложений для управления доходностью. В текущих условиях, когда интеграция перестала быть проблемой, банки могут выбрать лучшие прикладные решения, чтобы удовлетворить свои специфические требования. Например, в составе ВРМ-платформы “Контур” (разработка Intersoft Lab) представлены приложения для ведения управленческого учета и подготовки отчетности по МСФО. Но в рамках стратегического видения системы управленческой и финансовой отчетности Группы ММВБ архитектура решения объединила витрину финансовых данных, разработанную на ВРM-платформе “Контур”, и приложения Oracle Hyperion Planning и Oracle Hyperion Financial Management от мирового лидера ВРМ-индустрии корпорации Oracle.
Те же принципы применимы и к выбору поставщика хранилища данных — основы ВРМ-системы. На уровне ХД решаются две основные задачи: обеспечение оптимальной структуры хранения и обеспечение надлежащего качества данных. Модель данных финансового ХД определяет состав объектов хранения, их атрибуты, взаимосвязи и т. д. Она должна гарантировать полноту данных для решения всего комплекса ВРМ-задач, поддерживать особенности ведения бухучета и подготовки регуляторной отчетности для Банка России, обеспечивать приемлемую скорость получения данных и отчетов из ХД.
Принципиальное требование к поставщику ХД — предоставление описания модели данных. Это позволит сотрудникам банка самостоятельно строить новые виды отчетности из хранилища. В ВРМ-проекте особенно важно, чтобы заказчик доверял данным в ХД, иначе использование системы так никогда и не начнется. Достичь этого поможет применение программных средств класса Data Quality на уровне интеграции хранилища с источниками данных, а также специальных инструментов ХД. Стоимость компонентов Data Quality в составе интеграционных пакетов разных поставщиков сегодня по-прежнему высока, однако наблюдается определенная тенденция к ее снижению, к тому же отдельные вендоры предлагают lite-версии своих инструментов. Качество данных становится доступнее, хотя интеграция и Data Quality пока еще остаются основными статьями экономии в ВРМ-проектах.
Организационный аспект
Внедрение ВРМ практически всегда ведет к организационной перестройке в банке. В первую очередь это касается изменений в регламентах процессов учета и управления. Автоматизировать хаос нельзя. Процессы надо описать на бумаге, закрепив документально ответственность и механизмы контроля над исполнением. Например, если регламенты ввода и проверки данных отсутствуют, то наладить выпуск отчетности невозможно. Потому что ни одно подразделение или исполнитель никогда “за просто так” не возьмут на себя дополнительную нагрузку и ответственность за качество данных. Часто единственный способ запустить новые или модифицировать устоявшиеся процессы — использование административного ресурса. Это должно быть ожидаемым и подготовленным событием на всех этапах разворачивания ВРМ-проекта.
Автор статьи — эксперт Ассоциации российских банков, заместитель генерального директора компании Intersoft Lab по развитию бизнеса.
*Продолжение цикла статей: “Системы управления эффективностью бизнеса для российских банков” — PC Week/RE, № 26/2006www.pcweek.ru/idea/article/detail.php?ID=72866; “Управление эффективностью бизнеса в российских банках” — PC Week/RE, № 40/2007; “Управление эффективностью банковского бизнеса в условиях кризиса” — PC Week/RE, № 41/2008; “Управление эффективностью банковского бизнеса после кризиса” — PC Week/RE, № 47/2010.
