Подводные камни на пути к data-driven: принцип GIGO

Недавно я выступал на РИФ с одноимённым докладом в программе 2.0 в секции «Модная тема — дашборды для бизнеса». Запись этой секции не проводилась, поэтому я решил собрать основные мысли в статье.

Меня зовут Алексей Сидоров. Я чуть больше десяти лет занимаюсь интернет-маркетингом и веб-аналитикой, а последние три года — бизнес-аналитикой. Мы внедряем управленческую отчётность для различных направлений бизнеса на множестве источников данных, предлагаем рынку собственный сервис по выгрузке данных из онлайн-источников и формированию хранилища и ведём блог про продукт MS Power BI.

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

Дашборды для бизнеса — это действительно модная история, причём порой с не самым позитивным значением этого слова. По моей оценке, около 3% компаний, интересующихся BI, доходят до дашбордов, которые действительно влияют на прибыль компании.

За этот прогноз я сразу вынужден извиниться перед коллегами — у меня нет для его подтверждения, это субъективная оценка, исходя из работы с текущими обращениями. Такой низкий процент связан, на мой взгляд, с тем, что сами дашборды — это самая вкусная и, пожалуй, самая простая часть айсберга.

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

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

Примерно 50% поступающих к нам входящих тёплых лидов, людей, которые при разговоре действительно вроде чего-то хотят, рассеивается в воронке где-то до статуса «Сформирована задача». В качестве задачи мы принимаем хотя бы список показателей и параметров, которые в результате нужны клиенту, и краткое описание того, зачем и как он хочет их использовать.

Это очень важный вопрос, который нужно с самого начала решить — а что вообще повлияет на прибыль? Какой отчёт, какой показатель, в каком разрезе нужно видеть, чтобы он был полезен для принятия решения?

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

Представляете такое ТЗ, к примеру, на дом? А ведь небольшой загородный дом сейчас строится порой быстрее, чем сложная BI-система.

Для решения этого вопроса мне сильно импонирует концепция jobs to be done, про которую сейчас много пишут. Подумайте, какую работу должен выполнять отчёт? Какие именно данные, в какой момент времени и для чего вам необходимы? Можно прямо вот в такой форме и записать ответы:

Когда я ___________________, мне необходимо увидеть ________________________, чтобы сделать вывод о _______________________.

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

Важно, чтобы всеми знаниями относительно будущей отчётности обладал не только её заказчик (руководитель), но и тот, кто занимается её внедрением в компании. Ответственный за эту задачу менеджер должен понимать конечную цель, понимать логику работы отчёта и показателей в ней, брать на себя ответственность за принятия решений и, наконец, должен быть мотивирован эту задачу решать.

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

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

Тут стоит отметить, что это бывают вполне объективные причины — когда сотрудник перегружен своими основными задачами, а тут к нему прилетает какая-то отчётность непонятно для чего и кому вообще нужная.

Какой самый старый софт вы помните? ICQ, Winamp, Alcohol 120%, игру «Сапёр»? Может быть, Norton или Lexicon? В прошлом году нам предложили оценить возможность перехода на Power BI с аналитической системы 1984 года выпуска. 1984, Карл!

В любом работающем бизнесе всегда присутствует множество систем, в которых отражаются важные (а иногда и не очень) для конечных решений данные. «1С», счётчики статистики, CRM, рекламные кабинеты — все живут своей жизнью. Каждая из них хранит свои специфические сущности — чеки, отгрузки, посещения, события, клики, расходы, клиентов.

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

Это приводит к тому, что в компаниях появляется большое количество различных систем, которые просто накопились с течением времени. О многих из них уже забыли. Откуда они взялись и зачем они вообще нужны, никто не знает, с другими ещё как-то работают, но для чего — тоже не понятно, или они просто не настроены оптимальным образом для конкретного случая.

Редко встречаются компании, в которых все системы подобраны, настроены и работают хотя бы хорошо, в основном это всё напоминает классический «зоопарк» программного обеспечения.

В реальных условиях — систем много, данные в них дублируются, вводятся и анализируются вручную, генерируя множество разных таблиц, в которых и варится компания. Это всё выливается в следующую проблему.

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

Исторически сложилось так, что в сегменте малого и среднего бизнеса мы очень редко встречаем осознанный подход к накоплению и консолидации данных. Нет дополнительных полей в «1С», установлены, но не настроены счётчики веб-аналитики, не считаются звонки, всё свалено в одну кучу. Получается настоящий клубок из различных систем, которые уже успели накопить множество разрозненных и некорректных данных.

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

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

Я до какого-то времени думал, что в крупных компаниях дела обстоят иначе. Но нет, вот классический пример — на майских праздниках ко мне заезжал однокурсник из банка, входящего в десятку крупнейших, и делился своей печалью — его рисковая модель перестала работать, просто потому что ИТ-шники поменяли id клиентов. В прошлом месяце у клиента был один идентификатор, а в этом стал другой, история не подтягивается, оценка рисков не работает, отчёты показывают туфту.

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

Всё это можно легко описать довольно старым принципом, который ранее получил широкое распространение в информатике, а не так давно приобрёл новое и, наверно, более актуальное значение в анализе данных — garbage in, garbage out. Смысл его в нашем случае очень прост: если на входе имеются искажённые и неполные данные, то никакой алгоритм не сможет из них сделать что-то полезное.

Если компания решила стать современной и начать принимать решения на основе данных, то ей придётся меняться изнутри как в организационном, так и в техническом подходе к бизнесу. Только в этом случае дашборды станут необходимостью и смогут принести реальные результаты для дальнейшего развития. Иначе это просто мода и трата денег на ветер — красивые картинки, которые не принесут конечной пользы и забудутся через пару месяцев.

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

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

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

Далее я приведу краткое описание кейса пользователя нашего сервиса myBI Connect — Алексея Верткова. Благодаря успешному преодолению всех подводных камней Алексей добился повышения продаж небольшой оптовой компании на 38% менее чем за два месяца. Последовательность простых и хорошо известных шагов, была применена в рамках небольшого отдела продаж. Эти шаги привели к хорошей встряске и сильному повышению его эффективности.

Итак, на старте, компания имела отдел продаж из четырёх человек, продажи велись в хаотичном порядке, CRM-система велась без каких-либо нормативов, повторные продажи не регулировались. В целом болей было много, но основные были именно в объёме продаж, на что и решили начать воздействовать. Что было сделано?

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

Результаты не заставили себя долго ждать, по итогам девяти недель:

Этот кейс отражает основную мысль моей статьи — все подводные камни можно избежать, но важно подходить к каждому осмысленно. Неважно, как вы подходите к вопросу перехода на data-drive, самостоятельно или с помощью сторонних специалистов — отчётность не появится сама собой, ей нужно заниматься и вкладывать в этот процесс время и ресурсы. И это обязательно принесёт результаты.

#кейсы #маркетинг