Недавно я выступал на РИФ с одноименным докладом в программе 2.0 в секции «Модная тема — дашборды для бизнеса». Запись этой секции не проводилась, поэтому я решил собрать основные мысли в статью.
Дашборды для бизнеса — это действительно «модная» история, причем порой с не самым позитивным значением этого слова. По моей оценке, менее 3% компаний, которые начинают интересоваться BI доходят до конечных успешных дашбордов. Под успешным дашбордом я понимаю отчет, который приносит реальную пользу. За эту цифру я сразу вынужден извиниться перед коллегами — у меня нет для нее подтверждения, это субъективная оценка, исходя из работы с текущими обращениями. Такой низкий процент связан, на мой взгляд, с тем, что сами дашборды это самая вкусная и, пожалуй, самая простая часть айсберга…
Вот где-то там в облаках на своем вертолете хочет пролетать руководитель, смотреть на этот айсберг сверху, принимать решения и лететь к следующему. И в целом это совершенно верный подход — с этим не поспоришь. Но реальность такова, что под каждым дашбордом скрывается достаточно много подводных камней. Вот именно о них мне бы и хотелось поговорить.
Я постараюсь описать проблемы, которые свойственны и маркетинговым и финансовым внедрениям, рассказать про процессные и технические проблемы в общем.
Я не знаю
Примерно 50% поступающих к нам входящих теплых лидов, людей, которые при разговоре действительно вроде чего-то хотят, рассеивается в воронке где-то до статуса «Сформирована задача». В качестве задачи мы принимаем хотя бы список показателей и параметров, которые в результате нужны клиенту и краткое описание того, зачем и как он хочет их использовать.
Это очень важный вопрос, который нужно с самого начала решить — а что вообще повлияет на бизнес? Какой отчет, какой показатель, в каком разрезе нужно видеть, чтобы он был полезен для принятия решения?
К сожалению, точный ответ могут дать редко. А еще хуже, что порой это выясняется слишком поздно. Казалось бы, что клиент точно знает, что ему нужно, мы сможем построить полезный отчет, он поможет заработать больше, но нет. В диалогах появляются такие фразы:
- «Примените бест практики в отчете»
- «Сделайте так, чтобы мы могли эффективно управлять»
- «Ну вы что-нибудь постройте, а мы скажем подойдет или нет»
- «В смысле, что должно быть в отчетах? Вы вообще эксперт? Решите сами»
Представляете такое ТЗ к примеру, на дом? А ведь небольшой загородный дом сейчас строится порой быстрее чем сложная BI-система.
Для решения этого вопроса мне сильно импонирует концепция jobs to be done, про которую сейчас много пишут. Подумайте, какую работу должен выполнять отчет? Какие именно данные, в какой момент времени и для чего вам необходимы? Можно прямо вот в такой форме и записать ответы:
Когда я ____________________ мне необходимо увидеть _____________________, чтобы сделать вывод о __________________.
Только после того как будет хоть как-то сформирована задача, станет понятно, что именно и для какой цели необходимо, можно будет идти дальше и решать организационные вопросы и проблемы с самими данными.
Делегирование
Очень важно, чтобы всеми знаниями относительно будущей отчетности владел не только ее заказчик (руководитель), но и тот, кто занимается ее внедрением в компании. Менеджер ответственный за эту задачу должен понимать конечную цель, понимать логику принятия решений, брать на себя ответственность за принятия решений и, наконец, должен быть мотивирован эту задачу решать.
К сожалению, мы часто сталкиваемся с проблемами организационной структуры – на первый взгляд заказчик понимает все, что ему нужно, мы обрисовываем план интеграции и получения данных, на горизонте снова начинает маячить успешный кейс… но нет — мы спотыкаемся на том, что сотрудники заказчика не готовы погружаться в задачу для ее успешного решения, не хотят разбираться, не хотят брать на себя ответственность, не готовы к тому, чтобы решать задачи, которые остаются на их стороне. Причин может быть много — им просто лень, не хватает компетенций, есть опасения проявить себя плохо в этой задаче, не понимают зачем нужны эти отчеты и по какой логике должны быть построена.
Тут стоит отметить, что это бывает вполне объективные причины — когда сотрудник перегружен своими основными задачами, а тут к нему прилетает какая-то отчетность непонятно для чего и кому вообще нужная.
«Зоопарк» ПО
Какой самый старый софт вы помните? Аську, винамп, alcohol, сапера? Может быть Norton или Lexicon? В прошлом году нам предложили оценить возможность перехода на Power BI с аналитической системы 1984 года выпуска. 1984, Карл!
В любом работающем бизнесе всегда присутствует множество систем, в которых отражаются важные, а иногда и не очень, для конечных решений данные. 1С-ки, счетчики статистики, CRM, рекламные кабинеты — все живут своей жизнью. Каждая из них хранит свои специфические сущности — чеки, отгрузки, посещения, события, клики, расходы, клиенты.
В большинстве случаев эти системы появляются не сразу, а по мере развития бизнеса, и во многих случаях их набор обоснован какими-то косвенными факторами: кто-то посоветовал, что-то понравилось, кто-то внедрил, а потом уволился, и т.д. Это приводит к тому, что в компаниях появляется большое количество различных систем, которые просто накопились с течением времени. О многих из них уже забыли, откуда они взялись и зачем они вообще нужны никто не знает, с другими еще как-то работают, но для чего тоже не понятно или они просто не настроены оптимальным образом для конкретного случая…
Редко встречаются компании, в которых все системы подобраны, настроены и работают хотя бы хорошо, в основном это все напоминает классический «зоопарк» программного обеспечения.
В реальных условиях — систем много, данные в них дублируются, вводятся и анализируются вручную, генерируя множество разных экселей, в которых и варится компания. Это все выливается в следующую проблему…
Культура работы с данными
Одной из типичных проблем является желание визуализировать данные, которых попросту нет.
Исторически сложилось так, что в сегменте малого и среднего бизнеса мы очень редко встречаем осознанный подход к накоплению и консолидации данных. Нет дополнительных полей в 1С-ке, установлены, но не настроены счетчики веб-аналитики, не считаются звонки… все свалено в одну кучу. Получается настоящий клубок из различных систем, которые уже успели накопить кучу разрозненных и некорректных данных.
Это приводит к том, что клиент «свято» верит в то, что у него есть все для того чтобы ему сделали необходимый отчет. На удивление некоторые исполнители даже берутся и что-то делают, вот только проблема в том, что по сути данных нет… то есть назвать то что накопилось за несколько лет работы данными, конечно можно, вот только они в таком виде, что сделать на основе их какое-то качественное представление о реальном состоянии бизнеса просто невозможно. Накопление некоторых данных носит какой-то спорадический характер, другие данные по какой-то причине становятся сильно изменчивыми, то что ранее было одним может стать чем-то абсолютно иным сегодня и прочее прочее.
Я до какого-то времени думал, что в крупных компаниях дела обстоят иначе. Но нет — на майских праздниках ко мне заезжал однокурсник из банка, входящего в топ-10 и делился своей печалью — его рисковая модель перестала работать, просто потому что it-шники поменяли id клиентов. В прошлом месяце у клиента был один идентификатор, а в этом стал другой, история не подтягивается, оценка рисков не работает, отчеты показывают туфту.
Некоторые компании об этом и не догадываются, так как их бизнес это не данные, а продажи, строительство или что-то еще. Штатных специалистов, которые могли бы об этом рассказать руководителю либо нет, либо они предпочитают это умалчивать. Да и вообще специалистов, которые хотят и умеют погружаться инфраструктуру данных на рынке совсем немного, в основном все хотят конечных отчетов, не зная, как их строить.
Принцип GIGO
Все это можно легко описать довольно старым принципом, который ранее получил широкое распространение в информатике, а не так давно приобрел новое и, наверно, более актуальное значение в анализе данных — garbage in, garbage out. Смысл его в нашем случае очень прост, если на входе имеются искаженные и неполные данные, то никакой, даже верный алгоритм не сможет из них сделать что-то полезное.
Если компания решила стать современной и на самом деле начать принимать решения на основе данных, то ей придется меняться изнутри, как в организационном, так и в техническом подходе к бизнесу. Только в этом случае дашборды станут необходимостью и смогут принести реальные результаты для дальнейшего развития. В противном случае, это просто «мода» и как результат трата денег на ветер – красивые картинки, которые не принесут конечной пользы и забудутся через пару месяцев.
Data-Driven Business
Во-первых, стоит отметить, что приведенные проблемы являются нормой, с ними сталкиваются все. В реалиях нашего бизнеса на первом месте всегда находится создание работающей и прибыльной бизнес модели, именно этот процесс порождает и множество учетных систем и разрозненность данных и прочее прочее, это неизбежно. Важным тут является подход к решению этих проблем. Независимо от того, будете вы делать это самостоятельно или привлечете специалистов по внедрению, вам будет нужно погружаться в эти проблемы.
Нужно быть готовым к тому, что вам может понадобиться менять подход к организации работы, делать изменения в текущих учетных системах, обучать людей, контролировать эти изменения. Компании с таким подходом мы очень любим — только с ними получается приходить к результатам.
Далее я приведу краткое описание кейса пользователя нашего сервиса myBI Connect — Алексея Верткова. Благодаря успешному преодолению всех подводных камней Алексей добился повышения продаж небольшой оптовой компании на 38% менее чем за 2 месяца. Последовательность простых и хорошо известных шагов, была применены в рамках небольшого отдела продаж. Эти шаги привели к хорошей встряске и сильному повышению его эффективности. Полный текст этого кейса приведен здесь.
Итак, на старте, компания имела отдел продаж из 4 человек, продажи велись в хаотичном порядке, CRM система велась без каких-либо нормативов, повторные продажи не регулировались. В целом болей было много, но основные были именно в объеме продаж, на что и решили начать воздействовать. Что было сделано?
- Полная ревизия клиентской базы и квалификация контрагентов, были добавлены новые поля и категории.
- Проведено несколько совещаний с сотрудниками и подготовлены точные инструкции по ведению данных в CRM.
- Определены и зафиксированы показатели, на которые решили влиять.
- Именно они стали основной для мотивации продавцов. Была изменена система расчета премий.
- Далее с помощью myBI Connect была настроена регулярная выгрузка данных из CRM в хранилище и с помощью Power BI было построено несколько простейших отчетов
Кроме этого было создано несколько управленческих отчетов для ABC-анализа категорий клиентов, их источников, работы менеджеров и прочего.
Результаты не заставили себя долго ждать, по итогам 9-ти недель:
- продажи выросли на 38%
- количество обработанных заявок выросло в 2 раза
- сократились трудозатраты на контроль работы менеджеров
- стали понятны ошибки в привлечении клиентов, исходя из их конечной прибыльности
Этот кейс прекрасно отражает основную мысль моей статьи — все подводные камни можно избежать, но важно подходить к каждому осмысленно. Неважно, как вы подходите к вопросу перехода на Data-Drive подход, самостоятельно или с помощью сторонних специалистов — отчетность не появится сама собой, ей нужно заниматься и вкладывать в этот процесс время и ресурсы. И это обязательно принесет результаты!
