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

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

Аналитика может и не перестала работать по факту, но со временем система накапливает столько источников, доработок и негласных договоренностей, что бизнес перестает понимать, что происходит внутри нее. И возникает логичный вопрос о том, можно ли такой системе доверять? 

Это одна из самых частых ситуаций, с которыми мы сталкиваемся, когда приходим в крупную компанию с BI-аудитом. И почти всегда видим результат нескольких лет наслоений: разные отделы годами донастраивали отчеты под себя, кто-то менял логику расчета метрики и не сообщал об этом остальным, часть источников данных подключили временно и забыли зафиксировать, как именно.

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

Как система, которая работала, перестает быть понятной

Ни одна компания не строит неопределенность и неточности внутри своих систем специально. Мы просто выстраиваем аналитическую систему, подключаем первые источники, аналитики закрывают конкретные задачи. Система работает, и все довольны.

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

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

Как понять, что аналитике пора на диагностику

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

• никто не может быстро и уверенно объяснить, как считаются ключевые метрики или набор метрик;

• нет актуальной схемы того, откуда и куда движутся данные;

• разные отчеты по одному и тому же вопросу дают разные цифры;

• добавление новой метрики или отчета превращается в отдельный проект на недели;

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

• бизнес регулярно просит ручные выгрузки, потому что стандартный автоматический отчет не отвечает на интересующий вопрос;

• маркетинг не видит полную картину эффекта от рекламных активностей;

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

• вся система держится на одном человеке;

• нет понятных договоренностей о том, кто отвечает за данные, в какие сроки чинятся проблемы и кто вообще владелец каждого отчета.

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

Как техническая неприятность может стать опасной для бизнеса

Да, многие живут с  немного путанной аналитикой годами. Минорные несостыковки действительно можно претерпеть, особенно если финансовых убытков пока никто не замечает. Однако помним, что несостыковки имеют свойство накапливаться, и момент, когда их количество станет критическим, неизбежно отразится на эффективности бизнеса.

Руководители начнут принимать решения с задержкой. Раз нужно ждать, пока цифры сойдутся между собой, рассуждения на их основе потребуют более длительного времени. Команды начнут тратить рабочее время не на полезное действие, а на сверку отчетов друг с другом. ИТ-отдел будет избегать изменений в системе, потому что никто не знает, какие зависимости может задеть на первый взгляд безобидная правка. Бизнес потеряет скорость проверки гипотез, потому что тесты, которые должны занимать (и прежде занимали) дни, растягиваются на недели согласований и перепроверок.

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

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

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

Система, которую уже невозможно нормально передать на поддержку

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

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

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

Проблема была в отсутствии документации при относительно небольшом объеме данных. Но бывает и обратная ситуация. Когда данных настолько много, что дело не в нехватке описания, а в том, что систему в принципе невозможно удержать в голове целиком.

Когда данных слишком много, чтобы держать их в голове

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

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

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

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

Зачем нужен BI-аудит

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

Хорошо проведенный аудит дает ответы на вопросы, которые до момента его проведения оставались открытыми:

• какие отчеты бизнес реально использует, а какие существуют сами по себе;

• какие данные приносят пользу, а какие просто занимают место и стоят денег;

• в каких точках возникают расхождения и ошибки;

• какие метрики считаются непрозрачно и требуют отдельного разбора;

• где в процессах остался ручной труд и разовые обходные решения;

• какие части системы обходятся дороже всего в поддержке;

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

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

Не всегда нужно ломать все и строить заново

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

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

iiii Tech проводит BI-аудит: разбирает текущие отчеты, источники данных, архитектуру и процессы работы с аналитикой, чтобы показать, где бизнес теряет прозрачность, скорость и управляемость, и какие изменения стоит делать в первую очередь.