Когда аналитика становится бюрократией: как data governance начинает мешать решениям

Есть момент в жизни любой data-зрелой компании, который никто не замечает в реальном времени.

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

И все вроде бы делают правильные вещи. Governance, каталог, процессы согласования. Data mesh. Все по учебнику. Только решения почему-то принимаются медленнее, чем два года назад, когда ничего этого не было.

Я для себя описываю это так: у data-организации есть треугольник Speed – Safety – Trust, где

Проблема начинается, когда governance оптимизируют только Safety и Trust, забывая про Speed. Тогда появляется Governance Debt – “процессный долг”: каждый новый шаг согласования кажется разумным, но суммарно он превращает данные в медленный сервис, от которого бизнес начинает отвыкать.

Я прошла через это в нескольких компаниях – и как аналитик, и как CPO. И хочу сказать то, о чем в целом не принято говорить: data governance может стать главным врагом data-driven культуры. Не плохие данные, и не отсутствие инструментов, а сами процессы, построенные чтобы данными управлять.

Все начинается с хорошей идеи.

Данные в компании разрозненные, определения метрик расходятся между командами, один и тот же показатель считается по-разному в финансах и в продукте. Это реальная боль. И кто-то, обычно новый CDO или сильный data-лид, говорит: “нам нужен порядок в данных и процессах. Нужен единый каталог, data lineage, процесс согласования изменений в схемах, владельцы данных.”

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

Сначала появляется форма для регистрации нового источника данных. Потом – committee, который эту форму рассматривает. Далее – SLA на рассмотрение (две недели, потому что люди заняты). Шаблон для запроса доступа, аудит существующих доступов, по результатам которого половина команды теряет доступ к тому, с чем работала последние полгода. И напоследок. процесс восстановления доступа (та же форма, тот же committee, те же две недели).

Микро-кейс (финтех). В одном финтех-контуре доступ к витрине, которую команда уже использовала, перевыдали через новый процесс: тикет – владелец данных – ИБ – комитет. В итоге вопрос, который раньше закрывали за полдня, стал занимать несколько рабочих дней, и бизнес начал держать параллельные Excel-выгрузки “на всякий случай”. Формально governance улучшился, фактически появился Governance Debt.

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

Если бизнес задает вопрос – «а сколько клиентов сделали X за последние 30 дней», и ответ приходит через полторы недели, это не проблема данных. Это проблема процессов вокруг данных. Хорошие данные, заблокированные плохим governance, работают хуже плохих данных с быстрым доступом.

Я видела команды, где на каждый реализованный запрос приходилось три-четыре артефакта: тикет, описание в каталоге, подтверждение владельца данных, запись в changelog. Это не аналитическая работа. Это делопроизводство. Если ваши лучшие аналитики превращаются в data stewards поневоле – вы платите аналитикам за работу, которую можно автоматизировать или упростить.

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

“У нас 94% источников задокументированы в каталоге” – звучит хорошо. Но если никто этим каталогом не пользуется при принятии решений, это просто красивое число. Я видела отчеты data governance команд, где KPI были полностью оторваны от бизнес-результата: покрытие каталога, процент задокументированных пайплайнов, количество прошедших data literacy training. Ни одного показателя о том, стали ли решения лучше или быстрее.

Это самый честный сигнал. Когда менеджеры начинают вести свои Excel-таблицы, потому что через data team долго, когда аналитические запросы уходят напрямую в engineering в обход всех процессов, когда люди договариваются в личке вместо того чтобы создавать тикет – это не нарушение регламента, а отрицание системы, которая перестала служить своей цели.

Микро-кейс (ритейл). Когда доступ к данным о продажах и промо стал открываться “по регламенту” неделями, категорийные менеджеры сделали теневой слой: ежедневные выгрузки и свои “источники правды”. Через месяц компания получила две системы: официальную (правильную) и рабочую (быструю). Это не саботаж – это реакция на потерю Speed.

Есть разница между командой, которая помогает организации работать с данными, и командой, которая контролирует доступ к данным как к ресурсу власти. Второй тип появляется незаметно. Признаки: governance блокирует проекты без объяснения альтернатив, решения принимаются исходя из соответствия процессу, а не из бизнес-контекста, на любой вопрос есть ответ “это не по процессу”.

Если онбординг нового аналитика неформально включает инструкцию “вот официальный процесс, а вот как это делается на самом деле” – у вас есть официальная система и теневая система, которая реально работает. Это значит, что официальная – нет.

Потому что governance – это то, что принято хвалить и к чему стремиться.

“У нас сильный data governance” – это строчка в LinkedIn, в презентациях для совета директоров, в ответах на вопросы о data maturity. Сказать вслух, о том что governance стал замедлять решения, – это значит поставить под сомнение решения, которые принимались публично и с большими инвестициями.

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

Последствия плохого governance видны быстро (инциденты с данными, расхождения в отчетах, утечки). Последствия избыточного governance (о том, что решение приняли медленно) размазаны во времени и плохо атрибутируются.

Если вы не можете ответить за день на вопрос бизнеса – governance у вас не про доверие, а про контроль.

Я не против governance. Я против governance как самоцели. Разница в том, от чего вы отталкиваетесь при проектировании процессов.

Начинать с решения, а не с процесса. Каждый governance-процесс должен отвечать на вопрос: какое конкретное решение становится лучше благодаря этому процессу? Если ответа нет – процесс под вопросом.

Измерять то, что важно бизнесу. Не покрытие каталога, а время от вопроса до ответа. Не процент задокументированных источников, а доля решений, принятых на основе данных. Если ваш governance не делает решения быстрее и качественнее – он не работает, даже если все метрики зеленые.

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

Раз в полгода задавать неудобный вопрос. Буквально: собрать людей и спросить – какие data-процессы мешают вам делать работу быстро?

Нанимать людей в data governance с сервисным, а не контрольным мышлением. Это вопрос культуры найма. Человек, который думает “как я могу помочь команде работать с данными быстро и безопасно” и человек, который думает “как убедиться, что все следуют идеальному процессу” – это два разных подхода с разными последствиями для организации.

Зрелость в работе с данными – это способность принимать хорошие решения быстро, опираясь на данные, которым доверяешь. Governance существует чтобы это обеспечить. Не чтобы это заменить.

Если у вас в компании сильный governance и медленные решения – что-то пошло не так.