Проект бизнес-аналитики часто ломается не на графиках, а раньше: в целях, данных и ожиданиях. До договора надо понять, какие решения система даст бизнесу, откуда возьмёт цифры и кто примет результат. Иначе красивый дашборд быстро превращается в дорогую витрину сомнений.
С какой цели начинать проект бизнес-аналитики
Цель проекта бизнес-аналитики (BI) — не набор отчётов, а управленческое решение, которое станет быстрее, точнее или дешевле. До старта фиксируют вопросы бизнеса, метрики и людей, которые будут этими данными пользоваться.
В недвижимости это видно особенно жёстко. Руководитель продаж хочет видеть путь клиента от объявления до сделки. Маркетологу нужны заявки по каналам, а финансисту — выручка по жилому комплексу (ЖК), срокам оплаты и остаткам. Если всё это сложить в один экран без отбора, получится пёстрая стена чисел. Смотреть на неё будут на совещании, а решать всё равно по старым таблицам.
Начинать полезно с короткого разговора о боли. Где теряются деньги? На рекламе, просроченных сделках, нестыковках между отделом продаж и бухгалтерией? После этого появляются нормальные формулировки: «видеть стоимость заявки по каждому каналу», «сравнивать план и факт по объектам», «находить менеджеров с длинным циклом сделки». Такие задачи уже можно считать, проектировать и принимать.
- какое решение человек примет после просмотра отчёта;
- какая метрика покажет изменение ситуации;
- как часто нужны данные: каждый час, раз в день или к планёрке;
- кто владелец показателя и кто отвечает за источник данных.
Кстати, спор о показателях до разработки экономит недели. «Продажи» для отдела рекламы, коммерческого директора и бухгалтерии часто означают три разные сущности. Один считает брони, второй — договоры, третий — поступившие деньги. Пока словарь не собран, бизнес-аналитика будет спорить сама с собой.
Какие данные надо разобрать до договора
До договора надо понять, где лежат данные, кто даёт к ним доступ, как часто они обновляются и насколько им верят сотрудники. Без этого подрядчик оценивает не проект, а туман.
На практике источники почти всегда разъезжаются. Лиды хранятся в системе управления взаимоотношениями с клиентами (CRM), расходы на рекламу — в кабинетах площадок, сделки — в учётной системе, планы — в файле у коммерческого директора. Ещё есть коллтрекинг, шахматка квартир, ручные корректировки и выгрузки, которые кто-то по пятницам отправляет в чат. Картина неприятная, зато честная.
Перед заказом нужно запросить у будущего подрядчика не демонстрацию «красивых экранов», а разговор о данных. Какие поля нужны? Есть ли уникальный номер клиента, сделки, объекта? Совпадают ли даты в разных системах? Что делать с дублями и возвратами? На этих вопросах быстро видно, умеет ли команда работать с реальным хозяйством компании.
| Зона проверки | Что выяснить | Тревожный сигнал |
|---|---|---|
| Источники | Системы, файлы, кабинеты, ответственные за доступ | «Потом подключим всё сразу» |
| Качество данных | Дубли, пустые поля, разные названия объектов | Проверку откладывают до финала |
| Обновление | Частота загрузки и допустимая задержка | Всем обещают данные «в реальном времени» |
| Права доступа | Роли, ограничения, персональные данные | Один доступ для всей компании |
Отдельный разговор — исторические данные. Для прогноза продаж по объектам нужны старые сделки, рекламные расходы и статусы клиентов. Если история велась кусками, модель не спасёт ситуацию. Тогда проект начинают с витрины фактов: что уже можно считать, где есть провалы, какие показатели появятся после наведения порядка в источниках.
Как оценить подрядчика и состав работ
Хороший подрядчик до сметы спрашивает о решениях, данных, пользователях и приёмке. Если разговор сразу уходит в лицензии, палитры графиков и срок «две недели», риски проекта уже выросли.
У команды должен быть понятный маршрут: обследование, прототип, подключение источников, модель данных, отчёты, обучение пользователей, поддержка. Не как церемония ради документа, а как рабочая карта. Заказчику надо видеть, где заканчивается аналитика и начинается разработка, кто согласует справочники, кто отвечает за доступы, кто принимает формулы.
Полезный признак — подрядчик спорит с формулировками. Не из вредности. Когда просят «дашборд по продажам», он уточняет, какие продажи, за какой период, по какой дате и с какими отменами. Такой спор иногда утомляет, особенно вечером после третьего совещания, но именно в нём рождается система, которой будут пользоваться.
- Попросите описать первый рабочий сценарий на одном бизнес-вопросе.
- Уточните, кто со стороны заказчика нужен каждую неделю.
- Проверьте, входит ли описание метрик в состав работ.
- Зафиксируйте формат обучения и срок поддержки после запуска.
Смету тоже надо читать не по итоговой сумме. В ней должны быть видны источники, отчёты, роли, загрузки, тестирование и доработки после первых пользователей. Если весь проект назван одной строкой, сравнить предложения подрядчиков почти невозможно. Дешёвый вариант часто прячет работу, которая всплывёт отдельным счётом.
Как принять первый результат без разочарования
Первый результат принимают не по красоте графиков, а по совпадению цифр, скорости ответа и пригодности отчёта для решения. Пилот должен закрывать один законченный сценарий, а не изображать всю будущую систему.
Для пилота подойдёт, например, отчёт по воронке продаж: источник заявки, менеджер, статус, бронь, договор, оплата. В нём сразу проявятся слабые места. Где-то не совпадут статусы, где-то клиент раздвоится, где-то рекламный канал потеряется после звонка. Это не провал, а нормальная диагностика перед большим запуском.
Критерии приёмки лучше записать до разработки. Цифры в отчёте сверяются с эталонной выгрузкой, права доступа проверяются на разных ролях, пользователь проходит свой сценарий без помощи аналитика. Если коммерческий директор не может за минуту найти просадку по объекту, экран надо менять, даже если диаграмма выглядит эффектно.
- сходимость показателей с выбранным источником;
- понятные названия метрик и фильтров;
- загрузка данных в оговорённый срок;
- разные права для руководителя, менеджера и аналитика;
- список доработок после теста на реальных пользователях.
Ещё один момент часто забывают: кто будет жить с системой после релиза. Нужен владелец внутри компании, не номинальный, а с правом менять справочники, собирать вопросы и отсекать лишние пожелания. Без такого человека отчёты начинают обрастать случайными вкладками, и через полгода никто не помнит, зачем появилась половина экранов.
Итог
Проект бизнес-аналитики надо оценивать до старта по четырём вещам: решение, данные, подрядчик и приёмка. Если хотя бы одна часть расплывается, риск переносится в разработку, а там он уже стоит дороже. Цель должна быть связана с действием, данные — с владельцами, смета — с понятным составом работ.
Сильный старт выглядит не шумно: несколько точных вопросов, честная карта источников, пилот на одном сценарии и зафиксированные правила приёмки. После этого бизнес-аналитика перестаёт быть набором экранов и начинает работать как рабочий инструмент для продаж, финансов и управления объектами.