Ошибка на миллион: что может пойти не так при построении хранилища данных
Корпоративное хранилище данных (Data Warehouse, DWH) необходимо для запуска проектов в области бизнес-аналитики. Данные поступают в хранилище из различных источников — информационных систем, приложений, внешних систем. Таким образом, хранилище данных становится единым источником проверенной информации компании. С помощью аналитических инструментов компании извлекают из собранной в DWH информации ценные для бизнеса сведения для повышения эффективности решений, принимаемых в различных подразделениях – от менеджмента и членов правления до бухгалтерии, казначейства, отдела кадров и других службах. Аналитика помогает решать множество бизнес-задач — от оценки клиентской базы и продуктов до бюджетирования и составления консолидированной отчетности.
Многие крупные компании понимают ценность бизнес-аналитики и необходимость создания корпоративного хранилища данных. Однако практически все сталкиваются с проблемами, приводящими к увеличению бюджета проекта и затягиванию сроков реализации. Разберем наиболее «дорогие» ошибки при построении DWH.
Ошибка № 1: непонимание бизнес-целей
Это главная ошибка, которая может привести к срыву проекта и необходимости начинать всё с нуля.
При построении хранилища данных следует идти от потребностей бизнеса. Это означает, что важно привлечь будущих пользователей — сотрудников, которые будут работать с информацией и строить аналитические отчеты. В зависимости от их задач выбираются архитектура и способ реализации конечного решения. В противном случае проектная команда загружает в хранилище данные по своему усмотрению и в том виде, который считает оптимальным. Время и усилия потрачены, а результата нет — пользователи не могут полноценно работать с хранилищем и получать требуемый результат.
Поэтому первым делом нужно определить перечень ключевых сущностей, которые необходимо загрузить для того, чтобы покрыть потребности бизнеса в полном объеме. Без вовлечения будущих пользователей на старте проекта это вряд ли удастся.
Ошибка № 2: неправильная модель данных
Далее необходимо выбрать оптимальную модель данных, которая будет соответствовать определенным на старте проекта бизнес-целям. При этом она не должна быть сложной как на этапе проектирования, так и на этапе эксплуатации.
Один из значимых рисков — выбор модели данных, которая используется редко. В этом случае будет сложно найти архитекторов, которые успешно внедряли такие решения. Чтобы разобраться в методологии, где всегда присутствует множество нюансов, специалистам придется потратить время. И это уже удорожает проект.
Если нет широкого опыта применения модели данных в корпоративных хранилищах, то во время реализации проекта могут возникать неприятные сюрпризы. Например, процедура загрузки данных из систем источников может оказаться слишком сложной и будет требовать колоссального количества времени. Могут возникнуть проблемы с обучением команды — на это придется отвлекать ресурсы опытных специалистов.
Выходом из ситуации может послужить упрощение модели до определенного уровня, однако нередко это ведет к потере достоинств, в силу которых она изначально была выбрана. В итоге компания не только теряет деньги и срывает сроки проекта, но получает решение, которое будет тяжело и дорого поддерживать в будущем.
Принятие неверного решения на этапе выбора модели данных может стоить крайне дорого, а риски становятся непрогнозируемыми. Поэтому важно привлекать максимально компетентных специалистов на стадии предпроектного обследования и моделирования хранилища данных.
Ошибка № 3: некорректная пирамида специалистов
Построение корпоративного хранилища данных или замена устаревшего DWH на новое решение — это чаще всего большой мультивендорный проект. К примеру, на одном из таких проектов у нас работает больше 300 человек, из которых около 100 — сотрудники нашей компании.
Для достижения запланированного результата важно не только подобрать людей с нужными компетенциями, но и соблюдать баланс проектных ролей. Например, для снижения затрат в команду привлекают больше начинающих разработчиков и аналитиков. Это может стать проблемой: опытные специалисты, вместо того чтобы решать сложные задачи, вынуждены тратить время на обучение новичков, а после обучения — постоянно контролировать их работу. Процесс затягивается, изначально запланированная экономия на ФОТ превращается в лишние расходы.
Как избежать проблем
Чтобы соблюсти сроки проекта и добиться нужного результата с первого раза, рекомендую придерживаться еще нескольких важных правил:
-
Источники данных для хранилища лучше определить на старте проекта исходя из бизнес-потребностей.
-
Пробелы в имеющихся данных проще закрыть, если сразу задокументировать их местоположение, структуру и качество. Такой порядок определяет бизнес-правила для их преобразования в соответствии с требованиями хранилища.
-
В команду должны входить «спонсоры» проекта из высшего руководства, а также сотрудники, которые будут работать с данными. Стандартные отчеты и KPI, необходимые им для выполнения задач, важно определить в начале проекта.
-
Из разных сценариев применения хранилища данных для пилотного проекта стоит выбрать один-два с высокой ценностью для бизнеса.
-
Опыт технологического партнера по организации хранилищ данных должен соответствовать потребностям компании — в этом случае удастся избежать типичных проблем.
-
Решение должно быть гибким. Когда работать с ним будет все больше подразделений и сотрудников, появится необходимость в построении витрин данных и масштабировании хранилища. Изначально гибкая платформа сможет удовлетворить растущие потребности.
Опубликовано 20.01.2023
