Схема работы пользователей до внедрения единого озера данных

Запуск нового проекта

После обсуждений и согласования с “corporate” (головным офисом компании) было принято решение о старте нового проекта по объединению всех данных по по отчетности в рамках единого хранилища - озера данных. Проект получил кодовое название “Эйва” (в фильме Аватар Эйва - средоточие энергии, а в нашем случае - чистых данных).
В начале проекта необходимо фиксировать существующие проблемы “как есть”, чтобы правильно сформулировать цели и задачи проекта.
В нашем случае от бизнес-пользователей были озвучены следующие проблемы:

1. Каждый сотрудник работал одновременно с несколькими несвязанными между собой системами отчетности, в которых было много устаревшей информации и не задокументированной логики расчета KPI;
2. Не было выделенного хранилища данных для консолидации;
3. Было невозможно принятие быстрых управленческих решений из-за отсутствия аналитики “в режиме реального времени”;
4. Были проблемы с качеством данных из внешних источников. Данные в основном передавались сотрудникам по email посредством Excel-файлов;
5. Большое количество “ручных отчетов”, Excel был главным инструментом визуализации для “кастомной” отчетности;
6. Сложно прогнозируемое управление ресурсами и затратами для поддержки различных аналитических инструментов.

Вместе с командой бизнес-заказчика мы сделали вывод:

Цели проекта:

1. Предоставить бизнес-пользователям (как полевым сотрудникам, так и руководству отдела продаж) структурированную информацию в рамках единого окна - озера данных в облаке (мы назвали это экосистемой продаж). Данные для отчетности должны отображаться как исторические, так и актуальные на текущий день.
2. Подготовить экосистему продаж к предоставлению данных внешним контрагентам в соответствии с политикой безопасности
3. Внедрить единую логику отчетности для трех стран (кластера) Unilever: России, Украины и Беларуси.

Как проходило внедрение

Ключевые принципы

Мы зафиксировали ключевые принципы для того, чтобы внедряемое решение удовлетворяло современным стандартам:

1. Возможность загружать как структурированные, так и неструктурированные данные;
2. Система должна быть в облаке (содержать локальные сервера - прошлый век);
3. Использование “Pay to go model” - платить только за используемые ресурсы. Это позволяет быстро масштабировать решение;
4. Возможность выполнения сложных аналитических запросов, используя массовой параллельной обработки;
5. Возможность применения машинного обучения и искусственного интеллекта out-of the-box.

Архитектура ИТ-решения или почему мы выбрали Microsoft Azure

В международных корпорациях обычно все решения по внедрению новых ИТ-систем, должны согласовываться с головным офисом, поэтому выбор потенциальных систем для внедрения был сильно ограничен. Тем не менее, мы выбрали Microsoft Azure по следующим причинам:

1. Все данные для отдела продаж могли храниться в одном месте;
2. Данные для принятия оперативных управленческих решений могли обновляться каждые 15 минут;
3. Power BI - удобное средство визуализации для любой BI отчетности, большинство сотрудников уже использовали его для визуализации данных;
4. Мы могли настраивать любые методы интеграции данных (начиная от классических xls/csv файлов до современных REST API)
5. Прозрачное ценообразование и оплата по факту за используемые вычислительные мощности озера данных
6. Возможность подключения компонентов AI для прогнозирования продаж планирования производства

Выбор вендора и определение ключевых участников проекта

Мы провели тендер и выбрали подрядчика, имеющего опыт в реализации проектов такого масштаба - компанию Deloitte.
Ключевые участники проекта были определены так, чтобы были заинтересованные сотрудники из каждого требуемого подразделения:

У каждого проекта, реализуемого с помощью вендора, должно быть два руководителя проекта (я представлял компанию Unilever, а со стороны Deloitte с нами работал опытный ИТ менеджер - Наджим Мохаммад).

Схема компонентов

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

Пример схемы компонентов

Мы обозначили, что возможны следующие элементы схемы:

1. 4 типа компонентов (систем):

• Работающая система;
• Система еще не запущена в промышленную эксплуатацию;
• Система планируется к выводу из эксплуатации;
• Внешний источник данных.

2. 3 типа потоков данных:

• Текущий поток (AS IS)
• Планируемый поток (TO BE)
• Планируемый к удалению поток после внедрения потока TO BE;

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

Нужно понимать, что эта схема должна обновляться в режиме реального времени, иначе она быстро потеряет актуальность и практический смысл. Для этого мы определили ответственного за схему компонентов аналитика.

Настройка ETL процессов или “составление STTM модели”

Для проектирования ETL процессов мы предпочли “подход от обратного”.
Мы зафиксировали список всех требуемых для отчетности KPI в отделе продаж компании, их получилось около 90. Затем шаг за шагом описывали, как формируется каждый KPI и из какой системы берутся данные.
Получившийся документ называется Source to target mapping или STTM модель. Это был огромный Excel. Наша схема компонентов AS IS помогла разобраться, как мы сможем построить потоки TO BE.

Мастер данные - основа

Мы сколько угодно можем настраивать потоки данных, но без “чистых” мастер данных мы не получим качественную отчетность, поэтому мы инициировали отдельный проект по работе и хранению мастер-данных.
Эта тема отдельной статьи, поэтому здесь только отобразим концептуальную схему, которую мы решили использовать к компании: все мастер-данные (как новые, так и обновляемые) сначала загружались в “стейджинг” и проверялись, и только потом загружались в мастер-каталог.

Схема выверки мастер-данных

Вершина айсберга или визуализация KPI

По просьбе бизнеса мы сделали 4 ключевых дашборда для отдела продаж компании:

1. Retail Execution. Общие KPI по продажам
2. Distributor business. Продажи через дистрибьюторов;
3. Key Accounts. Продажи по прямым договорам с торговыми сетями;
4. Ice Cream. Дашборд по продажам мороженого, так как за его распространение отвечала отдельная торговая команда.

Как мы организовали поддержку решения

Любое новое решение должно быть хорошо задокументировано. Мы определили аналитиков, которые вычитывали документацию, а я занялся организацией поддержки решения. В результате родилась такая схема:

В соответствии с требованиями ITIL, мы определили 3 уровня поддержки (их можно увидеть на приведенной схеме):

1. За каждым дашбордом мы определили его Владельца. Он же является ключевым пользователем (и можно сказать Product Ownerом). Он отвечает за его развитие и ответы на вопросы конечных пользователей. Если он не может помочь пользователю, то обращается к дата стюарду по соответствующей таблице
2. Дата стюард определяет, может ли он решить вопрос и в случае необходимости создает заявку сотруднику поддержки системы
3. Сотрудник поддержки разбирает проблему, и если она не относится к доработке, то исправляет ошибку.

Результаты автоматизации

После внедрения нового озера данных в промышленную эксплуатацию в 2021 году мы подвели итоги проекта:

1. Power BI Дашборды: Были созданы 4 ключевых дашборда в Power BI для отдела продаж;
2. Использование сотрудниками: Более 400 сотрудников стали использовать систему в своей ежедневной работе;
3. Вывод из эксплуатации систем: 6 аналитических систем были выведены из эксплуатации;
4. Интеграция данных: Было подключено 5 внешних источников информации, которые загружали данные на ежедневной основе.
5. Эффективность поддержки: Количество запросов в поддержку сокращено на 70 % благодаря новой схеме поддержки.
6. Рост продаж: Проведение более частых и целенаправленных рекламных кампаний, что привело к увеличению продаж на 5%.
7. Оптимизация затрат: Оптимизированы мотивационные выплаты дистрибьюторам, исключены перерасчеты бонусов, внедрено стандартизированное SLA с уровнем соблюдения 99%.

Результаты любого проекта всегда должны сравниваться с тем, что было, поэтому мы составили такую сравнительную таблицу:

Таким образом, новая система позволила сотрудникам принимать более правильные и своевременные управленческие решения для того, чтобы увеличивать дистрибуцию и продажи товаров компании.
Пенетрация товаров компании Юнилевер в 2021 году приблизилась 99%, т. е. практически в каждом доме есть хотя бы один из товаров компании.
P.S. От ИТ-директора компании Юнилевер были вручены заслуженные награды:

1. “The best goalkeeper” - Руководителю проекта Сергею Корневу за успешное внедрение системы и существенную экономию бюджета.
2. “The most useful player” - Аналитику проекта Марату Нерсисяну за профессионализм и сверхусилия по поддержке нескольких сложнейших ИТ-систем по время перехода на единое озеро данных.