`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Александр Кучерук

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

+33
голоса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+33
голоса

Напечатать Отправить другу

Читайте также

Хотя я зарекся иметь дело с банками еще в 1999 году, вы описали очень точно то, что было актуально в конце 90-х. Насколько я имею возможность быть в курсе того, как оно сейчас - ничего не поменялось. 3-4 нормальных технических/технологических спеца на крупный банк - это уже роскошь... И проблемы - 100% те, что описаны, причем это на фоне масляных глаз "заказчика" в ожидании отката...

V.K.

Александр, первая ваша фраза о том, что в RFP не видно решения бизнес-задач.
Далее в тексте Вы пишете: "Полностью качественных данных не существует."
Может быть и тут, у вас нет полностью всех данных, чтобы оценивать RFP?

ИМХО, нужно сделать хотя бы три-пять ХД для банков, "набить шишки", чтобы были успешные решения.

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

Если считать, что построение ХД процесс достаточно долгий, то есть вполне сбывающийся риск того, что в процессе построения ХД перестанет быть нужно, или перестанет удовлетворять нечетким RFP. С соответствующими выводами и сменой как ХД так и главного подрядчика.

Вообще-то у меня складывается устойчивое ощущение, что все ИТ-проекты, которые не укладываются в 6-8 месячный срок реализации, очень сильно отходят от первоначальных RFP в последствии. И тут искусство интегратора и консультанта в том, чтобы правильно сделать декомпозицию задач на условно-постоянные и "рисковые", сиюсекундные. У тех, у кого это получается - вероятность успешной реализации и удовлетворенность клиента - высокие. У других - рулетка...

V.K.

Блестяще! Вы очень точно описали мои ощущения и мысли по поводу успешности таких проектов. Браво!

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT