Данные как продукт: почему ответственность за данные нельзя вешать на одну команду
Когда аналитика перестаёт работать, проблема часто не в инструментах. Разбираю, как распределять ответственность за данные между командами.
Стандартная ситуация: в компании есть аналитический отдел или дата-команда, на которую повешена ответственность за "все данные". Они строят пайплайны, отвечают на вопросы, готовят отчёты. При этом реальные данные живут в системах, которыми владеют другие команды: CRM, ERP, операционные системы. Дата-команда берёт данные оттуда, но решить проблему качества не может - эти системы не в её власти.
Это противоречие накапливается медленно, но в определённый момент выходит на поверхность. Аналитические отчёты расходятся между собой. Никто не понимает, чьи цифры правильные. Дата-команда тушит пожары, а не строит инфраструктуру.
Откуда берётся проблема
Исторически данные воспринимались как побочный продукт систем. CRM записывает данные, потому что так устроена CRM. ERP хранит транзакции, потому что без этого не работает учёт. Никто специально не думал о данных как о чём-то, за что нужно нести ответственность отдельно от системы.
Когда данных мало, это работает. Когда их становится много и они нужны для решений - проблемы начинаются. Ни у одной команды нет полноты картины. Ни у одной команды нет мандата и ресурсов, чтобы это исправить.
В 2019 году в технологическом сообществе активно обсуждается концепция, которую называют data mesh - подход к организации работы с данными, при котором ответственность за данные распределяется по командам-владельцам доменов. Идея не новая, но её оформление и систематизация сейчас делают её более применимой.
Что значит "данные как продукт"
Если команда, которая владеет доменом - например, команда заказов - несёт ответственность не только за функциональность своей системы, но и за качество и доступность данных, которые она производит, это меняет характер работы.
Данные из этого домена начинают рассматриваться как продукт, у которого есть потребители (другие команды, аналитика, ML). Этот продукт нужно описать - какие данные, с какой частотой обновляются, что означает каждое поле. Нужно гарантировать его качество - что данные полные, корректные, не теряются при изменении системы. Нужно поддерживать - реагировать на проблемы, которые обнаруживают потребители.
Это требует от командных лидов другого мышления. Нельзя просто сказать "мы сделали фичу, данные будут какие будут".
Почему это не решается инструментами
Можно купить или построить дата-каталог, настроить мониторинг качества, внедрить data lineage. Всё это полезно. Но ни один из этих инструментов не заработает, если у данных нет владельца, который заинтересован в их качестве.
Инструменты делают видимой проблему - кто отвечает за конкретный датасет, где нарушена свежесть, какое поле не описано. Но реагировать на эту видимость должен человек или команда с мандатом и мотивацией.
Именно поэтому работа по качеству данных - это в первую очередь организационная задача. Технология - вторична.
С чего начать
Если вы видите описанную ситуацию в своей компании, несколько шагов, которые дают результат быстрее, чем покупка нового инструмента:
- Составьте список ключевых наборов данных, на которых держится операционная и аналитическая работа.
- Для каждого набора данных задайте вопрос: кто сейчас де-факто отвечает за их качество? Если ответа нет - это и есть точка риска.
- Договоритесь, что команды-владельцы систем несут ответственность за описание и базовое качество данных, которые они производят.
- Сделайте этот мандат частью ожиданий от командных лидов, а не дополнительной нагрузкой на дата-команду.
Это не быстрый процесс. Но именно он меняет ситуацию системно, а не временно.