Кто отвечает за качество данных в компании, которая не является IT-компанией
Проблемы с качеством данных встречаются повсеместно. Ответственность за них - редкость. Разбор того, как назначить владельцев без создания бюрократического слоя, которым никто не пользуется.
На каком-то этапе большинство растущих компаний обнаруживают, что их данные в худшем состоянии, чем казалось. Отчёты дают разные цифры в зависимости от того, кто их запустил. CRM и бухгалтерская система расходятся по выручке. Количество клиентов различается по отделам. Проблема обычно не техническая. Она структурная: у данных нет владельца.
«IT-отдел» - это не владелец. «Все» - тоже не владелец. А «исправим при переходе на следующую систему» - именно так плохие данные переживают три смены платформ.
Что на самом деле означает владение качеством данных
Владение качеством данных - это не то же самое, что ответственность за базу данных. Это значит, что конкретный человек может ответить на следующие вопросы применительно к конкретному набору данных: какое значение правильное, откуда мы это знаем, когда последний раз проверяли, и кому звонить, когда что-то не так.
Большинство компаний не могут ответить ни на один из этих вопросов по своим базовым операционным данным. Вот в чём проблема.
Почему IT-отдел не может решить это в одиночку
Качество данных - это бизнес-проблема с технической поверхностью. IT-команда может выстроить правила валидации, отслеживание происхождения данных и оповещения об аномалиях. Но они не могут определить, что значит «корректный адрес клиента» для процесса продаж. Это определение живёт у людей, которые используют данные каждый день.
Когда IT полностью владеет качеством, происходит одно из двух. Либо они сами формулируют бизнес-правила, делая допущения, с которыми бизнес потом спорит. Либо они возвращают каждый вопрос по данным в бизнес, и ничего не решается, потому что никто на стороне бизнеса не чувствует себя ответственным.
Практическая модель владения
Модель, которую я видел работающей в компаниях среднего размера, проста. Для каждого критического домена данных - клиенты, продукты, транзакции, поставщики - есть конкретный человек со стороны бизнеса, который является «ответственным за домен». Он не пишет SQL. Он отвечает на вопросы о корректности, одобряет разрешение конфликтов и согласовывает определения.
Команда инжиниринга данных владеет технической инфраструктурой: пайплайнами, хранилищем, проверками качества, оповещениями. Когда проверка срабатывает, уведомление идёт ответственному за домен, а не в очередь IT.
Это не большое организационное изменение. По большей части вы делаете явным то, что и так должно быть правдой: директор по продажам знает о корректности данных о клиентах больше, чем администратор базы данных.
С чего начать
Выберите один набор данных, который создаёт наибольшую операционную боль. Тот, из-за которого возникает больше всего разговоров «эти цифры не совпадают». Определите, кто в бизнесе больше всего страдает от его качества. Дайте этому человеку чёткий мандат: его задача - быть ответственным за решение вопросов корректности, а не делать очистку данных самому.
Проведите так три месяца. Измерьте, сколько времени занимает разрешение спора о качестве данных до и после. Если время сократилось значительно - у вас есть рабочая модель. Тогда распространяйте её на следующий домен.
Цифра, которая говорит о наличии проблемы
Если ваши руководители тратят больше часа в неделю на совещания, которые начинаются с выверки данных перед тем, как перейти к реальному обсуждению, - у вас проблема с владением данными. Цена почти всегда выше, чем кажется, потому что выверка - невидимая работа: она выглядит как совещание, а не как проект по данным.