Современная система анализа данных включает в себя три составляющие: хранилище данных, средства обработки данных и средства визуализации результатов обработки. Хранилище данных заполняется данными, извлекаемыми из оперативных учетных систем. Средства обработки (нейронные сети, деревья решений, ассоциативные правила и др.) позволяют извлечь знания из данных, превратив их в информацию, необходимую для поддержки принятия решений. Средства визуализации служат для наглядного представления результатов обработки.

Есть проблема

Для анализа используются мощные средства Data Mining. Однако, часто забывают, что качество анализа зависит не только от применяемых математических методов, но и, в первую очередь, от качества данных, предъявляемых на обработку. Если исходные данные содержат ошибки, то результат обработки может не показать наличия закономерностей или даже выявить ложные зависимости. Вследствие этого могут быть приняты ошибочные решения, которые повлекут потерю прибыли, клиентов, сегментов рынка и даже всего бизнеса. Здесь идет речь не об ошибках, имеющих статистическую природу, исправляемыми методами прикладной статистики, а о грубых ошибках целостности, достоверности и полноты данных. Наличие ошибок в данных не только препятствует проведению анализа, но и косвенно указывает на возможные проблемы в финансовой отчетности (всем понятно, чем грозит, к примеру, предоставление ошибочных данных в налоговую инспекцию) или факты мошенничества со стороны персонала предприятия.

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

Перечислим, не претендуя на полноту, возможные источники ошибок в данных:

  1. Ошибки ввода;
  2. Ошибки в программном обеспечении торгового терминала;
  3. Ошибки в базе данных системы учета торговых операций;
  4. Ошибки консолидации данных из различных филиалов торговой сети;
  5. Ошибки импорта в хранилище данных.

    Рассмотрим более подробно перечисленные источники ошибок.

    Ошибки ввода

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

    Ошибки в программном обеспечении торгового терминала

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

    Ошибки в базе данных системы учета торговых операций

    Современные системы управления базами данных поддерживают различные механизмы обеспечения целостности и непротиворечивости данных и характеризуются высокой степенью надежности. К сожалению, разработчики баз данных не всегда пользуются этими средствами. Унаследованные системы зачастую используют устаревшие механизмы хранения данных (файлы таблиц DBase или Paradox), не удовлетворяющие современным требованиям надежности. Большинство современных систем управления базами данных поддерживают реляционную схему представления данных. Хорошо, если разработчик корректно спроектировал схему базы (что далеко не всегда случается), чем предохранил данные от массы потенциальных ошибок. Но все равно существуют правила корректности данных, которые не могут автоматически учитываться стандартными механизмами контроля корректности реляционных баз данных. К примеру, не проверяется правильность расчетных величин, появление дубликатов записей в таблицах и др.

    Ошибки консолидации данных из различных филиалов торговой сети

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

    Ошибки импорта в хранилище данных

    Импорт данных может производиться непосредственно из СУБД или через промежуточные файлы. При непосредственном переносе строится набор SQL-запросов и отправляется на обработку СУБД посредством таких механизмов, как ODBC, OLE DB или специальных (прямых) драйверов СУБД. Если используются промежуточные файлы, то сначала производится экспорт данных в файлы выбранного формата (текстовые файлы, файлы MS Excel, файлы DBase, XML) и только затем – импорт данных в хранилище из этих файлов. Ошибки могут возникнуть при любой схеме и на любом шаге. Ошибки могут содержаться в SQL-запросе, в драйверах баз данных; детали реализации форматов файлов экспорта могут реализовываться и интерпретироваться по-разному в программах экспорта и импорта.

    Ошибки в данных можно классифицировать по уровню локализации:

    1. Уровень поля записи
    2. Уровень записи
    3. Уровень таблицы
    4. Уровень базы данных
    5. Уровень консолидированных данных

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

      Есть решение

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

      • Пригодны ли данные в текущем состоянии для аналитической обработки?
      • Насколько корректно работает учетная система?

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

        Процедуры проверки данных, представленные в решении Deductor:RetailProfiler, охватывают все перечисленные классы ошибок. Процедуры проверки разбиты по группам, при определении которых были учтены вышеприведенные классификации типов ошибок.

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

        1. Не указан филиал
        2. Не указан номер кассы
        3. Не указан кассир
        4. Не указана группа товаров
        5. Не указан товар
        6. Не указана дата продажи
        7. Не указано количество товара
        8. Не указана скидка
        9. Не указана торговая наценка
        10. Не указана цена поставщика
        11. Не указана цена продажи

          Во вторую группу входят процедуры проверки допустимости значений и сочетаний значений полей записей:

          1. Цена продажи меньше цены поставщика.
          2. Торговая наценка нулевая или отрицательная.
          3. Цена поставщика нулевая или отрицательная.
          4. Фактическая цена продажи не равна расчетной.
          5. Недопустимое значение даты продажи.
          6. Штучный товар с дробным количеством.
          7. Неверный код филиала, кассира, группы товаров, товара.

            В третью группу входят процедуры выявления противоречий в записях одного чека. Эти ошибки относятся к классу ошибок на уровне таблицы:

            1. Противоречие в дате выдачи чека.
            2. Противоречие в номере кассы.
            3. Противоречие в параметрах кассира, выдавшего чек.

              В четвертую группу отнесены процедуры выявляющие ошибки несогласованности данных в базах данных. Эти ошибки возникают при консолидации данных из разных филиалов торговой сети:

              1. Разные наценки в филиалах.
              2. Товары в разных группах.
              3. Разные наименования товаров.
              4. Разные коды товаров.
              5. Разные единицы измерения.
              6. Дублирование кода товара.
              7. Дублирование наименования товара.
              8. Разные наименования групп товаров.
              9. Разные коды групп товаров.
              10. Дублирование кода группы товара.
              11. Дублирование наименования группы товаров.

                В пятую группу входят процедуры, выявляющие подозрительные данные. Критерии "подозрительности" записи основаны на закономерностях, присущих сфере торговли:

                1. Подозрение на ошибку в цене поставщика.
                2. Подозрение на ошибку в наценке
                3. Подозрение на ошибку привязки операции продажи к месту продажи
                4. Аномальная скидка
                5. Аномальное количество товара
                6. Подозрение на утерю данных продаж

                  Принцип работы этих процедур можно пояснить на примере поиска аномальных значений количества товара в чеке. Формально количество конкретного продаваемого товара может быть почти произвольным, и никакая учетная система не будет контролировать явно ошибочные, с точки зрения здравого смысла, значения. К примеру, не продают 10 грамм колбасы или 100 кг горчицы. Количество продаваемого товара чаще всего подчиняется нормальному закону распределения. Этот факт можно задействовать для выявления аномальных значений количества товара. На основе сравнения количества товара в чеке и статистических данных выявляются резко нетипичные значения (выбросы) которые с большой вероятностью окажутся ошибочными.

                  Стандартная схема мониторинга качества данных

                  Поиск ошибок следует начинать с поиска пробелов в данных, т.к. остальные процедуры проверки ориентированы на работу с заполненными полями записей. Оставшиеся проверки включают поиск ошибок в значениях записей, ошибок консолидации данных и поиск подозрительных записей. Результаты проверок объединяются в небольшое количество сводных отчетов с возможностью детализации.

                  Обнаруженные ошибки необходимо проанализировать. Возможны следующие ситуации:

                  1. Обнаруженные ошибки делают данные полностью непригодными для анализа
                  2. Ошибочных записей немного, и их можно просто удалить
                  3. Некоторые ошибки указывают на серьезные проблемы в OLTP-системе
                  4. Обнаруженные ошибки (все или часть) вовсе не являются ошибками

                    Процедуры проверки не укажут причину появления ошибок и способ их устранения. Но наличие регулярных процедур проверки предотвращает бесполезную или даже опасную аналитическую обработку некорректных данных. Обработка некорректных данных опасна тем, что построенные на их основе некорректные модели могут послужить ориентиром в принятии важных управленческих решений. Выявленные ошибки могут служить индикатором проблем в OLTP-системе. Наличие серьезных ошибок в данных может служить обоснованием необходимости смены OLTP-системы или ее серьезной доработки.

                    Основные отчеты

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

                    Отчет о пропусках и ошибках в данных продаж
                    Рисунок 1. Отчет о пропусках и ошибках в данных продаж.

                    Отчет о противоречиях и дублировании в чеках
                    Рисунок 2. Отчет о противоречиях и дублировании в чеках.

                    Отчет о подозрениях на ошибку в данных продаж
                    Рисунок 3. Отчет о подозрениях на ошибку в данных продаж.

                    Анализ предоставленных скидок
                    Рисунок 4. Анализ предоставленных скидок.

                    Пример работы системы

                    Пусть имеется сеть розничной торговли. Данные по продажам за день пересылаются в центральный офис по модемной связи. В центральном офисе данные из филиалов за день консолидируются и сохраняются в файлах фиксированного формата. Перед тем, как импортировать данные в основное ХД, аналитик выполняет проверку с помощью Deductor:RetailProfiler. По результатам проверки формируются несколько консолидированных отчетов. Процесс оценки качества данных представлен на рис. 5.

                    Пример процесса мониторинга качества данных
                    Рисунок 5. Пример процесса мониторинга качества данных.

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

                    Пример процесса мониторинга качества данных
                    Рисунок 6. Пример функциональной схемы мониторинга качества данных.

                    Решение можно усовершенствовать, если установить систему мониторинга качества данных Deductor:RetailProfiler в каждом филиале. Тогда существенная часть ошибок в данных была бы выявлена еще до отправки данных в центральный офис. Чем ближе расположена система мониторинга качества данных Deductor:RetailProfiler к источнику данных, тем оперативней выявляются и исправляются ошибки.

                    Заключение

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

                    Основные преимущества Deductor:RetailProfiler:

                    1. Система мониторинга качества данных и аналитическая система реализованы на базе единой платформы Deductor
                    2. Используются развитые средства Deductor для обработки больших объемов данных
                    3. Учтены особенности сферы розничной торговли
                    4. Не требуется дополнительного программирования

                      Многие представленные процедуры проверки данных могут быть распространены и на другие прикладные области (например, оптовая торговля). Для дальнейшего развития системы Deductor:RetailProfiler можно задействовать методы Data Mining для выявления устойчивых закономерностей и обнаружения записей, нарушающих эти закономерности.

                      www.on-crm.ru

                      Онлайн CRM система:
                      - единая база клиентов
                      - история взаимодействий
                      - учет продаж

                      www.kvartiran.ru

                      Портал - все новостройки СПб
                      - база новостроек
                      - поиск квартир
                      - бронирование квартир

                      www.on-realty.com

                      Сервисы для риелторов
                      - Сайт агентства недвижимости
                      - База новостроек
                      - Виджет каталога новостроек

                      jooble - работа для SEO специалистов
                      Санкт-Петербург, Полюстровский пр., д. 43А © sinercom.ru, 2024

                      (812) 385-72-26

                      @

                      sinercom@sinercom.ru

                      wolter-sc

                      Карта сайта