Привет, аналитики!
В прошлый раз мы разобрались, как бизнес-аналитику наладить взаимодействие со стейкхолдерами и превратить их противоречивые требования в единую систему.
Сегодня я хочу поговорить о дальнейшей работе аналитика в проектах по созданию хранилищ данных (DWH). Как пройти весь путь от сбора требований до внедрения готового решения, сохраняя баланс интересов бизнеса и ИТ.
Мы уже выяснили потребности пользователей и достигли консенсуса по целям системы. Теперь предстоит воплотить эти требования в реальное DWH. И здесь нас ждет не меньше подводных камней, чем на этапе согласования.
Как избежать недопонимания между бизнесом и ИТ в ходе проектирования? Как убедиться, что разработанное решение действительно решает задачи заказчика? И как помочь пользователям безболезненно перейти на новую систему?
Я поделюсь с вами своим опытом участия в проектах DWH от этапа планирования до поддержки готового решения.
Этап сбора и анализа требований бизнеса
Начало любого проекта DWH - это глубокое понимание потребностей бизнеса.
Определение потребностей бизнеса - один из ключевых и самых трудоемких этапов в проектах DWH.
Важно согласовать план исследования с руководителем проекта со стороны бизнеса - определить список респондентов из разных подразделений, разработать опросник для интервью, распределить роли в проектной команде.
Далее проводятся интервью с сотрудниками компании - как правило, по 2-3 представителя от каждого ключевого департамента. Задача - максимально полно собрать и задокументировать их потребности и пожелания к DWH.
После серии интервью проводится анализ и систематизация собранных требований. Важно выявить и устранить все разночтения и противоречия между пожеланиями разных департаментов.
Далее формируется рабочая группа с участием представителей бизнеса и ИТ для совместного обсуждения результатов исследования. Цель - прийти к согласованному видению целей и приоритетов проекта DWH.
Итогом этапа становится формализованный документ требований BRD (Business Requirement Document), а также рекомендации по организации последующих этапов проекта - составу команд, выбору исполнителей, поэтапному плану работ.
Таким образом, именно на этапе сбора требований закладывается прочный фундамент проекта DWH, позволяющий минимизировать риски на последующих этапах.
Формирование детальных бизнес-требований
После определения общих целей и задач DWH, наступает этап детальной проработки и документирования требований бизнеса.
На этом этапе необходимо:
Провести углубленный анализ существующих бизнес-процессов, выделить ключевые процессы, которые должна охватывать система.
Собрать и проанализировать аналитические методики и отчеты, используемые в компании. Определить пробелы, которые должна закрыть DWH.
Провести инвентаризацию информационных систем и данных заказчика. Понять, какие системы станут источниками данных для DWH.
Детально проработать и задокументировать функциональные и нефункциональные требования к DWH в BRD.
Сформулировать KPI и метрики, которые должна рассчитывать система.
Провести серию рабочих совещаний и согласовать BRD со всеми ключевыми подразделениями.
Результатом этапа является подробный документ требований, понятный как бизнес-пользователям, так и разработчикам. Он станет основой для проектирования и разработки DWH решения
Информационное исследование
На этапе информационного исследования происходит переход от бизнес-требований к техническим.
Основные задачи на этом этапе:
Проанализировать методики расчета KPI и показателей, которые должна поддерживать DWH. Определить требования к данным.
Выявить все необходимые бизнес-понятия (продукты, клиенты, сделки и т.д.) и согласовать их описание с заказчиком.
Разработать семантическую модель данных, описывающую сущности и связи между ними в терминах предметной области.
Спроектировать информационную модель источников данных - какие данные берутся из каждой системы.
Определить требования и ограничения к исходным данным на основе требований к KPI и отчетности.
Разработать варианты архитектуры DWH, включая выбор ПО, схему работы ETL, источники и хранилища данных.
Составить список рисков и сложных участков реализации проекта.
Результатом являются информационная и архитектурная модели системы, которые затем уточняются и детализируются на этапах проектирования и разработки.
Концепция решения на базе технологий DWH
На этапе концепции происходит объединение бизнес-требований и технических возможностей в целостное видение решения.
Основные задачи на этом этапе:
Разработать документ концепции решения на основе проведенных исследований.
Представить концепцию на обсуждение рабочей группе с участием представителей бизнеса и ИТ.
Согласовать первоочередные задачи, которые будет решать DWH в рамках первой очереди.
Утвердить критерии оценки результатов проекта.
Распределить роли и зоны ответственности в команде проекта.
Получить финальное подтверждение соответствия концепции ожиданиям заказчика.
По результатам этапа формируется итоговый документ концепции, который фиксирует основные параметры проекта для последующей разработки.
Этап проектирования DWH
На этапе проектирования на основе утвержденной концепции создается детальный технический проект DWH.
Ключевые задачи этапа:
Разработать концептуальную модель данных - сущности, атрибуты, связи. Это логическое представление данных в DWH.
Спроектировать физическую схему хранения данных - таблицы, поля, ключи, индексы. Это уже физическая модель в выбранной СУБД.
Выбрать инструменты ETL и спроектировать процессы по извлечению, преобразованию и загрузке данных.
Разработать архитектуру всей системы - какие компоненты, где размещаются, как взаимодействуют.
Спроектировать интерфейсы и отчеты в системе бизнес-аналитики.
На выходе получается комплект документации для реализации ПО, БД, ETL-процессов, отчетности и интерфейсов.
Этап внедрения и сопровождения
После разработки и тестирования DWH наступает важный этап внедрения системы в промышленную эксплуатацию.
Главная цель этапа - обеспечить эффективное использование системы для решения задач бизнеса и постоянное развитие в соответствии с новыми потребностями.
Основные задачи:
Разработать аналитические отчеты, дашборды и KPI, которые решают первоочередные задачи заказчика.
Организовать обучение ключевых пользователей и администраторов работе с системой.
Оказывать поддержку пользователям после запуска, помогать при возникновении вопросов.
Регулярно собирать обратную связь от пользователей, фиксировать пожелания по развитию системы.
Постепенно наращивать функциональность DWH согласно приоритетам бизнеса.
Грамотное внедрение DWH критически важно для полноценного использования всей мощности системы в интересах бизнеса.
Полезный документ
Друзья, в дополнение к описанным этапам работы над проектом DWH, я хотела бы поделиться полезным инструментом - детальной структурой работ в таких проектах.
В приложенном файле представлена подробная иерархическая структура задач, которые необходимо выполнить на каждом этапе - от определения потребностей бизнеса до внедрения готового решения.
Она включает в себя работы по исследованию и анализу бизнес-требований, проектированию архитектуры и модели данных, разработке ETL-процессов, интерфейсов и отчетности, тестированию и внедрению системы.
Для каждого вида работ приведено подробное описание шагов и задач, которые необходимо выполнить на практике в реальных проектах DWH.
Это очень полезный инструмент как для бизнес-аналитиков, так и для руководителей таких проектов. Он помогает понять всю полноту и сложность задач, оптимизировать распределение ресурсов и управлять рисками на каждом этапе.
Рекомендую изучить структуру работ перед стартом нового проекта по созданию хранилища данных. И использовать ее затем в качестве чек-листа и навигатора при планировании и мониторинге хода проекта. Уверена, это повысит ваши шансы на успех!
Итак, мы рассмотрели основные этапы работы бизнес-аналитика в проектах по созданию хранилищ данных - от сбора требований до внедрения готового решения.
Как видите, это довольно длительный и трудоемкий путь, требующий тщательного планирования, четкого распределения ролей в команде проекта и постоянного взаимодействия между бизнесом и ИТ.
От аналитика здесь требуются такие навыки как:
глубокое понимание бизнес-процессов и потребностей заказчика;
умение выявлять и структурировать требования;
способность находить компромисс между бизнесом и ИТ;
знание методологий проектирования и best practices в области BI и DWH.
В этой статье я постаралась дать общее представление о задачах аналитика на каждом этапе, рассказать о типичных "подводных камнях" и способах их преодоления.
В следующих публикациях я подробно разберу конкретные кейсы и приведу примеры из своего опыта внедрения решений DWH в различных компаниях.
А пока - удачи вам в прокачке аналитических суперсил и построении продвинутых хранилищ данных! Делитесь в комментариях своим ценным опытом - это поможет всем нам стать еще лучше в нашем нелегком, но таком нужном деле!
menz1
Критиковать уже можно? :) в приложении очень много пунктов, я даже читать устал, если выполнять хотя бы половину, проект не закончится никогда.
Хранилища не являются вещью в себе и их проектируют с двух сторон - сверху, от отчетов/дашбордов и снизу от исходных систем. Практически всегда у бизнеса уже есть понимание, какие отчеты они хотят видеть, обычно даже избыточное :).
В целом, для отчетов определяются необходимые сущности в исходных системах, после этого целиком их забираем (это называется поддержка неизвестного), фиксируем состав основных данных, мастер систему, набор атрибутов. Фиксируем связи между транзакционными данными и алгоритмы обогащения. Прописываем состав витрин, соответствие полей витрин отчетам.
Пишем документы ролевая модель и проектное решение на основе всего выше (иногда из двух частей, для бизнеса и для айти). И для проектирования этого достаточно. Все равно практика показывает, что проектное решение хорошо, если на 70% совпало с реальностью.
У вас же все в кучу, и предпроектное обследование, и проектирование, и выбор инструментов реализации, и даже куцая разработка и почему-то поддержка опэ.
З.ы. Существенную часть из написанного должны делать разработчики, которые понимают возможности инструментов и систем, бизнес-аналитики как правило это сделать в принципе не могут, да и не должны.
Mapar
Тут скорее вопрос внешняя разработка или внутренняя. При внутренней - как Вы описали. При внешней скорее как в статье. Я бы не рискнул делать разработку на заказ, без подготовленных и согласованных заказчиком бизнес требований и технического задания и без документирования каждого шага. Иначе, потом сдавать заколеблешься.