В BI-проектах есть момент, который на бумаге выглядит как финал работы, а на практике часто оказывается только началом более сложной части.
Отчёт готов, данные обновляются, показатели считаются, доступы выданы, на демонстрации заказчик в целом согласен с логикой и просит разве что добавить несколько разрезов или поправить формулировки. С точки зрения проекта всё выглядит неплохо: есть артефакт, есть согласование, есть ощущение, что теперь у бизнеса появился нормальный инструмент для работы с данными.
Потом проходит месяц, иногда два, и выясняется, что компания по-прежнему принимает решения примерно так же, как и раньше. Руководители снова уточняют цифры в чате, менеджеры продолжают выгружать Excel “для себя”, финансовая команда сверяется со своими файлами, коммерческий блок опирается на свои расчёты, а дашборд открывают перед встречей или в тот момент, когда нужно быстро найти подтверждение уже сложившейся версии.
Формально BI появился. Но способ управления почти не изменился.
Я не пишу это как претензию к бизнесу или к конкретным BI-инструментам. Обычно причина не в одном неудачном решении, а в том, что техническая часть проекта и управленческая часть проекта существуют отдельно друг от друга. DataLens, Power BI, Tableau, Metabase или самописный фронт могут быть вообще ни при чём. Отчёт может быть быстрым, аккуратным и полезным для просмотра, но при этом так и не стать частью процесса, в котором принимаются решения.
Кажется, проблема часто появляется раньше, чем аналитик открывает редактор дашборда.
Запрос на отчёт обычно звучит просто, потому что бизнес описывает проблему через понятный ему артефакт: “сделайте дашборд по продажам”, “нужна аналитика маркетинга”, “хотим видеть склад”, “надо P&L по направлениям”. Это нормальная точка входа в задачу, но за одной и той же формулировкой могут стоять совершенно разные управленческие вопросы.
Дашборд по продажам для собственника может быть способом понять, почему деньги не сходятся с ожиданиями. Для коммерческого директора это инструмент еженедельного контроля воронки. Для руководителя отдела продаж это список людей и сделок, с которыми нужно разбираться сегодня. Для маркетинга это проверка, какие каналы дают не лиды вообще, а нормальную выручку.
Если этот разговор не состоялся, легко собрать “главный экран продаж”: выручка, сделки, средний чек, конверсия, план-факт, менеджеры, источники. Такой экран может выглядеть убедительно, но после сдачи возникает неприятный вопрос: кто именно должен на него смотреть, в какой момент и что должно измениться в действиях команды, если какой-то показатель ушёл не туда.
Просмотры дашборда тоже не спасают
Раньше я относился к использованию отчёта проще: если его регулярно открывают, значит он как минимум попал в рабочее поле пользователей; если не открывают, значит где-то промахнулись.
Сейчас мне кажется, что это слишком слабая проверка.
Если дашборд никто не открывает, да, это плохой сигнал. Возможно, отчёт неудобный, медленный, отвечает не на те вопросы или проигрывает старому Excel, который все ругают, но продолжают использовать. Тут хотя бы понятно, куда копать.
Но если дашборд открывают, радоваться рано. Человек может посмотреть на график, закрыть вкладку и дальше принять решение так, как принимал его всегда: по опыту, по последнему сообщению в чате, по устной договорённости или просто под влиянием самого уверенного человека на встрече.
В логах будет активность. Внутри проекта можно будет сказать, что пользователи работают с аналитикой. Но управленчески могло не произойти почти ничего.
Мне кажется, BI часто путает включение интерфейса с включением аналитики в работу компании. Первое сделать сильно проще. Второе требует договориться о том, где именно отчёт участвует в управлении.
Например, если дашборд по продажам открывают раз в неделю на коммерческой встрече, но после просмотра никто не фиксирует отклонения, не выбирает действия и не возвращается к ним через неделю, то это скорее иллюстрация к разговору, чем инструмент управления. Уже неплохо, но ещё не то, ради чего обычно строят аналитику.
Какой вопрос стоит задать до сборки отчёта
Я бы всё чаще начинал не с вопроса “какой дашборд вам нужен?”, а с более неприятного: “какое решение вы хотите начать принимать лучше?”
Не красивее презентовать. Не быстрее смотреть цифры. Именно принимать лучше.
Кто принимает это решение? Как часто? Что он сейчас смотрит перед этим? Кому не доверяет? Где начинается спор? Что считается нормой, а что отклонением? Что человек должен сделать, если увидел проблему? На какой встрече это будет обсуждаться? Кто вернётся к этому через неделю?
Эти вопросы могут выглядеть занудно, особенно если заказчик пришёл “просто за отчётом”. Но без них дашборд легко превращается в витрину показателей: всё важное собрано, всё красиво разложено, но судьба отчёта после сдачи туманная.
Иногда в этот момент выясняется, что дашборд нужен не один. Собственнику нужен короткий экран по деньгам и отклонениям. Руководителю направления нужен рабочий инструмент для контроля процесса. Аналитику нужна детализация, где можно докопаться до причины. Попытка уместить всё это в один универсальный экран обычно заканчивается компромиссом, который всем немного подходит и никому по-настоящему не помогает.
При чём тут North Star
В продуктовых командах есть понятие North Star-метрики. Если коротко, это показатель, который помогает понять, растёт ли основная польза продукта для пользователя. Не просто растут ли регистрации, не просто идёт ли активность вокруг продукта, а появляется ли то действие, ради которого продукт вообще существует.
У Spotify таким ориентиром могут быть прослушивания. У Zoom проведённые встречи. У маркетплейса успешные сделки. Примеры грубые, но идея понятная: хочется отличить настоящую ценность от шума вокруг неё.
В BI-проектах похожий вопрос тоже нужен.
Что считать успехом? Сдали отчёт? Подключили пять источников? Сделали витрины? Ускорили обновление? Получили сто просмотров за месяц?
Всё это может быть важно. Но ни один из этих показателей сам по себе не отвечает на главный вопрос: стал ли бизнес хоть немного иначе управляться после появления аналитики.
Для себя я всё чаще формулирую North Star BI-проекта так: аналитика должна перейти из набора отчётов в рабочий инструмент управления.
Да, звучит менее технически, чем “построили хранилище, витрины и слой визуализации”. Зато ближе к тому, ради чего это всё обычно покупают.
Если руководитель раньше замечал проблему через месяц, а теперь видит её на еженедельной встрече, это уже изменение. Если команда перестала спорить, чей Excel правильнее, и начала обсуждать причины отклонения, это тоже изменение. Если собственник больше не собирает картину бизнеса вручную из пяти людей и семи файлов, значит аналитика начала делать свою работу.
Не обязательно сразу строить “data-driven culture”. Это выражение вообще лучше использовать осторожно, потому что за ним часто прячется пустота. Иногда нормальный результат гораздо проще: компания впервые получила общую картину, которой можно доверять.
Шкала зрелости аналитики
Мне удобно думать об аналитике как о шкале, а не как о галочке “BI внедрён”.
На первом уровне всё держится в голове собственника, в Excel, в переписках и ручных выгрузках. Это может работать, пока бизнес небольшой или пока один человек правда способен удерживать основные связи.
Потом отчёты появляются, но используются нерегулярно. Их вспоминают перед встречей, перед проблемой или когда нужно срочно объяснить, почему что-то пошло не так.
Дальше отдельные отделы начинают работать с цифрами. Маркетинг видит своё, продажи своё, финансы своё, операционный блок своё. Это уже лучше хаоса, но спор часто просто переезжает на другой уровень: цифры есть у всех, только реальность у каждого своя.
Следующий уровень начинается, когда аналитика становится частью регулярного управления. Её открывают не “когда вспомнили”, а потому что есть встреча, процесс, ответственность и понятные действия после просмотра.
Самый сильный вариант, когда без аналитики уже странно принимать решение. Не потому что так написано в стратегии, а потому что иначе компания слишком быстро теряет связь с тем, что происходит на самом деле.
Эта шкала грубая, но полезная. Она возвращает разговор с уровня “сделали ли мы дашборд” на уровень “куда сдвинулось управление”. Иногда хороший проект переводит компанию с первого уровня на второй. Иногда с третьего на четвёртый. Иногда вообще не требует новых графиков, а требует встроить уже существующие отчёты в нормальный ритм обсуждений.
Вместо вывода
Дашборд не обязан быть большим событием в жизни компании. Иногда это просто удобный отчёт, который заменил ручную выгрузку, и этого достаточно. Не каждый проект должен менять стиль управления.
Но если от BI ждут большего, если хочется, чтобы компания действительно начала лучше видеть себя через данные, то одного факта внедрения мало. Нужно понимать, какое решение обслуживает отчёт, кто его принимает, когда смотрит на цифры и что делает после этого.
Иначе получится знакомая история: данные есть, графики есть, доступы есть, а управление осталось там же, где было. Просто рядом появилась ещё одна ссылка.
Иногда пишу о BI, данных и управлении в телеграм-канале: https://t.me/smart3asy
ссылка на оригинал статьи https://habr.com/ru/articles/1045540/