Подпишитесь на рассылку «Точки роста»
eng
image
Подписаться
Заказать звонок
Заказать демо
Чат

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

Рубрика:Экспертное мнение
Дата публикации: 5 Апреля 2017
Автор:Игорь Гусаков
Без постоянного внимания к тому, насколько аккуратно ведется справочная информация в учетной системе, невозможно получить качественную отчетность. Часто операторы забывают указать значения одной или нескольких аналитик клиента или продукта, и в отчетах сразу возникают так называемые «дырки».
Контроль качества данных

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

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

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

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

Читайте также:
Как привести в порядок клиентскую базу данных

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

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

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

Разбираем ошибку в отчете «Продажи по каналам»

Традиционно в компаниях есть разделение команд продаж по каналам. Например, г-н Иванов и его подчиненные работают с ключевыми клиентами. Соответственно, если мы увидим фамилию г-на Иванова и в канале HORECA, это должно вызвать у нас подозрение. Углубившись, мы увидим, например, что это происходит потому, что один из подчиненных Иванова, некто Петров, продал продукцию не только своим гипермаркетам, но и трем торговым точкам, относящимся к HORECA. Посмотрим на эти точки внимательнее, а еще лучше — позвоним Петрову. Оказалось, что одна точка указана как HORECA ошибочно, и это нужно исправить, вторая точка вообще относится не к Петрову, а к Сидорову из другого отдела, и, наконец, третья точка действительно принадлежит каналу HORECA, но обслуживается Петровым по решению его руководства. Ошибки исправлены, а наличие фамилий Иванова и Петрова в канале HORECA теперь легитимно.

Однако такой контроль требует гораздо более глубокого знания устройства компании, понимания ее бизнес-процессов, ее территориально-организационной структуры и т.д.

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

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

Читайте также:
Миллионы измерений OLAP

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

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

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

Возможные ошибки в отчете по измерению «география»

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

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

Читайте также:
Мон’дэлис Русь: грани анализа

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

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


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


Вам также могут быть интересны статьи: