Как реализовать BPM-проект в банке

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

Проект - инициатива топ-менеджмента

Решение о внедрении BPM-системы принимает руководство. Даже если проект был инициирован ИТ-подразделением и систему выбирали ИТ-специалисты, последнее слово все равно должно оставаться за бизнесом. Поэтому на этапе принятия решения нужно донести до основных потребителей информацию о возможностях управленческой системы и заинтересовать бизнес-подразделения в проекте. При этом необходимо провести презентацию системы на различных уровнях: для руководства и бизнес-подразделений. Можно сделать референс-визит в банк, который использует предлагаемую систему. Если положительное решение по проекту принято, то первым шагом к успеху проекта может стать назначение куратора из числа первых лиц банка. Он должен обладать необходимыми полномочиями на предоставление финансовых и трудовых ресурсов для решения задач проекта.

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

Бизнес-пользователи во главе угла

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

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

Например, при реализации каждого этапа BPM-проекта в «Еврофинанс Моснарбанке» (ОАО АКБ «Еврофинанс Моснарбанк») создавалась проектная группа из представителей банка и компании-разработчика системы. Так, перед началом этапа автоматизации подготовки налоговой отчетности была сформирована группа, в которую со стороны банка вошли главный бухгалтер (в качестве куратора проекта), ИТ-специалист (как руководитель проекта), а также сотрудники отдела налоговой отчетности. Со стороны разработчика в проекте выступали руководитель проекта, аналитики проекта, а также программисты. Сотрудники банка принимали участие в постановке, согласовании и утверждении технического задания, а разработчик готовил ТЗ и настраивал бизнес-приложения.

Определиться с приоритетами

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

Часто предпроектное обследование путают с разработкой технического задания. Но подготовка ТЗ – это отдельный проект, который предполагает описание физической реализации модели данных банковского хранилища и настроек прикладной функциональности. Приступают к нему только после определения бизнес-требований и при наличии проработанных управленческих методик. Имея на руках документ с бизнес-требованиями, можно еще до начала проекта оценить масштабы предстоящих работ и затрат, а главное – рассчитывать на получение ожидаемого результата. В «Еврофинанс Моснарбанке» (ОАО АКБ «Еврофинанс Моснарбанк»), к примеру, введена практика делить проект на две части: сначала составляются и согласовываются бизнес-требования, на основании которых затем пишется ТЗ для настройки прикладных решений.

От простого к сложному

Приступая к ВРМ-проекту, можно рассчитывать на то, что в конечном счете удастся автоматизировать комплекс управленческих технологий: планирование и бюджетирование, управление доходностью и рисками, подготовку отчетности по МСФО и РПБУ и др. Однако не стоит одномоментно браться за решение всех задач, иначе есть риск не справиться ни с одной из них. Лучше разбить большой проект на несколько подпроектов и начать с приоритетной задачи. Например - автоматизировать бюджетирование хозяйственных расходов, а после ввода в эксплуатацию этого модуля BPM-системы приступить к реализации технологии подготовки управленческой отчетности.

Поэтапное внедрение системы позволит быстрее получить отдачу. Кроме того, персоналу будет проще постепенно осваивать  новые инструменты. Опыт показывает, что каждый подпроект должен иметь обозримые сроки, не превышающие 6 месяцев. Если результаты подпроекта будут заметны по окончании этого периода - лояльность руководства и сотрудников банка к дальнейшему развитию BPM-проекта будет обеспечена. Представить новые возможности решения проектная команда может, не дожидаясь окончания внедрения. Проведение демонстраций после реализации каждого значимого этапа работ будет подогревать интерес к проекту - как со стороны руководства, так и со стороны непосредственных пользователей. В результате проектная команда своевременно сможет получить «обратную связь» и заручиться поддержкой коллег из разных подразделений банка.

Если говорить о проекте в «Еврофинанс Моснарбанке» (ОАО АКБ «Еврофинанс Моснарбанк»), то поэтапный подход к построению системы оправдал себя. За полгода было внедрено хранилище данных, за такой же срок был автоматизирован управленческий учет, а первые пользователи приступили к работе с системой через год после начала проекта.

Проект, который невозможно завершить

Хранилище данных  не относится к категории «коробочных» решений, которые можно купить, внедрить, а дальше - только поддерживать. Система будет постоянно развиваться: необходимо будет расширять состав данных для сбора в хранилище, число учетных систем, с которыми его нужно будет интегрировать, будут совершенствоваться управленческие технологии банка. Поэтому важно, чтобы банк имел возможность выделить ИТ-специалистов, которые будут постоянно работать над проектом.

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

В «Еврофинанс Моснарбанке» (ОАО АКБ «Еврофинанс Моснарбанк») работы над проектом велись с 2004 года. Сначала была решена задача сбора данных бухгалтерского учета из АБС головного офиса и филиалов, автоматизирован расчет управленческой отчетности на основе этих данных. С 2005 года бизнес-пользователи стали выпускать отчетность по клиентам. В 2006 году был начат сбор данных по сделкам с клиентами. В 2007 году банк автоматизировал бюджетирование хозяйственных расходов. В настоящее время к завершению подходит этап автоматизации налогового учета, идет автоматизация подготовки обязательной отчетности по РПБУ. А в дальнейшем планируется внедрить технологии финансового планирования, трансфертного управления ресурсами, управления ликвидностью и операционными рисками.

Витрины данных

Пользователи бизнес-подразделений ожидают от управленческой системы, в первую очередь, быстрого получения необходимых отчетов. Лучшее решение для оперативного выпуска отчетов – это тематические витрины данных. Для каждого подразделения формируются индивидуальные витрины с выборками данных из хранилища. Обращаться с витриной, которая содержит только интересующие показатели, удобно – как с точки зрения скорости отклика, так и с позиции разграничения доступа к данным специалистов разных подразделений и уровней. Можно моментально увидеть только требуемый набор показателей за месяц, квартал, год.

В «Еврофинанс Моснарбанке» (ОАО АКБ «Еврофинанс Моснарбанк») подобный подход и был использован. Были созданы так называемые «микрокубы» – витрины данных для семи различных отделов и управлений.

Каждый день из хранилища выгружаются данные для нескольких десятков автономных микрокубов, предназначенных для разных подразделений банка. Применение витрин данных избавило банк от проблемы снижения производительности программного комплекса при массовом обращении к отчетам. Работа с витриной осуществляется с помощью OLAP-интерфейса, в котором пользователи могут интерактивно управлять формой отчетов без программирования. Для просмотра витрин данных было создано 25 рабочих мест, с помощью которых руководство, среднее управленческое звено, аналитики выпускают более 100 отчетных форм. В настоящее время технология начинает распространяться и на филиалы.

Все по полочкам

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

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

Существует распространенное мнение, что в хранилище надо сложить все, что есть в банке, а там видно будет, как эти данные использовать. Но результатом такого решения может стать огромная «свалка» данных, которая не будет приносить банку никакой пользы. Избежать этого можно до начала создания хранилища - еще на этапе формирования бизнес-требований к ВРМ-системе. Они станут основой для разработки технического задания на настройку модели ХД, которое обеспечит решение действительно актуальных задач, которые стоят перед банком, причем в разумные сроки и с ожидаемым результатом.

Жизнь вносит свои коррективы

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

Скупой платит дважды

Не стоит закрывать глаза на то, что создание хранилища данных требует серьезных затрат. Помимо приобретения дорогостоящего программного обеспечения для построения хранилища и автоматизации управления, потребуется мощная аппаратная платформа с большим объемом дискового пространства. На сервере ХД будут храниться данные всех филиалов и дочерних банков. Кроме того - должно оставаться место для резервного копирования базы, для тестирования внешних решений и собственных разработок.

По опыту «Еврофинанс Моснарбанка»(ОАО АКБ «Еврофинанс Моснарбанк»), ежегодно объемы данных хранилища растут на 50%. Рассчитывая объем необходимого дискового пространства, надо учитывать предполагаемый ежегодный прирост объема данных, а после всех прикидок умножать эту цифру на три. При реализации проекта также возникнут затраты на консультационные услуги по постановке методологий управления кредитного учреждения. Не стоит забывать и о затратах на квалифицированную команду сопровождения проекта.

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