Как мы обнаружили пропажу десятков миллионов рублей благодаря сквозной аналитике бизнеса

Пример из практики: в одной из крупных компаний собрали единое хранилище данных аналитики и обнаружили, что в старых отчетах где-то потерялись десятки миллионов рублей.

Финансисты смотрели на одни данные, а отдел продаж на другие. В одном отчете учитывались какие-то склады и адреса доставок, а в другом отчете нет. Никто не замечал, что несколько миллионов каждый месяц непонятно где оседали. Это частая проблема на рынке eCommerce. И в этой статье мы расскажем, как не допустить подобного.

Мы в Heads and Hands разрабатываем мобильные решения для eСommerce и глубоко погружаемся в бизнес-задачи клиента. Общаясь с партнерами и клиентами, часто слышим об одних и тех же сложностях с аналитикой. Маркетологи умеют работать с Google Analytics, продажники владеют 1С, а штатные аналитики рисуют красивые отчеты в Excel, но между собой эти системы никак не связаны. Руководители не видят общей картины, и правая рука не знает, что делает левая.

На конференциях модно говорить про сквозную аналитику, Big Data и персональные рекомендации, но на деле мало у кого есть какие-то космолеты. Все до сих пор работают в Excel: выгрузили данные из нескольких таблиц, объединили в одну таблицу и отследили выкупаемость. Базовый уровень.

Мы поговорили с Елизаветой Гринберг о наиболее острых проблемах с аналитикой в средних и крупных компаниях, и как их решать.

Елизавета Гринберг, CEO BI Tool

Консультирует компании по построению сквозной аналитики, по созданию OLAP-кубов, по настройке веб-аналитики и связанных с этим бизнес-процессов.

Ранее руководила направлением eCommerce в интернет-магазине женской одежды и аксессуаров «ZARINA». Отвечала за маркетинг в «220 вольт», работала в компании «Юлмарт» и образовательной сети «Дневник.ру», консультировала сеть ювелирных магазинов «585 Золотой».

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

Когда нет прозрачной системы отчетности, очень сложно заниматься аналитикой. Огромных усилий стоит связать данные из интернета с данными из офлайн-источников. Сложно понять, по каким признакам их объединить.

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

— сотрудники интернет-магазина собирают данные с помощью Google Analytics или Яндекс Метрики;

— отдел продаж и отдел закупок пользуется ERP-системами, например, 1С;

— колл-центр работает в какой-то CRM-системе: Mindbox или аналоге;

— когда появляется мобильное приложение, там используется уже собственная система аналитики, например, Firebase. Эти системы аналитики используют другую систему хранения данных — Google BigQuery — возникает необходимость рассылать триггерные письма или SMS, и для этого подключают свой сервис — например, Retail Rocket.

Получается «зоопарк источников данных», где каждый источник живет своей жизнью. Отслеживать переходы клиентов между системами приходится вручную.

Аналитикам некогда заниматься аналитикой. Из-за ручного режима формирования отчетов, менеджеры постоянно обращаются к аналитикам с новыми запросами: «А пришли мне вот эти данные». Аналитик их выгружает. «А пришлите мне другие данные». Аналитик их выгружает. «А теперь в первый отчет нужно добавить вот такой параметр». И вместо того, чтобы заниматься анализом, аналитик превращается в «выгружателя данных», и вся система работает неэффективно.

Создание нового отчета из 1С требует отвлекать 1С-разработчиков. Часто аналитика не является приоритетной задачей. У разработчика всегда есть длинный бэклог, в котором задачи по аналитике висят в самом конце списка. Когда же до них доходит очередь, включается еще и ранжирование отделов — аналитические отчеты для финансистов всегда будут сделаны раньше отчетов для маркетологов. Очередь копится, пока решения в компании принимаются «на коленке», без конкретных цифр.

Подробные отчеты за длительные периоды долго выгружать. Допустим, нужно выгрузить данные о продажах за 10 лет с разбивкой по каждому заказу. Такой отчет будет выгружаться из 1С несколько часов или дней. Бывали случаи, когда 1С просто «ложился», так и не выгрузив необходимые данные. Это приводило к коллапсу всей ИТ-инфраструктуры, так как в 1С не только хранят отчеты, но и ведут все операционные процессы.

Функционирование системы аналитики зависит от человеческого фактора. Часто всю эту схему держит в голове один или несколько человек. Они уходят в отпуск или в декрет или вовсе увольняются, и в компании случается апокалипсис: никто не знает, откуда выгрузить нужные данные, какие-то системы забывают оплатить и их отключают, какие-то платформы выходят из строя, и никто не знает как их починить.

Нет единой версии правды: одинаковые метрики не сходятся в разных отчетах. Например, маркетологи оперируют веб-данными и считают оборот в Google Analytics, а отдел продаж смотрят оборот в 1С. И часто вот бывает, что отдел продаж приходит к маркетологу: «Почему у нас опять нет продаж?». А маркетолог показывает: «Вот же, смотрите у меня в гугл-аналитике, я сделал 5 миллионов». А в 1С отображается только 3 миллиона. Куда делись 2 миллиона? Где-то стоят разные фильтры, где-то не подгружаются какие-то данные, где-то информация по-разному интерпретируется. И никто не знает, кто прав.

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

Когда в инфраструктуре компании больше 5 инструментов аналитики, когда выгрузка отчета требует дольше 5 минут, когда специалисту нужно подойти к нескольким людям, чтобы разобраться, где взять какие-то данные — это признаки, что в компании нет прозрачной системы аналитики. В этом случае для решения задач лучше всего подходит построение OLAP-кубов.

Преимущества OLAP-кубов:— единая система аналитики на уровне организации объединяет данные из всех источников;

— заранее согласованные отчеты обновляются в реальном времени;

— все метрики одинаковы во всех отчетах компании;

— старые инструменты аналитики не требуется менять, ломать и перестраивать.

Пользователь открывает пустую страницу Excel. При первом подключении нужно будет получить доступ к OLAP-кубу и выбрать формат сводной таблицы отчета. В следующий раз все будет загружаться автоматически.

Описать бизнес-кейсы. Для начала, собираем информацию внутри компании у каждого отдела: изучаем отчеты, которые используют чаще всего, и метрики, которые регулярно мониторят.

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

Сформировать роадмап по областям данных. Допустим, у нас есть система логистики, система бухгалтерии, есть продажи, есть данные из интернет-магазина. Это все области данных, они хранятся в своих базах, из которых мы должны будем эти данные получать. Делим работу на итерации и поэтапно планируем подключение этих источников.

Спроектировать модель хранилища данных — Data Warehouse. BI-разработчик строит архитектуру, как и откуда собирать данные, как их склеивать между собой.

Создать хранилище данных и OLAP-куб. На разработку первой работающей версии обычно достаточно 2-3 недель.

Протестировать и доработать хранилище данных и OLAP-куб. Бизнес-аналитик начинает пользоваться OLAP-кубом, проверяет корректность данных и заполнение полей, консультирует разработчика по все новым бизнес-кейсам и форматам отчетов.

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

Бизнес-аналитик. Требования:

— знакомство с основными системами аналитики;

— знание методик исследования, анализа и моделирования бизнес-процессов;

— опыт написания технической документации;

— умение разбираться в неизвестной предметной области в короткие сроки;

— аналитическое мышление и умение систематизировать информацию;

— опыт проведения обучения пользователей;

— опыт командной разработки в ходе реализации проекта, в том числе постановка задач разработчикам.

BI-разработчик. Требования:

— знания в области методологии проектирования хранилищ;

— знание схем организации данных «Звезда» и «Снежинка»;

— опыт в проектировании и реализации процессов интеграции приложений и данных, процесс обеспечения качества данных;

— ETL-процессы: интеграция нескольких систем между собой, создание приложений, которые связывают одну систему источник с другой системой;

— умение оптимизировать запросы и планы их выполнения, знания возможных путей увеличения производительности запросов, смена структуры таблиц, изменения запросов;

— умение работать в команде с аналитиками и умение находить общий язык с неспециалистами в разработке.

Решение подойдет и для малых компаний с оборотом от 2-3 млн. рублей в месяц и количеством сессий до 1 млн. в месяц, и для крупных бизнесов с миллиардным оборотом и сотнями миллионов сессий.

Подготовительный период займет одну-две недели, создание OLAP-куба потребует примерно месяц работы разработчика, еще примерно месяц потребуется на доработки и адаптацию сотрудников. Первый рабочий результат обычно готов уже через месяц, весь проект занимает 2—3 месяца.

Инвестиции в проект зависят от сложности IT-инфраструктуры, количества источников данных и объема данных. Для среднего интернет-магазина инвестиции составят 300—400 тыс. рублей. Сюда входит работа бизнес-аналитика, BI-разработчика и необходимое ПО. Когда все основные задачи и отчеты будут завершены, останется только минимально поддерживать работу OLAP-куба и вносить незначительные изменения, обычно это стоит не больше 30 тыс. рублей в месяц.

Чаще всего используют продукты Microsoft. Они изначально предназначены для удобной синхронизации между собой, это позволяет сэкономить время разработчика на интеграцию.

Data Warehouse: SQL Server.

OLAP Engine: Analysis Services (Multidimensional/Tabular).

Витрина данных: Power BI или Excel.

Если остались вопросы о создании OLAP-кубов, обращайтесь в BI Tool или лично к CEO Елизавете Гринберг в Facebook.

В Heads and Hands мы разрабатываем цифровые сервисы на основе web и mobile. Рассказываем в Facebook о разработке мобильных приложений. Запустили курс для менеджеров и собственников бизнеса.

#ecommerce #mcommerce #analytics #olap #bigdata #data_insight #аналитика #mobile #деньги