Что нужно знать про внедрение ХД?

Кратко, что нужно обязательно знать про внедрение хранилища данных.

1. Если проект затевается без конкретной прикладной задачи «просто строим хранилище, потом решим для чего», то он будет неуспешным. Если вендор рекомендует такой проект – присмотритесь к другим поставщикам.
2. 3-4 месяца – реальный срок, в который можно запустить хранилище для решения одной простой задачи. В идеале - полгода. Будет комфортно и исполнителю и заказчику.
3. «Пилот» на старте ХД-проекта – «де-факто» норма. Это коммерческое внедрение, которое решает одну небольшую задачу, например, автоматизацию несложной формы регуляторной отчетности. Заказчик сможет объективно оценить ПО, компетенции проектной команды и собственную готовность к проекту.
4. Для «пилота» вендор может предоставить заказчику особые условия, например, «временные» лицензии на период внедрения, бесплатное техническое сопровождение и проч. Потому, что вендору «пилот» тоже полезен.
5. Интеграция хранилища с источниками данных – самая длительная и затратная часть проекта. Оптимально выполнять ее по шагам, встраивая разработку маппингов в решение новых прикладных задач. Не так «потянут» расходы, и сразу будет виден полезный результат от инвестиций и усилий.
6. Нельзя сэкономить на разработке маппингов, взяв их из другого проекта: «вы же уже интегрировались с АБС Х, у вас это все есть». Конечно, заготовки многих маппингов у команды внедрения есть, и знание систем-источников тоже. Но не бывает двух одинаковых АБС, и чаще всего сделать для заказчика маппинг «с нуля» быстрее, чем править «чужой».
7. Правильнее собирать данные в ХД «под» конкретную задачу. Нерационально ставить целью заполнение всех полей модели данных. Во-первых, это дорого. Во-вторых, не решая прикладную задачу, невозможно убедиться в достаточности и качестве собранных данных. Подумайте, стоит ли платить за «мертвый груз»?
8. Распространенное заблуждение, что прикладной функционал ХД заработает автоматически, как только хранилище наполнится данными. Это не так. Тиражные (готовые) ХД-приложения многократно ускоряют внедрение прикладных решений. Но они требуют адаптации. Создание пользовательской системы на базе тиражного приложения предполагает настройку готовых механизмов под методические требования заказчика и может сопровождаться доработкой/разработкой процедур, дополняющих тиражные функции по запросу банка. Даже выпуск форм регуляторной отчетности в каждом банке имеет свою специфику. А внутренняя отчетность всегда уникальна.
9. Если банк не хочет развивать ХД своими силами, он всегда может обратиться к вендору. Если развитие силами банка невозможно, то банк выбрал плохое ХД. Если банк готов участвовать в развитии ХД, он должен договориться с вендором о правилах совместной разработки.
10. Выгода от ХД становится заметна, когда начинается переиспользование данных. Например, собрали данные и автоматизировали десяток форм регуляторной отчетности. Дальше разворачиваете приложение для управленческой отчетности, потом настраиваете расчет трансфертных доходов и расходов, следом расчет трансфертных цен и т.д. Решение каждой следующей задачи увеличивает возврат инвестиций в создание хранилища.

Это конечно, не всё. Но надо же с чего-то начинать.