- Регистрация
- 23 Август 2023
- Сообщения
- 3 600
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 243
Offline
Представление
Меня зовут Камышев Константин, последние 12 лет занимаюсь созданием бизнес-технологических процессов в области управления данными: от мастер-данных до построения архитектуры решений.
О чем статья
О создании процессов управления данными, о том, какие фундаментальные вопросы следует прояснить на старте, какую методологию стоит утвердить от технических специалистов менеджменту направления data.
Данные - это не только железо, СУБД и ETL. Это управленческая система.
Без заинтересованного заказчика, поддержки бизнес-единиц, зрелых команд и четкой управленческой структуры — даже самая мощная архитектура может дать сбой.
Менеджменту, который участвует в управлении данными и сейчас находится на старте создания нового сервиса в компании или запуска рефакторинга и выстраивает взаимоотношения между: бизнесом, ИТ.
Техническим специалистам по данным, кто хочет заглянуть со стороны менеджмента.
Подбора инфраструктуры
Подбора параметров программного обеспечения
Идеализации одного подхода
Оцените состояние
Какие есть методологии проектирования?
Как выбор методологии влияет на требования к команде?
Проанализируйте уровень и природу заинтересованности
Управленец крупного производственного предприятия работает с командой сотрудников. Один сотрудник — директор производства, другой — директор по продажам, которые выступают внутренними заказчиками. Рядом — директор по данным, который инициирует инвестиции на развитие управления данными.
При наличии понимания, накопленного опыта «как не следует», оценки улучшения сервиса (выраженного в цифровых метриках или финансовых показателях) вас ждет быстрый старт.
Если понимание на этом этапе только формируется, это сигнал, что потребуется дополнительное время на проработку гипотез и поиск точек роста для проекта.
Цель: понять, какая тактика и стратегия будет: полное содействие развитию данных в компании или необходимость поэтапного изменения восприятия процессов к данным.
Оцените готовность компании и команд (не только технических, но и бизнес-подразделений)
Прошлый пункт не должен создать ошибочного восприятия «Почему не следует развивать сервис» — ответ однозначен: следует.
Помним, что:
Могут требоваться дополнительные инвестиции (необходимо учесть в компании бюджетный цикл и механизм его прохождения)
Необходимо подготовить бизнес-единицы к изменениям. Сотрудники однозначно сформировали привычные связи с существующим сервисом или представляют себе новый, исходя из своего опыта, вне зависимости от текущей реальности внутри компании и/или рынка (восприятие изменений необходимо проработать).
Цель: понять, что нет более сложной системы, чем взаимоотношения людей. Сейчас мы, естественно, акцентируемся на взаимоотношениях внутри компании по направлению к data. От этого зависит, какое время уйдет на выстраивание взаимоотношений с другими командами — это процесс не всегда быстрый.
Поймите, создаст ли ваш продукт конкуренцию решениям других команд
Разработана концепция DWH (как части платформы управления данными), и данное развитие создает возможности для компании и команд. Но может создать напряжение для части команд, которые имеют свои локальные решения.
Цель: понять, какое количество решений команд ваш продукт может затронуть.
Поймите, как приносить монетизацию
Очевидно, что данные — это ценный актив. Одна из важных задач управления данными — правильно определить и донести, что DWH — это:
Качественный сервис для внутренних клиентов
Монетизируемый сервис
Монетизация может быть как:
Внутренней — позволяет бизнесу правильно индексировать стоимости, оптимизировать каналы продаж, искать точки роста и т.п.
Внешней — позволяет создавать коллаборации между компаниями и увеличивать воронки продаж.
Цель: заложить в финансовую модель проекта механизм реинвестирования: часть экономического или финансового эффекта от данных направлять на развитие платформы, расширение команды и R&D.
Оцените наличие legacy-решений и их количество в компании
Существующие, часто изолированные решения (legacy) создают значительные управленческие риски:
В каждой команде при их наличии возникает вопрос: «Что будет с нами, как только произойдет централизация?»
Бизнес не стоит на месте, и возникает дилемма: «Доработать legacy-решение под конкретный заказ или отказать бизнесу до момента централизации?» — это крайне сложный вопрос, особенно на старте проекта. Придется принимать волевые решения.
Разрыв привычных связей пользователей legacy-решений. Пользователи имеют устоявшиеся паттерны работы. Это сложный и поэтапный процесс изменения пользовательских привычек.
Сколько попыток уже было совершено по отказу от legacy-решений? Если больше одной и все неудачные, по умолчанию доверие к новой стратегии будет низким.
Цель: оценить уровень привязанности процессов к legacy-решениям.
Оцените, как часто и глобально меняются бизнес и технические процессы
Если бизнес-процессы и архитектура меняются часто, вам остается соответствовать темпу.
Как только вы перестанете успевать за требованиями бизнеса, возникнут последствия:
Возврат к децентрализации / провал в закрытии legacy-решений
Снижение мотивации команд
Цель: оценить экосистему компании, в которой начинаете строить новое или изменять существующее решение.
Утвердите требования к системе
Если у системы нет границ, то через некоторое время система расширится до размеров, которыми вы не сможете управлять на достаточном уровне.
Цель: Одно из недооцененных действий — это установление функциональных границ бизнес-технологического продукта, которое увеличивает предсказуемость поведения пользователей и технической команды data-решения, что в целом создает управляемый сервис.
Одна из задач систем — это ограничивать поведение как пользователей, так и команды разработки.
Автор: Ральф Кимбалл
сайт автора методологии здесь
Автор: Уильям Инмон
Книга (одна из): «Building the data Warehouse by W.H. Inmon»
Автор: Дэн Линcтедт
сайт автора методологии здесь
Книга (одна из): «Building a Scalable Data Warehouse with Data vault 2.0»
Автор: Ларс Рённбек
сайт автора методологии здесь
Давайте рассмотрим сравнительную таблицу методологий
Кимбалл | Инмон | Линстедт | Рённбек | |
Бизнес-логика подхода | Снизу-вверх | Сверху-вниз | Гибридный подход: - Сверху-вниз: общая архитектура, стандарты, правила DWH - Снизу-вверх: поэтапное наполнение DWH по мере возникновения потребностей | Гибридный подход: - Сверху-вниз: общая архитектура, стандарты, правила DWH - Снизу-вверх: поэтапное наполнение DWH по мере возникновения потребностей |
Процесс проектирования | От потребности бизнеса к реализации: - Выявляем бизнес заказчика - Выявляем основные области данных - Делим область данных на справочники и факт - Разработка report | Реализация идет от комплексного анализа бизнес-процессов к техническому воплощению: - Глубокий анализ бизнес-процессов компании - Выделение бизнес-областей, их взаимосвязей и заинтересованных лиц в данной области -Проектирование ядрового слоя - Разработка витринного слоя - Разработка report | - Выявляем бизнес заказчика - Выявляем основные области данных - Развиваем ядро согласно потребности - Разработка витринного слоя - Разработка report | - Выявляем бизнес заказчика - Выявляем основные области данных - Развиваем ядро согласно потребности - Разработка витринного слоя - Разработка report |
Преимущества | Позволяет быстро (2-4 недели) получить первые измеримые результаты и доказать ценность подхода для бизнес-заказчика. | - Умеренная гибкость - Долгосрочная перспектива развития - Единая версия правды в ядровом слое | -Нивелирование рисков предыдущих методологий | - Строгий математический подход, который соответствует 6-НФ -Нивелирование рисков предыдущих методологий в том числе и data vault: правило – один атрибут – один объект - Нивелирует любые деструктивные изменения в core-слое засчет того, что расширение модели происходит исключительно путем добавления новых таблиц, без изменения существующих ETL процессов и объектов - Отсутствие операций update/delete в ядровом слое (insert only) -Единообразный паттерн загрузки данных в объекты core слоя |
Ключевые вызовы и риски | На перспективе 6 месяцев может быть изменений требований, которые приведут к: - Частые перезаписи данных (изменение грануляции данных, добавление новых атрибутов) - Появление дублирующих областей | - Возможен затяжной процесс бизнес-анализа потребностей бизнеса, если компания - Умеренная гибкость – не означает абсолютную гибкость, которая всегда сможет подстроиться под измененный бизнес процесс | - Правильно определить hub - «Мягкие» ограничения core слоя в отношении объектов могут вызвать проблемы (например, какое количество hub может соединять link) | - Правильно определить anchor - «Страх» команды перед ростом количества объектов в core слое - Экстремальное количество join в ядровом слое |
Слои | - stg – слой приемки данных (как правило as-is) - dm – слой витрин данных - report – cлой агрегированных отчетов под визуал или пользователей | - stg – слой приемки данных (как правило as-is) - core – ядровой слой данных по 3-НФ с учетом бизнес-анализа областей - dm – слой витрин данных - report – cлой агрегированных отчетов под визуал или пользователей | - stg – слой приемки данных (как правило as-is) - Raw data layer – слой подготовки данных для следующего слоя с учетом типов объектов (hub, link, satellite) - Bussines data layer – бизнес слой хранения данных (hub, link, satellite, PIT, Bridge) - dm – слой витрин данных - report – слой агрегированных отчетов по визуал или пользователей | - stg – слой приемки данных (как правило as-is) - core – ядровой слой данных по 6-НФ с учетом типов объектов (anchor, tie, attribute) - dm – слой витрин данных - report – слой агрегированных отчетов по визуал или пользователей |
Инфраструктура | Важно, чтобы инфраструктура обеспечила возможность перезаписи витрин на предсказуемом уровне. Например, за техническое окно (ночью) можно пересчитать 6 периодов | - Требуется конфигурация сервера, которая оптимальна для стабильности core слоя и под пересчеты dm слоя | - Повышенная требовательность к RAM - Повышенная требовательность к DISK - Повышенная требовательность к Network | - Повышенная требовательность к CPU (join, оконные функции на core слое) |
Квалификация команды | Не требуется узкопрофильная высококвалифицированная команда | Требуется команда со специализированными навыками в области глубокого понимания бизнес анализа и переносе их на core слой | Требуется высококвалифицированная и узкопрофильные специалисты высокого уровня | Требуется высококвалифицированная и узкопрофильные специалисты высокого уровня |
Подходит, если: | - Компания со стабильной структурой подразделений, бизнес процессов, источников данных - Важен быстрый результат, а риски управляемы -Вычислительные ресурсы позволяют оперативно вносить изменения (добавление новых атрибутов, изменение грануляции) -Ограниченный бюджет на высококвалифицированную команду и большую емкость команды - Есть архитектор модели данных, понимающий специфику бизнеса | - Компания с умеренно изменяющимися структурой подразделений, бизнес-процессов и источников данных - Заказчик и бизнес-команды понимают сроки и стратегическую цель управления данными | - Компания с высоко изменяющейся структурой подразделений, бизнес-процессов и источников данных - Заказчик и бизнес-команды понимают сроки и стратегическую цель управления данными - Железо отвечает повышенным требованиям в области RAM, DISK, Network - СУБД умеет оптимально работать с большим количеством join | - Компания с экстремально изменяющейся структурой подразделений, бизнес-процессов и источников данных - Бизнес требования меняются динамически (бизнес в активной фазе росте или изменения) - Заказчик и бизнес-команды понимают сроки и стратегические цель управления данными - СУБД умеет оптимально работать с экстремальным количеством join - Возможная миграция систем источников на новую платформу с изменением всех бизнес ключей |
Не подходит, если: | - Компания в стадии роста с постоянными изменениями процессов - Источники данных часто изменяются | - Компания в стадии роста с постоянными и экстремальными изменениями процессов - Заказчик и бизнес-команды не понимают почему важно выделить этап анализа бизнес-процессов и дать время на реализацию стабильного ядра | -Ограниченный бюджет на железо -Ограниченный бюджет на высококвалифицированной команды | -Ограниченный бюджет на высококвалифицированную команду |
Так же рассмотрим чуть детальнее слои данных
слой | stg | core | data mart | report | visual |
Назначение | Отделить от систем источника данные | Накопить стандартизированные данные | Предоставить готовые детальные данные для возможностей бизнеса самостоятельно выполнять задачи аналитики, которые не покрыты следующими слоями | Предоставить готовые агрегированные и рассчитанные данные для уменьшения нагрузки на сервер | Визуализировать данные для пользователей. Преобладающее количество бизнес-аналитиков используют готовые визуальные отчеты |
Краткое описание | Предназначен для загрузки данных из систем источников как есть, или точь-в-точь | Предназначен для объединения и накопления детальных данных из разных источников, которые объединены в одну общую структуру согласно методологии | Витринный денормализированный слой данных (обычно разбитый на факт и справочник), который уже адаптирован для аналитики | Готовый отчетный слой, где данные уже агрегированы до ключевых показателей бизнеса по тактическим и стратегическим показателям согласно бизнес потребности, обогащенные справочниками и расчетными метриками бизнеса. Может позволить снизить нагрузку на dwh путем доступа к готовым данным вместо расчета налету | Готовый визуальный борд с возможностью фильтрации данных на лету |
Пример | Получить данные из CRM систем, которые разбиты по географии для повышения отказоустойчивости | Объединить заказы из n CRM в один объект согласно методологии | Предоставить витрину заказов со справочниками | Отчет заказов по количеству по географии, торговых точек, товаров за день | Визуализация продаж на карте по городам по фильтрам товаров, календарь |
Кимбалл | Обязательно | Не требуется | Обязательно | Опционально | Обязательно |
Инмон | Обязательно | Обязательно | Обязательно | Опционально | Обязательно |
Линстедт | Обязательно | Обязательно (необходимо учесть, что должно быть два) | Обязательно | Опционально | Обязательно |
Рённбек | Обязательно | Обязательно | Обязательно (в официальной методологии это view) | Опционально | Обязательно |
Таблица выше - краткое сравнение методологий и слоев решения.
Раздел 3. Как выбор методологии влияет на требования к команде
Итак, оценили состояние экосистемы и рассмотрели ключевые методологии. Каждая из них — это не просто свод архитектурных правил и технических инструментов в виде инфраструктуры и программного обеспечения, а лишь основа для вашей будущей data-команды.
Выбор подхода напрямую определяет, каких специалистов вам потребуется найти, как их поместить в организационно управленческую структуру и какие компетенции в них развивать.
Необходим баланс между методологией и членами команды.
Самые совершенные архитектуры могут не выдержать столкновения с кадровыми реалиями.
Поэтому после анализа бизнес-контекста и знакомства с методологиями ключевым становится вопрос: какой подход наиболее возможем в реализации текущим или достижимым возможностям вашей команды?
Как меняются требования к коллективу в зависимости от выбранного пути:
Методология Кимбалл
Этот подход позволяет относительно небольшой, но хорошо скоординированной команде быстро демонстрировать ценность. Его успех держится не столько на глубокой технической экспертизе, сколько на сильном понимании бизнес-процессов и умении выстраивать диалог с заказчиками.
Основная управленческая задача здесь — не допускать хаотичного роста количества витрин и дублирования логики.
На что обратить внимание:
Достаточно ли в команде людей, которые говорят на одном языке с бизнесом
Есть ли процессы для контроля за «зоопарком витрин»? Как правило, эта методология предъявляет наиболее демократичные требования к начальному уровню технической экспертизы, делая ставку на скорость и бизнес-ориентированность
Методология Инмон
Здесь фокус смещается.
Для создания стабильного и целостного ядра данных (core) необходимы не просто коммуникаторы, а глубокие эксперты в предметной области бизнеса, способные формализовать его сущности и связи (технический уровень).
Команда должна глубоко разбираться и владеть принципами нормализации, понимать долгосрочные последствия проектных решений.
На что обратить внимание:
Готовы ли бизнес-эксперты уделить значительное время на этапе проектирования?
Есть ли в команде или на примете архитектор данных, который мыслит категориями «единой версии правды»?
Требуется более зрелая и терпеливая команда, где ценится стратегическое мышление выше тактической скорости.
Data Vault и Anchor Modeling
Эти гибкие методологии — инструмент для работы в условиях высокой неопределенности.
Однако их гибкость имеет свою цену: они требуют команды высочайшей технической квалификации, которая работает как слаженный механизм.
Речь идет не об отдельных гениях, а о коллективе с отлаженными процессами архитектурного контроля, управления метаданными и строгой дисциплиной.
На что обратить внимание:
Существует ли в вашей компании культура сложной инженерной практики
Позволяет ли бюджет привлекать и удерживать узкоспециализированных и дорогостоящих data-инженеров?
Это инвестиция в долгосрочную адаптивность, сопряженная со значительными стартовыми затратами на формирование «звездного» состава. Ваша команда готова посвятить себя проекту длиной от 2-х лет?
Проверка на реальность: скиллы vs амбиции
Предположим, технические лидеры настаивают на внедрении Anchor Modeling, исходя из его теоретических преимуществ, в то время как контекст компании больше напоминает условия для Инмон.
Ключевые вопросы для обсуждения:
Насколько существующая команда готова к выбранной методологии не на уровне лозунгов, а на уровне ежедневной практики?
Что рискованнее: Значительно опередить за короткое время текущие компетенции или выбрать слишком «типовой» для амбиций, но реализуемый подход?
Практический шаг:
Проведите честную оценку навыков (skills matrix) команды
Совместно проанализируйте, какие пробелы критичны, а какие можно закрыть в процессе
Не идеализируйте ни один подход — идеальной методологии нет, есть наиболее подходящая для конкретной бизнес-ситуации и конкретной команды
Утверждая методологию DWH, вы на самом деле утверждаете бизнес-технологический процесс, затрагивающий следующие грани:
Выстраивание взаимоотношений с бизнесом: успешные или провальные
Кадровую стратегию: профиль сотрудника, роли, организационно-управленческую структуру команд и модель взаимодействия
Ваше решение превращает абстрактную архитектурный подход в рабочий «организм» вашего data-направления
Согласуется ли ваш выбор не только с вызовами бизнеса, но и с потенциалом членов команды, который вы готовы в него вложить?
Надеюсь, статья получилась увлекательной и позволяющей посмотреть на методологию с другой стороны.
Контакты:
Email: data-management@kkamyshev.ru
Канал: https://t.me/data_management_kamyshev_k