Пример систем дашбордов

В предыдущей главе описана структура Dashboard Map и логика его построения. Ниже — примеры того, как этот фреймворк применяют на практике.

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

Вы увидите, как построить Dashboard Map и как подобрать дашборды разных типов в каждом из кейсов:

• Система для всей компании — небольшого ресторана.
• Система дашбордов для отдела продаж.
• Примеры применения подхода в крупных IT-компаниях.

РесторанРесторан

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

Получается такой список:

Список ролей в ресторане

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

После того как список ролей составлен, следующий шаг — определить объекты управления в компании.

В этом примере объектами управления будут:

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

Объекты и процессы в ресторане

Чаще всего объекты управления легко восстановить по оргструктуре. Но чтобы ничего не упустить, полезно снова пройтись по ролям и задать себе вопрос: чем управляет этот сотрудник? Так список ролей становится чек-листом. К предыдущим шагам придётся возвращаться ещё не раз — это нормальная часть работы над картой.

Когда объекты управления определены, можно переходить к процессам. Здесь снова помогает список ролей. Стоит спросить себя: что именно делает этот человек в течение дня? В каких процессах участвует? Из каких этапов они состоят?

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

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

Описание бизнес-процесса закупки товаров

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

Последовательность действий всех процессов в ресторане

Теперь можно переходить к основной части разработки Dashboard Map — подбору конкретных дашбордов. Здесь работает простой алгоритм. Нужно пройтись по всем объектам управления и точкам контроля и определить, какие дашборды помогут следить за бизнесом. Важно не придумывать отчёты «на всякий случай», а связывать каждый дашборд с конкретной зоной ответственности или моментом принятия решения.

Для любого подразделения или направления бизнеса в системе всегда появляются два базовых типа отчётов — overview и self-service. В данном случае получатся overview-отчёт «Ключевые показатели ресторана» и self-service-отчёт «Self-service по заказам».

Два базовых типа отчётов для ресторана

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

В данном примере это страницы объектов управления «Кухня», «Зал» и «Приложение». Формально кухню и зал можно рассматривать как отдельные подразделения, каждое со своей собственной системой дашбордов, но при небольшом размере компании это лишнее усложнение. Выделять отдельные системы дашбордов стоит, если ими будут пользоваться больше 20–30 человек.

Объекты управления ресторана

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

Другая ситуация — процессы, где важна скорость реакции. Здесь без алертов не обойтись.

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

• при контроле остатков на складе — чтобы заранее понимать, не придётся ли ставить блюда «на стоп»;
• при контроле времени подачи блюд — чтобы не допускать задержек и вовремя реагировать.

Алерт нужен там, где промедление напрямую влияет на бизнес.

Точки контроля, для которых необходимы алерты

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

Точки контроля, для которых необходимы эксперименты

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

Для такого анализа приходится учитывать сразу несколько факторов — статистику продаж, уровень удовлетворённости клиентов, себестоимость, срок хранения и другие показатели. Работать с таким объёмом информации удобнее в отдельном аналитическом инструменте, где можно сравнивать, фильтровать и искать закономерности.

Точка контроля, для которой необходим аналитический дашборд

Если в процессах появляются не регулярные операции, а разовые проекты, для них можно сделать отдельный дашборд. Но важно понимать: такой дашборд не должен автоматически становиться частью системы. Его задача — временно поддержать изменение. После завершения проекта он либо исчезает, либо его полезные части «переезжают» в другие отчёты, если проект становится постоянной частью бизнеса. В случае ресторана таким проектом может быть запуск продаж мерча. Дашборд в этом случае помогает увидеть, как идёт запуск, где возникают проблемы и что требует внимания. Если продажа мерча закрепится как регулярное направление, соответствующие показатели логично встроить в overview и другие постоянные дашборды.

Дашборд для разового проекта

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

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

В финальной версии Dashboard Map собрана вся информация:

Dashboard Map ресторана

Этот кейс довольно простой, но на понятном и универсальном примере показывает принципы построения системы с помощью Dashboard Map. В реальной жизни процессов, скорее всего, будет больше.

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

Система дашбордов ресторана

Система включает дашборды разных типов: overview, self-service, страницы объектов управления, алерты, отчёты по экспериментам и аналитические инструменты. Каждый из них решает свою задачу и связан с конкретными ролями и процессами.

Overview-отчётOverview-отчёт

Здесь выстроена общая логика работы ресторана, есть общие метрики: выручка, продолжительность готовки. Есть топы по категориям и блюдам. Если нажать на категорию, можно перейти на более детальные отчёты.

Overview-отчёт ресторана

Self-service-отчётSelf-service-отчёт

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

Структура простая: слева — фильтры, справа — таблица с результатами.

Self-service-отчёт ресторана

Страница объектов управленияСтраница объектов управления

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

Страница объектов управления с детальной информацией о кухне

АлертыАлерты

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

Алерты, сообщающие о задержке в приготовлении блюд

Отчёт по экспериментуОтчёт по эксперименту

В ресторане ввели новое блюдо. Чтобы следить за тем, как изменения отразились на бизнесе, можно составить дашборд с результатами А/B-тестирования. Здесь есть описание рецепта и результат: блюдо по новому рецепту сработало хуже, чем другие блюда. Об этом говорят результаты по продажам и удовлетворённости клиентов.

Отчёт по эксперименту с результатами А/B-тестирования

Аналитические инструментыАналитические инструменты

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

Аналитические инструменты для исследования показателей блюд

Отдел продаж онлайн-школыОтдел продаж онлайн-школы

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

Карта дашбордов отдела разработки и запуска новых курсов онлайн-школы

В крупной компании у каждого отдела появляется своя система отчётности. Поэтому общая система дашбордов собирается из нескольких Dashboard Maps — по одной для каждого подразделения. Эти карты затем объединяются в общую систему.

Такая система отчётности становится фракталом: структура повторяется у каждого отдела, но содержание отличается.

Система отчётности в компании и её подразделениях

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

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

Отделу продаж нужна система, которая позволяет:

• видеть ключевые показатели;
• контролировать работу менеджеров;
• понимать, какие каналы привлечения работают лучше, а какие проседают.

Основные роли в отделе продаж:

Основные роли в отделе продаж

Следующий шаг — определить объекты управления в отделе. Первым нужно выделить сам отдел продаж. Отдельных продуктов здесь нет, но появляется важный объект управления — процесс продаж. Менеджеры по продажам (это понятно уже из названия роли) отвечают за результат сделки. Поэтому в фокусе оказывается не отдельная точка контроля, а весь процесс целиком — от первого контакта до оплаты. На это можно посмотреть и иначе: менеджер управляет не абстрактным процессом, а конкретным набором лидов, которые находятся в его работе. Фактически именно этот портфель лидов и становится объектом управления.

Также нужно описать процессы отдела продаж:

Объекты и процессы отдела продаж

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

Сначала создаются отчёты для подразделения — overview и self-service:

• для всего отдела — overview-отчёт «Ключевые показатели продаж B2C»;
• для работы с конкретными лидами и выгрузками — self-service-отчёт «Лиды».

Далее добавляются страницы объектов управления. В этом случае для контроля процесса продаж — страница объекта управления «Менеджер продаж».

После этого стоит пройтись по процессам и их точкам контроля:

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

После уточнения метрик и срезов получается готовый Dashboard Map:

Dashboard Map отдела продаж онлайн-школы

Получившийся Dashboard Map заметно отличается от Dashboard Map для отдела разработки курсов, и это закономерно. Исходные данные почти те же, но задача у подразделения другая, а значит, и система дашбордов будет иной. Проектирование системы может быть довольно простым. Ключевое — корректно описать роли, объекты управления и точки контроля. Если этого не сделать, начинается хаотичный выбор: «нужен такой дашборд, а может, ещё вот этот». Система формируется случайно и быстро разрастается. Когда же роли и точки контроля зафиксированы, появляется алгоритм. И уже не дашборды ищут себе применение, а каждый отчёт появляется как ответ на конкретную задачу.

Ниже — примеры дашбордов, которые могут получиться для отдела продаж.

Overview-отчётOverview-отчёт

Это ключевой дашборд, который необходим для отдела. На нём показаны основные метрики:

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

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

Overview-отчёт по продажам курсов

Отчёт self-serviceОтчёт self-service

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

Отчёт self-service по продажам курсов

Страница объекта управленияСтраница объекта управления

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

Страница менеджера для анализа работы

Аналитический инструментАналитический инструмент

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

Аналитические инструменты с детализацией по каналам и кампаниям

АлертАлерт

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

Дашборд-алерт для менеджера по продажам

В итоге получилась компактная система из пяти типов дашбордов: overview, self-service, страница объекта управления, алерт и аналитический отчёт. Такой набор закрывает операционные задачи отдела и помогает видеть, где проседает реклама и что стоит улучшить. Система остаётся сбалансированной: у каждого типа отчёта своя роль, а каждая задача — на своём месте.

Примеры применения в крупных компанияхПримеры применения в крупных компаниях

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

Yandex GOYandex GO

Когда я руководил BI-командой в Yandex GO, перед нами стояла задача навести порядок в дашбордах сразу в нескольких подразделениях — примерно в 15 направлениях бизнеса. Мне хотелось выстроить систему отчётности для каждого из них. Но прежде чем менять что-то в подразделениях, нужно было проверить сам подход. Поэтому мы с командой решили начать с себя и разработали систему дашбордов… про дашборды. Иными словами, применили фреймворк Dashboard Map к собственному подразделению. Хотелось быть сапожником с сапогами — и иметь живой пример, который можно показать коллегам.

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

• Алерты и рассылки. Помогали отслеживать, всё ли работает как надо: не упало ли обновление данных, нет ли резких отклонений по метрикам, какие задачи есть перед командой. Это были первые сигналы, на которые нужно реагировать.
• Overview-отчёты. Давали общее представление о том, что происходит в BI-системе: как происходит сертификация отчётности, сколько пользователей, как долго загружается отчётность, какими системами пользуются.
• Страницы объектов управления. Позволяли исследовать отдельные направления, например, посмотреть аналитику по конкретной папке или дашборду, оценить активность пользователей, понять, сертификация каких дашбордов должна произойти следующей, и так далее.
• Self-service-отчёты. Помогали выгрузить нужные данные без написания кода — например, список активных пользователей за месяц или отчёты, по которым упала вовлечённость.
• Аналитические инструменты. Использовались для глубокой проработки, например, чтобы исследовать влияние обновлений, сравнивать сценарии использования, находить закономерности.
• Отчёт по экспериментам. Использовался в моменте, чтобы отследить эффект от изменений или протестировать новые решения.

Система отчётов группы развития BI

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

Когда система дашбордов «для себя» была готова, мы перешли к подразделениям. Работа шла проектами. Для каждого направления формировалась небольшая команда: аналитик подразделения и BI-аналитик из центральной команды. Вместе они разрабатывали Dashboard Map, а затем запускали как минимум два типа отчётов. Мы договорились о простом правиле: в каждом подразделении обязательно должны появиться два базовых отчёта — overview и self-service. Остальные типы добавлялись по мере необходимости. Такой подход упрощал старт, позволял быстрее дать бизнесу ощутимую пользу и одновременно задавал стандарт, по которому подразделения могли дальше развивать свою систему дашбордов.

Такая система позволила снизить количество ad-hoc-запросов к аналитикам. Вместо постоянных уточнений и пересчётов у бизнеса появился понятный инструмент, с которым можно работать самостоятельно.

Классификация отчётности по детализации и степени необходимости

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

Типы дашбордов и их взаимосвязи

Подробнее про этот проект я рассказывал на конференции «Матемаркетинг» — посмотрите, если этой главы вам оказалось мало.

Агентство интернет-маркетингаАгентство интернет-маркетинга

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

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

Чтобы справиться с задачей, мы разделили работу на три этапа:

1. Разработка Dashboard Map. На встрече разобрали роли и объекты управления в производственном и сервисном отделах и наметили систему дашбордов для этих подразделений. В результате получилась архитектурная схема и общее понимание того, как работают отделы.

   
   Dashboard Map для агентства интернет-маркетинга

2. Определение метрик и срезов в компании и её подразделениях. Сначала обсудили, как соотносятся цели по системе OKR и метрики, а затем перешли к брейншторму. Вместе с командой определили, какие метрики будут нужны для компании и её отделов.

   
   Метрики и срезы для агентства интернет-маркетинга

3. Заполнение Dashboard Canvas. Это фреймворк для заполнения дашборда, о котором вы узнаете в следующей главе.

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

• Dashboard Map
• Метрики и срезы
• Dashboard Canvas

По результатам проекта был разработан первый дашборд из системы — overview.

Overview-дашборд агентства интернет-маркетинга

Другие проектыДругие проекты

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

После внедрения новой системы навигация стала понятнее, а операционное управление — прозрачнее.

Разработка Dashboard Map для банка

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

Разработка Dashboard Map для поисковика авиабилетов

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

Такой формат отлично работает: за короткое время удаётся буквально «руками» пройтись по всем данным и дашбордам компании. Одновременно структурируется мышление команды и появляется общее понимание того, как должна выглядеть система.

Главное о системах дашбордовГлавное о системах дашбордов

Система дашбордов — это не набор случайных отчётов, а продуманная архитектура, связанная с ролями, объектами управления и точками контроля.

Чтобы система работала, важно соблюдать основные принципы:

• Начинать нужно с ролей и процессов, а не с графиков.
• Каждый дашборд должен отвечать за конкретную задачу: обзор, детализацию, контроль, сигнал о проблеме или глубокий анализ.
• Overview и self-service — базовые элементы для любого подразделения.
• Страницы объектов управления помогают держать под контролем конкретные зоны ответственности.
• Алерты нужны там, где важна скорость реакции.
• Аналитические инструменты применяются, когда решение требует работы с большим объёмом данных.
• Проектные дашборды могут быть временными: если направление становится постоянным, его метрики встраиваются в систему.

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

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