Контроль качества данных

Тип «пусто» или «дырявая» отчетность

Представим, что сотрудник компании, которая занимается производством консервированных овощей и фруктов, заводя в учетной системе новый продукт – консервированный персик – забыл указать, что этот продукт относится к фруктовым консервам, то есть не заполнил поле «Тип продукта». Тогда в простейшем отчете «продажи продуктов по типам» вместо двух строк — овощные и фруктовые консервы — появится 3 строки, причем третья будет пустой. Если же мы «углубимся» в эту пустую строку, то есть осуществим т.н. операцию drill down, то увидим, что это и есть наш персик.

Это дает нам возможность отслеживать простейшие ошибки операторов учетной системы путем построения отчетов по ключевым аналитикам. Как только в отчете появляется «дырка», можно сделать вывод, что аналитика не заполнена, найти, у какого продукта или клиента ее забыли проставить, и обратить на это внимание оператора. Возникает вопрос о том, за какой период строить подобные отчеты.

Например, мы построили отчет по регионам за текущий год и обнаружили, что 10 единиц продукции проданы в торговую точку типа «пусто». Далее мы увидели, что это произошло потому, что двум адресам поставки забыли проставить аналитику «тип торговой точки». Мы обратились к операторам учетной системы и попросили их внести данную аналитику, что они и сделали. При обновлении отчета продаж в торговую точку типа «пусто» больше нет. Но это касается только текущего года. Построим такой же отчет за прошлый год. Теперь продаж в точки типа «пусто» уже 100 единиц. И это неудивительно, ведь в прошлом году никто не следил за данной аналитикой, а может быть, ее вообще не было в учетной системе. Но теперь исправить ситуацию сложнее. Большая часть торговых точек, у которых нет этой аналитики, уже не работает с компанией (ведь если бы они работали, мы бы увидели их и в отчете за текущий год). И поскольку среди торгового персонала текучка достаточно велика, многие из тех, кто обслуживал эти магазины в прошлом году, уже не работают в компании. Таким образом, никто не знает, к какому типу принадлежат наши проблемные точки.

Неверные данные: ручная проверка

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

Рассмотрим теперь более сложные проблемы. Предположим, что у нас есть подозрение, что какая-то аналитика заполнена неверно. Мы можем попробовать найти «параллельную» аналитику и сравнить их между собой. Например, возьмем аналитику «торговый представитель» и сравним с аналитикой «канал», построив отчет, в боковик которого выведем канал и затем торгового представителя.

Аналитика и текучесть кадров

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

Роль заказчика

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

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

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

Например, представим себе такую ситуацию. Руководитель службы продаж пришел к аналитикам и попросил отчет по MML. При этом он даже готов продумать, какие именно продукты должны продаваться в каких магазинах и предоставить это в нужном виде для загрузки в хранилище данных. Аналитик сделал отчет, руководствуясь алгоритмом, описанным в предыдущих номерах журнала «Мобильная Торговля». Затем он показал отчет заказчику, и стало понятно, что значение показателя «Процент выполнения MML» получилось слишком маленьким. И только теперь заказчик начинает вникать в методику расчета и думать, как ее изменить, с тем чтобы увеличить значение показателя. Чтобы такого не происходило, нужно четко описывать алгоритм расчета до, а не после создания отчета, а если показатель в результате не слишком хорош, то это означает, что в будущем нужно ставить более адекватные цели.

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

Cтатья подготовлена на основе книги Игоря Гусакова «Анализ и планирование продаж в компаниях рынка FMCG»