Основные риски проектов внедрения хранилищ данных и систем отчетности

11 июнь, 2012 - 12:07Александр Кучерук

Прочитал недавно RFP на тендер по построению хранилища данных в одном уважаемом банке и поймал себя на мысли, что в очередной раз тендер будет проводиться на выбор СУБД, ETL, инструмента отчетности, но не на решение для бизнес-задач. А значит опять возможна ситуация когда по факту сдачи работ конечная цель – создание единой точки правды для анализа бизнесом своих задач, может не быть достигнута.

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

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

Самыми трудоемкими (не сложными методологически или технологически, а именно трудоемкими) являются задачи:

– вообще найти требуемые данные. Данных в системах много, все нужны для учета, но какие нужны для хранилища? Все?

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

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

– получить достаточный объем исторических данных с учетом как необходимой детализации, так и с учетом скорости обработки аналитических запросов и скорости построения отчетов. Хранить _все и всегда_?

– иметь возможность выгружать данные за приемлемое время, как исторические, так и ежедневные порции обновляемых данных. Если данные в АБС или карточной системе сформированы к 02:00, а рабочий день начинается в 09:00, хватит ли 7 часов для выгрузки данных из источников и загрузить в ХД? А если позже данные в АБС будут формироваться к 05:00, успеет ли система подготовить отчеты к началу рабочего дня?

– консолидировать данные из различных источников, обязательно разрешая вопросы расхождений в данных и несогласованности справочников (классификаторов), т.е. идентификации «правильных и пригодных» данных.

И по трудоемкости эти задачи могут занимать до 70% трудоемкости проекта.

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

Если говорить о других рисках и взять, к примеру, перечень рисков из PM Book, то в проектах внедрения аналитических систем и хранилищ данных вряд ли удастся найти нечто специфическое, некатегорируемое ранее. Но с точки зрения личного опыта, наиболее часто встречающимися в наших проектах являются:

– неэффективные коммуникации в проекте, вызванные разным уровнем подготовленности участников к проектной работе и ведению проектной документации,

– неконтролируемое заказчиком расширение объема требований всех подряд подразделений, сразу после осознания того, что какое то подразделение выбило деньги на хранилище/аналитику и контракт подписан.

– ограниченные ресурсные и методологические возможности заказчика при проверке аналитических показателей в многомерной модели «плоскими» бухгалтерскими способами и недокументированными SQL запросами.

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

– презумпция виновности исполнителя:

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

... а ну раз у вас все корректно, тогда пойдем искать ошибки у себя в учетной системе/хранилище/процедурах выгрузки/бухгалтерии ...»

– недооценка ИТ подразделением своих трудозатрат по выгрузке данных из учетных систем. Навыки построения отчетов SQL запросами на несвязанных данных, сильно мешают системной работе при выгрузке в хранилище.

– неожиданные глюки в самой платформе

– отсутствие доступной системы подготовки специалистов заказчика навыкам работы с ПО, используемым для разработки.

Может у кого то есть и другие впечатления от подобных проектов, которые в той или иной степени внедряются во многих банках?

Буду рад возможности обсудить как риски, так и мероприятия по их демпфированию/устранению.