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

О причинах, которыми принято оправдывать провальные проекты построения хранилищ данных (ХД), и о том, что же на самом деле стоит за 60% неуспеха ХД-инициатив в банках.

По оценке Gartner, более 50% проектов построения ХД считаются частично реализованными или неудачными

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

Отсутствие финансирования неизбежно ведет к сокращению круга решаемых ХД задач и его постепенному замещению другими инструментами

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