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

Я забрала этот процесс на себя, включая последующую загрузку планов в контейнер PostgreSQL. Настроила прямую выгрузку покрытия из DWH в Excel, а через Power Query собрала инструмент, удобный отделу COD для валидации планов. Итог: то, что раньше занимало день, теперь выполняется за 5 минут. Казалось бы, идеальная автоматизация. Но именно она вскрыла системную проблему.

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

Чтобы защитить сотрудников от несправедливых KPI, я вшила в свой инструмент фильтр, отсекающий пул точек с некорректным покрытием. Но точечное лечение не решает системную болезнь. Я написала SQL-запрос, который выявляет эти точки в DWH, и пошла к команде MDM. Предложила зашить подобную проверку в их Coverage Tool, чтобы некорректные данные просто не попадали в хранилище. Мой аргумент был прост: расчет нормативов — это лишь капля в море, данные из DWH используют десятки других бизнес-процессов, и ошибка стоит дорого на всех уровнях.

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

Ситуация классическая, но она поднимает несколько важных вопросов о зрелости данных и роли аналитики в компании. 1. Разрыв между офисом и полями. Офисным сотрудникам часто не понять специфику работы регионов. Перекладывание ответственности за качество данных исключительно на конечных пользователей в полях не работает. 2. Роль аналитики. Аналитика должна быть поддержкой бизнеса, а BI-отчеты — инструментом, который помогает принимать решения. Когда BI становится неповоротливым, непрозрачным и сложным, бизнес всегда найдет обходной путь. В нашем случае — ручной пересчет в Excel. 3. Качество данных как общая ответственность. Ошибка в мастер-данных ломает не один отчет, а всю экосистему процессов. Игнорирование проблемы на уровне MDM под предлогом отсутствия правильного инициатора — это путь в никуда.

Автоматизировать процесс — это только половина задачи. Вторая половина — убедиться, что мы автоматизируем работу с качественными данными.

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