BI-инвентаризация: как разобрать архивы отчетов и не сломать бизнес-процессы

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

По данным исследования Atlan, в компаниях с более чем 500 дашбордами 30–40% отчётов пересекаются по содержанию. При этом 43% пользователей просто перестают открывать корпоративные отчёты и уходят в свои таблицы, потому что не могут найти нужное или не доверяют тому, что видят. Поэтому проблема для рынка не нова и затрагивает даже больше компаний, чем нам может казаться.

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

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

Дальше расскажем, как это делать на практике.

С чего начать и чего делать не стоит

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

Инвентаризация работает только как командная история. Минимальный состав выглядит так:

Data Engineer или BI Developer — тот, кто выгружает логи активности из системы, смотрит, кто и когда последний раз открывал каждый отчёт, откуда берутся данные, насколько тяжёлые запросы. Без этого человека вся работа превращается в догадки и предположения.

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

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

Практика показывает: именно стык между техническими специалистами и бизнесом — самое сложное место. Инженер видит, что отчёт не открывали восемь месяцев. Бизнес говорит: «Мы открываем не чаще чем раз в 8 месяцев». Короче говоря, в вопросах инвентаризации данных нельзя ограничиться только одним из контекстов: нужна синергия разных юнитов.

Шаг 1: Технический аудит

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

Что смотрим на этом этапе:

• Список всех объектов: отчёты, дашборды, датасеты, витрины. Часто уже на этом шаге обнаруживается, что никто в компании не знал реального их числа. Бывает, называют «около ста», а по факту — четыреста с лишним.

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

• Логи активности: кто открывал отчёт, как часто, когда последний раз. Отчёты, которые не открывались больше 90 дней, сразу уходят в отдельный список: это первые кандидаты на проверку (и зачастую удаление).

• Нагрузка на инфраструктуру: какие отчеты генерируют тяжёлые запросы, сколько времени занимает их сборка, есть ли мёртвые ETL-процессы, которые продолжают грузить данные в никуда.

Пару слов о последнем пункте. ETL-процессы, которые работают фоново и ни на что не влияют, встречаются практически в каждом проекте. Они поглощают ресурсы, но никак себя не проявляют, а поэтому и обнаруживаются только когда кто-то целенаправленно смотрит на инфраструктуру. И чем крупнее система, тем острее эта проблема.

Один из наших клиентов — международная производственная компания — обратился с задачей, которая на старте звучала как «помогите наладить мониторинг». Когда начали технический аудит, выяснилось, что DWH получает данные более чем из 30 источников, при этом система была business critical: сбой в ней напрямую влиял на операционные решения. Никакого систематического контроля за состоянием потоков не было — DAG-и в Airflow периодически останавливались из-за недоступности источников, инженеры узнавали об инцидентах постфактум, поддержка регулярно не укладывалась в SLA. Инфраструктура выросла до масштаба, при котором ручной контроль физически перестал справляться. 

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

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

Шаг 2: Интервью с владельцами и бизнес-контекст

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

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

Когда владелец найден, разговор строится вокруг трех вопросов:

• Какое решение принимается на основе этого отчета? Нужно выяснить, что руководитель делает иначе, посмотрев на эти цифры. Если внятного ответа нет, логично поставить отчет в очередь на ревизию.

• Что произойдет, если этот отчёт исчезнет завтра? Если сотрудники компании в состоянии назвать конкретный процесс, который завязан на эти данные, можно оценить, насколько отчёт критичен на самом деле.

• Насколько вы доверяете этим данным? Может выясниться, что отчетом пользуются, но цифрам не верят. Бывает, так происходит, потому что альтернативы нет, бывает потому что «так исторически сложилось». И здесь мы  думаем в первую очередь не об удалении, а о необходимости пересмотра логики.

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

Шаг 3. Расставляем приоритеты

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

Получаем четыре группы:

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

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

Низкая ценность, высокая сложность — самая неприятная группа. Тяжелые в поддержке отчеты, которые при этом почти никто не использует. Кандидаты на рефакторинг или удаление. Именно они чаще всего съедают непропорционально много ресурсов инфраструктуры.

Низкая ценность, низкая сложность — с ними все просто: архивируем на 30 дней, если никто не запросил — удаляем.

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

И цена ошибки здесь может быть очень высокой. В нашей практике был кейс с крупным fashion-ритейлером: в какой-то момент в данные закралась ошибка, которая привела к некорректному расчету LTV. Это не сразу бросалось в глаза: цифры выглядели правдоподобно, отчёт регулярно открывался, никаких явных сигналов не было. На основе этих данных планировались маркетинговые бюджеты, и планировались они, конечно, неверно из-за ошибки. К тому моменту, когда ошибку обнаружили, она уже обошлась компании в десятки миллионов рублей ежемесячных потерь. Отчет по LTV в этом бизнесе относился к первой категории матрицы — высокая ценность, высокая сложность — и как раз здесь нам нужен выстроенный контроль качества данных. После внедрения системы мониторинга DQ корректность ключевых бизнес-метрик стала предсказуемой.

Шаг 4. Проверяем, насколько данным можно доверять

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

Есть два уровня, которые нужно проверить.

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

Качество самих данных. Это отдельная и более глубокая история. Данные могут приходить с задержкой, дублироваться, содержать пустые поля в критичных местах, противоречить друг другу в разных источниках. По оценкам Gartner, плохое качество данных обходится компаниям в среднем не менее $12,9 млн в год. Gartner — это данные из их собственного исследования, основанного на опросе крупных enterprise-компаний. Но реальный ущерб часто не в прямых потерях, а в том, что проблема долго остаётся невидимой: данные выглядят нормально, отчеты открываются, цифры на первый взгляд правдоподобны. Решения принимаются. А потом выясняется, что фундамент был недостоверным.

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

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

Шаг 5. Фиксируем результаты, чтобы не вернуться к тому, с чего начали

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

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

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

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

Периодический пересмотр. Раз в квартал или полгода стоит пробежаться по логам активности и проверить, не появились ли новые неиспользуемые объекты. Это базовая гигиена, которая занимает несколько часов, но предотвращает накопление нового балласта.

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

Если вы узнали себя в этой статье

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

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

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