Оценивать эффективность ИТ-проектов в деньгах обычно не получается: чаще всего у клиентов нет данных о состоянии «до автоматизации». С BI-проектами дело обстоит еще хуже, чем «в среднем»: оценивать качество решений никто не берется, а именно за него чаще всего идет борьба. С другой стороны, в последнее время самой востребованной при создании аналитических систем оказывается подготовка обязательной отчетности, особенно в банках, но ни о чем другом речь уже не идет. Однако все же появляются примеры построения хранилищ данных, эффективность которых владельцы оценивают, причем основной эффект достигается на направлениях, никак с внешней отчетностью не связанных. Таким опытом поделился Олег Амурский, начальник отдела клиентской информации и бизнес-аналитики банка ВТБ24 на пятом форуме Business Intelligence, проведенном компанией AHConferences в октябре в Москве.
Цели, ход и результаты проекта
Основными целями создания хранилища клиентской и аналитической информации (ХКАИ) в ВТБ24 были консолидация управленческой отчетности с использованием единой терминологии и методик и информационно-аналитическая поддержка деятельности банка для повышения качества принимаемых решений. Предполагалось также упорядочить и унифицировать методы управления данными и обеспечения качества информации. Для всего этого в банке были намерены внедрить промышленное интегрированное решение в качестве технологической платформы ХКАИ, используя стандартную отраслевую модель данных.
При этом планировалась экономическая отдача за счет следующих факторов. Проект системообразующий, повысит капитализацию, а также улучшит качество решений и скорость их принятия. Предполагалось увеличение объема продаж за счет применения аналитического CRM. Прямой экономический эффект в целом по банку ожидался на уровне 7—10 млн долларов в год, преимущественно за счет сокращения трудозатрат по подготовке данных, формированию и проверке отчетности, сокращению дублирующих функций. И это действительно произошло, свидетельствует Олег Амурский.
Проект был разбит на два этапа. Первый продлился с декабря 2007 по декабрь 2008 г. включал в себя построение базиса ХКАИ, выбор платформы реализации и модели данных. В это же время были построены витрины CRM для решения задач клиентской аналитики, запущенные в эксплуатацию в июне 2008 г. Одновременно построены витрины финансово‑управленческой отчетности, создана модель детального слоя данных на базе отраслевой модели, поставляемой в решениях компании SAS для банковского бизнеса (включает 163 таблицы, 1491 поле, 84 справочника), налажена загрузка данных из систем-источников.
Второй этап включает развитие, расширение модели данных и состава источников. Он идет и в настоящее время. В нем реализуется централизация отчетности подразделений, перенос отчетности из учетных систем, поддержка бизнес-инициатив, в том числе бонусного механизма, CRM как канала коммуникации, оптимизация процедур обработки и хранения данных. Именно на задаче централизации и результатах ее решения Амурский и сосредоточился в своем докладе.
Те данные и информация, которые уже содержались в хранилище, позволили в 2009 году организовать процесс централизации отчетности подразделений практически по всему банку силами управления финансовой отчетности. При этом рассматривались три сценария. Первый — забрать всю отчетность «как есть» и реализовать в том виде, в каком ее привыкли видеть бизнес-подразделения. Недостаток этого сценария — большие трудозатраты по повторению всех форм. Кроме того, было много дублирования: у разных подразделений отчеты об одном и том же. Отчет по заявкам, отчет по продажам, отчет по портфелю, отчет по рискам каждое подразделение готовило самостоятельно. Отчеты, несмотря на внешние отличия отдельных форм, по сути, отличались только тем, что на одну и ту же информацию накладывались разные фильтры. Поэтому рассматривался и второй сценарий — представление отчетных форм в более-менее привычном виде с сохранением статичных форм. Минус — высокие затраты на создание статичных форм, отсутствие возможности для пользователей строить нестандартные срезы. В итоге, рассказывает Олег Амурский, был выбран третий подход, полностью основанный на OLAP-кубах и на сводных таблицах. Трудозатраты на реализацию такого механизма в банке сочли наименьшими. К его минусам можно отнести определенные сложности для пользователей, связанные с переходом на новые формы предоставления информации, плюс потеря некоторых показателей на первом этапе, до момента их появления в ХКАИ. Подход подразумевал единство предоставления информации, динамичные формы, позволяющие самостоятельно вести навигацию. В качестве основного исполнителя в банке выбрали внешнего подрядчика — АРСТЕЛ — Консалтинг. В качестве платформы использованы продукты SAS. База данных для детального слоя хранилища — Oracle, поскольку именно эта база — стандарт хранения данных в ВТБ24.
Основной бизнес-результат проекта заключается в возможности запуска CRM-компаний, построения сегментов, которые раньше выделить было невозможно. Ведь информация была разрозненной, информация об отдельных продуктах и услугах содержалась в разных местах.
С лета 2008 г. такие компании запускают постоянно, рассказывает Амурский. Именно за счет CRM-компаний, по методике, разработанной финансовым департаментом, за период с начала эксплуатации по август 2009 г., по его словам, достигнута полная окупаемость проекта, с учетом расходов на услуги подрядчика и на инфраструктуру. СМС-информирование о предстоящем платеже по всем кредитным продуктам, включая карты, привело к снижению технической просрочки на 15%, и этот показатель растет, подчеркивает Амурский. На базе централизованного хранилища стали возможны поиск и идентификация клиента, отображение его продуктов, счетов в разных системах. Это позволило сделать единый интерфейс для построения отчетов и запросов в целом по всем клиентам, выполнение запросов, поступающих от регулирующих и надзорных органов. На этой же базе реализованы витрины данных для Управления проблемных кредитов (залоги, заявки, просрочка, платежи в погашении кредитов, работа с коллекторами). Бонусные программы и программы лояльности проходят бизнес-тестирование, технически они уже реализованы.
Риски и их минимизация
Амурский рассказал о рисках этого проекта и о том, как их пытались минимизировать. Риски качества данных оказались, как и можно предположить, наиболее существенными из реализовавшихся. Так, ошибки ввода исходных данных и отсутствие контроля в учетных системах приводят к периодической необходимости ручного вмешательства в процессы загрузки данных. Особенности реализации новых банковских продуктов приводят к дополнительным трудозатратам по реализации обработки данных в ХКАИ. Если не реализуется четкий процесс ведения НСИ, то запаздывает поступление информации в ХКАИ, и разработанные отчеты периодически не сходятся с контрольными.
Что со всем этим делать? Оптимизировать процессы обработки данных, чтобы сделать их менее чувствительными к ошибкам, активизировать обратную связь с ответственными для исправления ошибок, определить владельцев НСИ и регламента ее актуализации, придерживаться единых прозрачных подходов при реализации доработок в АБС. Надо сказать, что большинство вопросов к этому докладу было связано именно с качеством данных и борьбой за него. В качестве возможных шагов Олег Амурский упомянул оргмеры в виде более жестких регламентов, которые определяют процесс ввода информации, доработки исходных систем по вставлению дополнительных функций контроля. Самый принципиальный вопрос — повышение качества данных как в хранилище, так и в источниках, считает Амурский: «Здесь мы опираемся на результаты контрольных процедур, которые проводятся в хранилище. На базе логов, таблиц и контрольных отчетов и выстроен механизм обратной связи с подразделениями, ответственными за ввод и качество информации».
Риски проектного решения тоже дали о себе знать. Выяснилось, что реализация части логики организации данных в модели детального слоя данных (например, в части хранения исторических данных) требует реорганизации и дополнения.
Реализация части алгоритма преобразования данных была признана ДИТ (департамент информационных технологий) требующей оптимизации. Текущее исполнение приводит к повышенным требованиям к ресурсам системы, а также затрудняет сопровождение. Появляется риск нестабильности функционирования.
Реализация рисков повлекла, разумеется, задержку сдачи результатов работ в эксплуатацию, задержала второй этап работ, повысила трудозатраты на сопровождение системы и вызвала трудности приемки системы на сопровождение в ДИТ. Чтобы не дублировать подготовку отчетности, выстроен процесс, в рамках которого большинство сложных отчетных форм формируются на базе ХКАИ, и фактически процесс выполняет только одно управление в банке. Важно, что в ВТБ24 есть такое выделенное подразделение, отвечающее за BI. Это подразделение финансовой и аналитической отчетности, оно входит в финансовый департамент, отвечает за сбор требований и приоритезацию задач развития хранилища, за организационные процессы и поддержку пользователей. Сюда входят регистрация обращений пользователей, анализ их запросов по поддержке регулярной отчетности, построенной на базе OLAP-кубов, фиксированных отчетных форм. Поддержка отвечает за корректность информации в отчетах и на витринах данных, принимает запросы на изменение существующих отчетов и создание новых, на выборку информации из витрин данных. Эта же служба вносит изменения и создает отчеты и алгоритмы в рамках существующего функционала.
Загрузка актуальных данных различна для двух существующих потоков данных: по открытому дню и по закрытому дню. Первый поток загружается в хранилище на следующий день. Сегодня доступна определенная информация о событиях, произошедших вчера. Данные по закрытому дню доступны через три — пять дней. За этот срок закрывается баланс дня в целом по банку, и потом данные поступают в хранилище.
Направления дальнейшего развития
Намечены, говорит Амурский, обширные планы на 2010 г. по развитию хранилища, в том числе интеграция новых источников, расширение состава информации. Отдельная задача — миграция с других, уже существующих в банке отчетных систем на платформу ХКАИ. Есть и другое направление — информация для топ-менеджмента. «В первую очередь мы обеспечили информацией средний менеджмент, аналитиков, операционных работников. Для топ-менеджмента формируются сводные агрегированные отчеты, которые доставляются прямо в почтовый ящик. Внедрение эффективных KPI на этих данных пока в разработке, на этапе сбора требований к этим показателям, — говорит Олег Амурский. — Планируем и дальше развивать хранилище, так как оно уже на рубеже 2008 г. дало убедительные экономические результаты. Продолжим развивать клиентскую аналитику, выделение сегментов, предложение карт и кредитов, сервисных компаний уведомления о платежах, причем развитие планируется в тех же масштабах, что и раньше. Бюджет этого проекта не сокращен. Параллельно с развитием ХКАИ в 2010 г. намечен первый этап создания онлайн-хранилища данных на базе новой технологической платформы, предназначенного в первую очередь для задач операционного CRM».
Тенденции развития технологий и продуктов для бизнес-анализа
Ян Шимек,
вице-президент Teradata в Восточной ЕвропеЧтобы быть конкурентоспособным, бизнесу нужно знать ответы не только на вопросы «что произошло», «почему произошло», «что произойдет завтра», но и на вопрос «что происходит сейчас». Поэтому растет потребность в оперативной аналитике.
Следующим логичным шагом станут активные действия, которые бизнес сможет предпринять на основе оперативного анализа. Суть оперативной аналитики заключается в применении стратегической аналитики к оперативным системам и процессам там, где это может оказать влияние на текущее развитие бизнеса.
Это станет следующим этапом развития традиционной аналитики: на ее основе принимаются тактические решения, а скорость может доходить до тысячи решений в минуту. Ее пользователями становятся сотрудники «на передовой», например, операторы call-центра, которые, принимая звонок клиента, видят всю историю и профиль клиента на мониторе компьютера. Одновременно система анализирует данный профиль и может в режиме онлайн рекомендовать оператору сделать этому конкретному клиенту индивидуальное выгодное предложение.
В основе построения системы оперативной аналитики — активное хранилище данных. Оно поддерживает принятие тактических решений при помощи быстрых тактических запросов и вместе с тем позволяет решать задачи стратегической и оперативной аналитики. Частота обновления данных в таком хранилище является критичной, поскольку решения принимаются в режиме реального времени.
Растет и потребность в аналитических инструментах, способных обрабатывать геопространственные данные. Около 80% всех корпоративных данных имеют привязку к определенному местоположению. Компании начинают осознавать потребность в эффективном использовании ГИС-данных для решения собственных бизнес-задач.