Хранилище данных как средство от кризиса

В условиях финансового кризиса банки вынуждены минимизировать расходы. В такой ситуации фактор стоимости внедрения и поддержки системы хранения данных становится критичным, при том, что получить с помощью хранилища данных базу знаний, которая поможет принять правильное решение – задача сама по себе непростая. Сегодня разработчики ПО предлагают различные подходы к ее реализации - от локальных решений на уровне подразделений до полнофункциональных интегрированных систем управления эффективностью бизнеса (Business Performance Management, ВРМ).

Один из вариантов предполагает создание небольших хранилищ данных (ХД) или витрин данных для конкретных подразделений. Такие ХД содержат узкий набор данных и 5-6 показателей для решения аналитических задач одного подразделения. Например - только данные по клиентам для sales-менеджеров или показатели управленческого баланса для финансовой службы. Это более быстрый и простой способ предоставить конечным бизнес-пользователям необходимую информацию, однако он не позволяет согласовать данные в витринах для разных подразделений. А значит, не исключена вероятность возникновения расхождений и ошибок в анализируемых показателях.

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

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

На что способны хранилища данных

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

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

Эксперты в качестве необходимой функциональности BPM-пакетов выделяют следующий состав приложений: планирование/прогнозирование и бюджетирование, управление доходностью, финансовая и обязательная отчетность, финансовая консолидация. Все эти задачи, по их мнению, следует решать на основе единой финансовой модели организации. Аналитики IDC убеждены, что все приложения должны быть согласованы. В рекомендациях Gartner указано, что согласование должно быть на основе финансовой модели «для бюджетирования, планирования и прогнозирования баланса, отчета о прибылях и убытках и отчета о движении денежных средств».

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

Скорость и последовательность

Хранилище данных ВРМ-системы не универсальное хранилище, в котором сохраняются буквально все бизнес-данные организации, но и не витрина для 5-6 показателей. В банках такое решение применяется для поддержки управления, анализа и подготовки отчетности и опирается на отраслевую методическую модель. Строить ХД для ВРМ надо последовательно, исходя из стратегических приоритетов бизнеса. Это позволяет существенно сократить сроки проекта и быстрее получить отдачу от автоматизации. Масштабные проекты внедрения ВРМ-систем на основе ХД выполняются поэтапно, где каждый этап решает отдельную прикладную задачу на необходимом составе данных.

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

Построение хранилища данных на основе готовой модели управления выглядит следующим образом. Для решения первоочередной бизнес-задачи из альбома шаблонов отчетности выбираются нужные отчеты, затем определяется состав методик, которые позволяют их получить, а также та часть словаря данных, которой достаточно для формирования отчетов. Например, для решения задачи получения единого реестра клиентов банка требуется собирать в ХД определенный набор информации о клиентах, выполнять процедуры очистки, поиска дублированных записей о клиенте, выявления аффилированности и др. Для этого устанавливается специальная часть словаря данных хранилища под названием «Реестр клиентов» (витрина данных, куб). После отладки сбора данных в ХД по клиентам и процедур выверки эта функциональность может эксплуатироваться в промышленном режиме. Затем можно реализовать новую задачу – например, получение обязательной отчетности на основе данных бухгалтерского учета. Теперь внедряется часть словаря «Главная книга», обеспечивается сбор и выверка данных бухучета в ХД, а затем инсталлируется приложение «Отчетность для Банка России». Оно разворачивает витрину данных для хранения показателей обязательных отчетных форм и устанавливает механизмы расчета показателей по данным Главной книги, а также механизмы выпуска отчетов в формате kliko. Когда будет отлажена и передана в эксплуатацию эта функциональность, можно приступать к следующей.

Таким образом, создается одно хранилище данных и несколько связанных с ним прикладных витрин данных (кубов). При этом сначала создается ХД на основе необходимой части словаря данных, обеспечивается сбор данных, разворачиваются витрины, а для следующей задачи к уже созданному решению присоединяется новая часть словаря.

Витрины и хранилище: вместе или отдельно?

Использование витрин данных имеет важное преимущество: это быстрота получения конечным пользователем необходимых отчетов - за счет ограниченного объема данных в кубе. Но, вариант когда витрины разобщены и каждая из них решает локальные, не связанные между собой задачи (то есть, когда кубы являются самостоятельными аналитическими хранилищами, а не частью единого банковского ХД), нельзя считать оптимальным. Такая система не гарантирует, что для принятия решений будут использованы качественные данные. Например, если в одном кубе имеются данные по клиентам, а в другом - данные управленческого учета, то получение управленческой отчетности в разрезе клиентов становится серьезной проблемой. Зачастую это вынуждает дублировать информацию в разных кубах, а это недопустимо. Ведь при таком подходе нельзя быть уверенным, что пользователи, работающие с разными кубами, будут видеть единую «корпоративную правду».

Выйти из этой ситуации можно следующим образом: каждый куб должен быть частью словаря данных единого ХД. Тогда устраняется избыточность и дублирование данных, во всех кубах данные будут согласованы. Объединенные данные, собранные в одном банковском хранилище, можно использовать для разных задач. Поэтому, выбирая ХД, нужно обращать внимание на наличие словаря (модели) данных. Это позволит создавать и наполнять ХД последовательно, после каждого этапа получая эффект для бизнеса. При этом заказчик будет застрахован от того, что каких-либо объектов или атрибутов данных в ХД не хватит для построения решения банка. Отраслевая модель максимально наполнена, поскольку аккумулирует опыт автоматизации различных задач для множества банков и передает заказчику этот опыт, упреждая его потребности. Именно поэтому подобные модели данных есть сегодня только у «зрелых» разработчиков ПО этого класса, таких как IBM, Oracle. Из российских компаний отраслевую модель для отечественных банков предлагает Intersoft Lab.

Спасет ли ХД в условиях кризиса?

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

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