Сведение больших массивов отчетов по продажам/остаткам

Сведение больших массивов отчетов по продажам/остаткам

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

Почему не получается отчетность?

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

reports1

Задача собрать «срез» по этому разлапистому дереву, каждый «узел» которого управляется независимым агентом со своими системами учета, традициями, справочниками, политикой и представлением о прекрасном — весьма нетривиальна.

Обычный подход к снаряду выглядит так:

  1. Разработать форму отчетности в Excel со всеми нужными полями
  2. Обязать всех участников сбытовой сети заполнять эти формы раз в месяц или раз в неделю
  3. Создать механизм сбора заполненных форм
  4. Агрегировать собранные формы и получить отчет

Механизм простой и понятный, но обычно он не работает. Точнее говоря, прекрасно работает все вплоть до п. 4. Проблема в том, что данные не агрегируются. Не сводятся. Итоговый отчетный массив оказывается паталогически захламлен ошибками, опечатками и неточностями, неоднозначными определениями и прочими проблемами качества данных.

Почему это происходит? Где-то эти отчеты составляют действительно руками, где-то выгружают из учетных систем. Причина тривиально проста: нет единых справочников, единого массива мастер-данных, каждый участник как правило выгружает данные из своей учетной системы, а системы участников, естественно, не синхронизированы между собой.

Проблемы возникают буквально по всем направлениям:

  1. Наименования товаров пишутся по разному у разных дилеров, в разных сетях. Где-то они оптимизированы под печать ценников, где-то были введены руками в сокращенном виде. SKU-коды производителя как правило не используются, на штрих-коды так же надежды особой нет. Плюс опечатки и ошибки.
  2. Наименования участников так же сильно захламлены. Учитывая, что нет строгой иерархии, одному дилеру могут отгружать товар несколько  дистрибуторов, легко «свести» отчетность по участникам сбытовой сети тоже не получится. Тут еще как-то может помочь ИНН, но даже если включить его в отчет, нередко он будет просто не заполнен.
  3. С идентификацией торговых точек все те же проблемы, что с компаниями, усугубленные тем, что торговое наименования и юрлицо — не одно и то же. При этом, опять же, в одну торговую точку товары могут попадать через разных дилеров и дистрибуторов, которые по разному идентифицируют ее, одни по торговой марке, другие по юрлицу.
  4. С плоскостью регионов тоже все не слава Богу, ибо очень сложно заставить людей заполнять нефункциональные поля, например «регион», которых, к тому же, нет в их учетных системах.
  5. Ну и самая интересная плоскость анализа — анализ по товарным группам, оказывается почти невозможен. Нереально заставить людей использовать в отчетах ваши, а не свои товарные группы, ибо их надо проставлять руками. В то же время искажения в написании не позволяют просто и быстро связать строки отчетов со своим базовым товарным справочником.

Таким образом, попытка «лобового» сведения отчетного массива средствами СУБД приводит к тому, что число «товаров» в отчете может в разы превышать номенклатуру (каждое разное написание для компьютера — отдельный товар), точно так же в разы может превышать число «партнеров» и «торговых точек». Ну и помимо всего того, позиции отчета фактически «не вяжутся» с собственным товарным каталогом.

В результате формально отчет есть, но его качество делает его совершенно бессмысленным. А попытка «привести данные в порядок» руками — обречена на провал если у вас порядка 10 тыс. файлов, в которых несколько миллионов строк с данными. Это совершенно реальные, практические цифры.

Что нужно для результата? Алгоритмы!

Итак, для получения нужного результата нам надо всего лишь «свести несводимое». А именно, распознать один и тот же товар, написанный самым разным образом, однозначно идентифицировать партнеров и точки продажи, добавить регионы и товарные группы. И, крайне желательно, сделать это автоматическим образом.

К счастью, у нас есть для этого все инструменты, в частности алгоритмы нечеткого поиска, которые позволяют нам эффективно находить «похожие» сущности, в том числе компенсируя опечатки, ошибки, разный порядок написания и т.д. Применяя эти алгоритмы к наименованиям товара мы можем «привязать» порядка 98% описаний к базовому продуктовому справочнику автоматически, а через это связать конкретные позиции отчета с товарными группами и другим продуктовыми аналитическими полями.

reports2

Аналогично, используя эти алгоритмы мы можем построить мастер-справочник партнеров и точек продажи просто «дедублицируя» массив данных о точках продажи из отчета, «находя похожие». Аналогично — по партнерам. Ну и, вишенкой на торте, вся адресная информация валидируется, приводится к единообразному виду, заполняются поля, связанные с анализом по регионам.

Таким образом, мы фактически строим мастер-данные сбытовой сети, а потом распознаем данные отчетов относительно этих мастер-данных и приводим в единообразный вид в автоматическом режиме с точностью порядка 95-98% . Таким образом из «свалки данных низкого качества» мы создаем массив отчетных данных высочайшего качества, который можно эффективно анализировать в любой BI системе.

Как это происходит?

Мы делаем это с помощью нашего MDM-решения, которое среди прочего может применяться для создания ETL-процедур и процедур обработки данных, «распознавания» мастер-данных в массивах, дедубликации массивов с целью формирования мастер-данных и многого другого. В данном же конкретном случае порядок действий таков:

reports3

Для начала обработки нам понадобится:

  1. Структура отчета — для понимания назначения полей и механизма первичного преобразования. Дело в том, что исторически отчеты обычно собирают файлами Excel, и нам надо «вытащить» из них данные.
  2. Существующие справочники, в первую очередь по товарному дереву. Мы, безусловно, можем сгенерировать товарные справочники прямо в процессе работы, но это непрактично. Гораздо правильнее сразу «распознавать» в строках отчета позиции из своего оригинального товарного каталога, что позволяет одновременно обогатить отчет дополнительными аналитическими признаками из него.
  3. Наши справочники, например, адресный эталонный справочник. Это нужно для приведения в единообразный вид адресов, телефонов, наименований и прочих данных, которые мы используем, чтобы идентифицировать партнеров и точки продажи.
  4. Отчетный массив. Как и было сказано, часть мастер-данных мы будем делать непосредственно из него.
  5. Определить систему сбора отчетов: по электронной почте, загрузкой на FTP, загрузкой на сайт и так далее.

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

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

В автоматическом режиме обрабатываются 97-98% записей, в то же время могут оставаться 2..3% записей, на которых автоматические алгоритмы дают сбои. Эти записи требуют внимания аналитиков, так как основной причиной их появления являются, во-первых, изменения в реальном мире, которые следует отразить в мастер-данных, а во-вторых, небольшой процент случаев, когда «похоже, но не уверен», алгоритм не может принять полностью автоматическое решения. Например, появление новой торговой точки, нового товара или такое уж искаженное их написание, что даже наши алгоритмы пасуют. В этом случае требуется короткое и несложное вмешательство человека-аналитика (дата-стюарда) с целью ответить на вопрос: это новый элемент мастер-данных или он соответствует одному из «похожих» на него существующих? После того, как это решение принято — соответственные изменения вносятся в мастер-данные и повторно с том же вопросом система к человеку не обращается.

Некоторые наши клиенты предпочитают полный автоматизм решений и правила типа «все, что не удалось узнать — трактовать как новый элемент» просто исходя из того, что погрешность в 2..3% для отчетов такого уровня является прекрасным результатом и нет смысла тратить ресурсы на дальнейшее уточнение.

Одновременно с этим мы можем настроить систему сбора регулярных отчетов в соответствии с выбранной технологией. Мы можем принимать их по электронной почте, брать из каталогов сайта или FTP-сервера, создать формы для загрузки и многое другое.

Обработка «в устоявшемся режиме» десяти тысяч файлов с отчетами, содержащими несколько миллионов строк занимает несколько часов, обычно — не более одного рабочего дня.

Что для этого нужно?

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

  1. Установка собственного IQMDM сервера на своей территории и на своих вычислительных ресурсах. В этом случае информация никогда не покидает Ваш контур безопасности. Мы предоставляем лицензии, услуги по настройке, помогаем пройти самый сложный первый этап, этап формирования мастер-данных, и выстроить автоматизированные процедуры, которые сводятся, например, к тому, что все отчеты по мере поступления складываются в один каталог, откуда они берутся системой, обрабатываются и данные из них помещаются прямо в BI систему. В этом случае оплачиваются лицензии на ПО и услуги по конфигурированию системы, а так же заключается контракт на техническую поддержку, обновление системы и эталонных справочников.
  2. Персональный SaaS. В этом случае мы предоставляем в аренду персональный экземпляр ПО вместе с необходимыми вычислительными ресурсами. Мы несем ответственность за доступность и работоспособность системы, ее обновления и т.д., Вы работаете с отчетами и результирующими массивами. Обычно на этапе первой обработки наша помощь все же потребуется, но в установившемся режиме оно прекрасно работает само. В этом случае оплачивается ежемесячная/ежеквартальная аренда ПО и ресурсов, консультации по настройке и поддержка на случай, если что-то у Вас с отчетами пошло не так.
  3. Обработка отчетов как сервис. Раз в определенное время мы получаем от Вас собранный массив отчетов, обрабатываем его и возвращаем Вам результат. Мы храним ваши мастер-данные, которые необходимы для эффективной регулярной обработки. В этом случае вы единократно оплачиваете работы по «инициированию» процесса, созданию необходимых мастер-данных как описано выше, и ежемесячно оплачиваете оговоренную сумму за обработку Ваших отчетов.

Начать стоит с того, что связаться с нами.

Заключение

Хотелось бы заметить, что эффективность наших алгоритмов обеспечивает беспрецедентное качество автоматического «сведения», сопоставимое только с интеллектуальной ручной обработкой. Парадокс, но большинство BI и ETL систем полагают данные изначально качественными, выровненными по единым опорным мастер-данным и справочникам и редко предлагают сколько-нибудь богатый арсенал средств повышения качества данных.

Воспользоваться нашими решениями существенно проще, дешевле и выгоднее, чем идти путем «принуждения источников к порядку». Теоретически можно «заставить людей делать правильно». Можно разработать какое-нибудь мобильное приложение, где надо будет обязательно выбирать все из единых справочников. Можно пытаться заставить всех использовать единые коды. Но как показывает практика — это не работает. Гораздо проще дать людям возможность быстро выгрузить данные из своих систем как они есть, а потом так же быстро и автоматически свести их с совершенно достаточной для качественных управленческих решений точностью.

Share