При чем здесь баян?

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

Проблема в том, что когда кнопок становится слишком много, заказчики начинают в них путаться, и что самое страшное – в них начинает путаться сам аналитик. Где какая метрика лежит, где отвалилось обновление, где у меня ODBC работает через локальный шлюз, а где через сертификат напрямую в PostgreSQL и так далее. Но как только мы начинаем чистить систему, начинают возникать заказчики, у которых внезапно “сломалось”, хотя дашборд они не открывали несколько месяцев. 

Мы проходили подобный процесс раза 4 точно, обычно он запускается при смене людей на руководящих позициях. Причины могут быть разнообразные – кому-то нужна отчетность на телефоне, потому что он постоянно бегает по офису, кто-то наоборот, хочет сидеть и “копать” много страниц с аналитикой и графиками. Некоторые вообще BI-систему впервые видят и удивляются, как можно отслеживать показатели без Excel. Возможно, коллегам из IT-компаний подобные штормы покажутся чем-то диким, но я хочу предложить кейс из FMCG, где бизнес не так хорошо обложен метриками и оцифрован.

Сделаем сразу акцент на том, что речь идет не про IT-компании. И дело не в том, что “айтишники” чем-то лучше или хуже других отраслей – у них попросту иначе выстроены процессы. Для примера, в IT куда более развита практика бизнес-анализа и сбора требований, в то время, как договориться с бизнесом “на берегу” в реальном секторе бывает очень сложно. Условный коммерческий директор или директор по логистике вряд ли захочет часами сидеть с аналитиком и разрабатывать макет дашборда – ему все же платят не за это и у него наверняка есть другие, требующие внимания вещи. 

С чего все началось

В начале перехода от монолитной BI-структуры к раздельной у нас был очередной раздутый “баян”. Было много дашбордов, никто ими не пользовался, за исключением 2-3, которые открывал РОП на совещании по понедельникам. На одном смотрели отгрузки и категории товара, на другом финансовую составляющую бизнеса. Ориентируясь на кейс Ромы Бунина, решили перейти к  структуре сущностей и процессов, ввели условное “Ядро” и “Периферию”. Сделали иерархию дашбордов от CEO-overview до отчетности по городам, с переходами, ссылками и комментариями и принципами UI/UX. Но этого оказалось недостаточно. РОП систему похвалил, так как он постоянно находится в кабинете и работает, в целом, с офисными сотрудниками и изредка с полевым персоналом. 

Но вдруг оказалось, что помимо РОПа отчетность также интересовала и коммерческого директора, который ранее получал Excel`ки от вышеупомянутого менеджера и помощников, но увидел BI и захотел себе такой же. Появилась новая проблема – как нам сжать весь бизнес в один лист. Казалось бы – есть ключевой дашборд CEO-overview, но существовал один нюанс. Большую часть времени ноутбук коммерческого директора пылится в кабинете и для того, чтобы посмотреть дашборд, ему нужно было открыть ссылку, ввести пароль для доступа к системе отчетности, найти нужный дашборд и пытаться что-то разглядеть на экране телефона. Какой из этого вывод? Проще запрашивать Excel с табличкой в 10 строк у помощника, чем идти к этим аналитикам с их неудобными сервисами. Как вы понимаете, ситуация в BI, когда пользователю неудобно – ужас, и уж тем более, если пользователь является C-level менеджером. 

Как решать проблему

Мы решили чуть раздуть баян, но в специфическом направлении. Какое было ТЗ? Никаких интервью, верстки макетов, демонстраций превью. Буквально «Сделать нормально, чтобы я с телефона видел». Тогда мы пришли к выводу, что наша цель — не дашборд, который удобно смотреть с телефона, а дашборд, на считывание которого должно требоваться не более 3 свайпов по экрану. Да, настолько сжато нужно было передать KPI бизнеса. То есть это буквально 3–4 чарта — большое число, график за последние 30 дней, еще одно большое число, еще один график на последние 12 месяцев, табличка с 7 строк и 3 столбца. И аналогичная страница, но только не по отгрузкам, а по оплатам.

Дашборд получил кодовое название «Карман». Хотя, я бы даже дшбордом его не назвал. Он помещался в экран телефона и обновлялся каждые 10 минут, при этом не нес совершенно никакой информации о товарах, никаких ABC‑анализов, остатков по регионам, кластеризации клиентов и прочих повседневных вещей, которые использует РОП. Мы закрыли главную потребность коммерческого директора — достать телефон, нажать одну кнопку, свайпнуть вниз, убрать телефон.

Решение настолько понравилось, что к нему начали приобщаться и другие менеджеры, так как в компании мы очень любим совещаться без ноутбуков, но смотреть на данные в процессе совещаний хотим. Все захотели себе карманные мониторинги, позволяющие оценить ситуацию в их направлении за 3 касания экрана. Таким образом, помимо основного баяна появилась небольшая гармошка, которая начала так же раздуваться, но уже исключительно в рамках мобильной верстки. Однако, параллельно с этим начал сдуваться основной «десктопный» баян и перешел исключительно на обслуживание РОПа и нескольких периферийных дашбордов.

Что получилось

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

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

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

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

Философское заключение

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

Речь идет о методе передачи бизнес-информации в максимально возможном сжатом виде. Концептуально – отход от BI, как веб-сервисов с цифрами и графиками к BI, как группе методов пользы для бизнеса. 

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