Публикации

Intersoft Lab в СМИ - истории успеха клиентов, интервью и мнения экспертов компании, обзоры рынка CPM

Непопулярный рейтинг причин краха банковских хранилищ данных

О причинах, которыми принято оправдывать провальные проекты построения хранилищ данных (ХД), о том, что на самом деле стоит за 60% неуспеха ХД в банках - в статье Юлии Амириди, заместителя генерального директора Intersoft Lab, на Bankir.ru.

История технологии хранилищ данных насчитывает уже три десятка лет. Вторую половину этого срока согласно данным опросов авторитетных иностранных компаний характеризуют стабильные 50-60% процентов провальных попыток создания «единого источника корпоративной правды». 2005 год: по оценке Gartner более 50% проектов построения ХД считаются частично реализованными или неудачными. 2012 год: по итогам опроса, проведенного консалтинговой компанией Dresner, результаты только 41% проектов построения ХД оценены положительно. 2014 год: по данным консалтинговой компании Scott Ambler + Associate 42% проектов ХД/BI признаны успешными, 55% столкнулись с проблемами, а 4% оказались провальными. И, наконец, 2018 год: только 2 из 10 банков (20%), с которыми работали консультанты McKinsey, сумели развернуть ХД.

По оценке Intersoft Lab, которая опирается на данные из открытых источников, ситуация на отечественном рынке банковских ХД в последние 15 лет немногим лучше мировой. Из примерно двухсот попыток внедрения ХД и решения на их основе различных прикладных задач после вычитания проектов, которые прекратили существование из-за отзыва лицензий у кредитных организаций, как минимум 38% хранилищ данных «не взлетели» вовсе либо так и остались, по меткому замечанию ИТ-менеджера из российского представительства одного иностранного банка, «прикованными цепями к взлетно-посадочной полосе», несмотря на бодрые рапорты об успешном завершении приемо-сдаточных испытаний. Думаю, не ошибусь, что поправка на ликвидацию банков и неафишируемые фиаско даст в итоге все те же 55-60% неуспеха ХД-проектов в российском финансовом секторе.

Западные аналитики утверждают, что главным препятствием к внедрению ХД являются исходные данные: их полнота, безошибочность, достоверность, то есть все то, что принято называть качеством данных. Возражать сложно, ведь 70% бюджета ХД-проекта тратится, как правило, на сбор данных и обеспечение их качества. Вместе с тем, за 18 лет работы на отечественном рынке автоматизации банковской аналитики, мне известен только один случай, когда недоверие к данным в ХД обернулось отказом банка от проекта. Чаще проблема с качеством данных приводит к долгострою. Во-первых, несмотря на пухнущие от проекта к проекту библиотеки проверок, которыми оснащены платформы ХД, у любого банка найдутся неподвластные тиражным инструментам уникальные проблемы с данными, исправление которых требует реализации сложных индивидуальных алгоритмов, например для заполнения пропущенных кодов контрагентов на проводках и т.д. В результате сначала время расходуется на диагностику причин обнаруженных расхождений, потом сотрудники банка по разным соображениям тянут с устранением ошибок и недочетов в учетных системах и после длительных переговоров настаивают на исправлении данных непосредственно на уровне ETL. Такие «костыльные» конструкции в моменте, конечно, облегчают жизнь, но имеют негативные последствия не только в части срыва сроков – несвойственные интеграционному процессу функции отрицательно влияют на производительность сбора данных, усложняют ETL-код и его последующее сопровождение. Во-вторых, сложность задачи интеграции и обеспечения качества данных на старте проекта практически всегда недооценивается заказчиками. Типичные аргументы: «не знаем, как у других, но на 95% у нас хорошие данные» или «мы сейчас сами выгружаем эти данные, и у потребителей нет претензий к их качеству» и т.п. Однако, по опыту в типовом наборе данных первого этапа построения ХД – бухучет, клиенты, кредитный портфель – в среднем обнаруживается порядка 200 видов ошибок. Их исправление может обернуться перерасходом бюджета и срывом сроков перевода первой очереди ХД в эксплуатацию. Но, согласитесь, для признания проекта неуспешным нужны более весомые резоны.

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

Третье место среди сложностей разворачивания ХД западные аналитики отводят недостаточной компетенции проектной команды, как со стороны заказчика, так и от исполнителя. И снова трудно признать, что именно эта причина сегодня наносит существенный урон созданию ХД в российских банках. 15 и даже еще 10 лет назад особенно при заказной разработке ХД фактор некомпетентности, действительно, работал. Зачастую на проект приглашали интегратора, который, получив контракт, быстро набирал с рынка команду более-менее подходящих разработчиков и выпускал ее «на клиента» со всеми вытекающими последствиями. Сейчас все иначе: известен обозримый список зарекомендовавших себя поставщиков банковских ХД, у каждого в наличии готовая более или менее тиражная платформа создания ХД, команды ETL-программистов, владеющих различными инструментами интеграции, включая СПО, наработанные технологии внедрения и подтвержденный референсами опыт. Отличия кроются в прикладных компетенциях: у одних шире наработки в автоматизации управления прибыльностью на базе ХД, кто-то специализируется на подготовке регуляторной отчетности, западные вендоры предлагают максимально полный стек финансовых приложений, правда у них далеко не всегда имеются в России референсные банки, и т.д. Но общий уровень отечественных специалистов - архитекторов, аналитиков, программистов и внедренцев - с опытом ХД-проектов на базе ПО российской либо иностранной разработки сегодня достаточно высок. Негативно повлиять на качество проектной команды способно стремление банков снизить затраты за счет приглашения специалистов из постсоветских республик, но и там, при грамотном выборе наличествуют квалифицированные кадры. Что касается компетенций самих заказчиков, за прошедшие годы они также выросли, и для критики вряд ли найдутся основания.

Итак, три чаще всего озвучиваемые причины краха проектов построения хранилищ данных при детальном рассмотрении не могут обосновать неуспех ХД-инициатив в российском финансовом секторе. Тогда в чем же дело? Рискну предложить собственный, гораздо менее благозвучный и оттого непопулярный рейтинг причин провалов ХД-проектов, основанный на личном знакомстве с изнаночной стороной автоматизации бизнес-аналитики в банках.

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

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

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

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

Или другая крайность: построение ХД исключительно с помощью средств интеграции данных. На практике это означает создание индивидуального набора таблиц и его заполнение с помощью инструментов ETL и Data Quality. На выходе имеем по сути своей промежуточный оперативный склад данных, лишенный отраслевой модели данных, без средств управления метаданными, без элементарных механизмов классификации данных и тем более их бизнес-аналитической обработки. Решение любой прикладной задачи приводит к реинженирингу такого ХД и новой индивидуальной разработке. Это тупиковый путь для тех, кто ставит целью решение на базе ХД самого элементарного набора прикладных задач. Примеров реализации описанного архитектурного подхода с помощью инструментов BIG Data, ИИ и проч. модных технологий пруд пруди. А вот польза создаваемых ХД сомнительна, да и жизнь скоротечна.

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

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

Автор: Юлия Амириди, заместитель генерального директора по развитию бизнеса компании Intersoft Lab

Источник: Портал Bankir.ru "Клуб экспертов"