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

3.2 Анализ результатов внедрения системы мониторинга консистентности данных в эксплуатацию

После написания технического задания и передачи его команде разработчиков, следуют этапы разработка информационный системы и ее ввод в эксплуатацию. Эти этапы были осуществлены согласно п.5 «Состав и содержание работ по созданию системы», п.6 «Порядок контроля и приемки Системы» и п.7 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» технического задания (см. Приложение 1).

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

Во-первых, было обнаружено 3 070 036 расхождений в рамках проверки «WMS > OPS: Приемка возвратов». Эти расхождения приводили к тому, что доход компании оценивался выше, чем он был на самом деле, а также выплаты некоторым поставщикам товаров были больше, в результате чего компания несла убытки. Поиск таких расхождений помог сохранить компании 8 518 млн рублей. В рамках проверки «WMS > OPS: Отгрузка товара» было найдено 378 расхождений, которые также являлись потенциальными потерями для компании, так как учетная система не знала об отгруженных товарах, и, соответственно, не знала, что должна «получить» за них деньги. Поиск таких расхождений помог сберечь компании около 1 млн рублей. Таким образом, одним из важных результатов автоматизации процесса мониторинга консистентности можно считать сбережение бюджета компании.

Во-вторых, на начало функционирования системы было выявлено около 6 млн расхождений. На текущий момент число этих расхождений варьируется около 40 000 и находится в процессе исправления. Снижение числа расхождений между информационными системами является показателем повышения качества данных в компании ХХХ.

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

Заключение

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

В работе были изучены методы и инструменты оценки качества данных. Некоторые концепции управления качеством данных были применены на практике для разработки системы мониторинга консистентности данных в компании ХХХ.

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

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

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

Список литературы

1. Wang, R. Y., & Strong, D. M. (1996) Beyond Accuracy: What Data Quality Means to Data Consumers. Journal of Management Information Systems, 12(4): pp 5-33.

2. General Administration of Quality Supervision (2008) Inspection and Quarantine of the People's Republic of China. Quality management systems-Fundamentals and vocabulary (GB/T19000--2008/ISO9000:2005), Beijing.

3. Alexander, J. E., & Tate, M. A. (1999) Web wisdom: How to evaluate and create information on the web, Mahwah, NJ: Erlbaum.

4. Alan, F. K., Sanil, A. P., Sacks, J. (2001) Workshop Report: Affiliates Workshop on Data Quality, North Carolina: NISS.

5. Cao, J. J., Diao, X. C., Wang, T. (2010) Research on Some Basic Problems in Data Quality Control. Microcomputer Information, 09: pp 12-14.

6. Goasdouй V., Nugier S., Duquennoy D., Laboisse B. (2007) An evaluation framework for Data Quality Tools, ICIQ.

7. Juran, J. M. (1989). Juran on Leadership for Quality: An Executive Handbook, NY: The Free Press.

8. The Data Management Association (2008). The DAMA Dictionary of Data Management. Bradley Beach, NJ: Technics Publications LLC.

9. English, L. (1999). Improving Data Warehouse and Business Information Quality. Wiley & Sons.

10. The Customer Data Integration Institute (2006). Corporate Data Governance Best Practices - 2006-07 Scorecards for Data Governance in the Global 5000.

11. The Data Management Association (2008). The DAMA Dictionary of Data Management. Bradley Beach, NJ: Technics Publications LLC.

12. Batini, C., Cappiello, C. Francalanci, C. & Maurino, A. (2009). Methodologies for data quality assessment and improvement. ACM Comput. Surv, 41 (3).

13. Gartner [Электронный ресурс] Gartner Magic Quadrant for Data Quality Tools / Friedman T. & Bitterer, A. (2009). URL: http://www.gartner.com/technology/media-products/reprints/dataflux/167657.html.

14. International Standards Organization (2005). ISO 9000:2005 (E). Quality Management Systems: Fundamentals and Vocabulary (3rd edition).

15. В.Н. Любицын (2012). Повышение качества данных в контексте современных аналитических технологий. Вестник ЮУргГУ, № 23.

16. Gartner [Электронный ресурс] 2016 Magic Quadrant for Data Quality Tools, 23 November 2016. - URL: https://www.gartner.com/doc/3522717/magic-quadrant-data-quality-tools.

17. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы.

Приложение 1 Техническое задание на создание системы мониторинга консистентности данных

1. Общие сведения

1.1. Наименование системы

Полное наименование системы: Система мониторинга консистентности данных.

Краткое наименование системы: Система.

2. Назначение и цели создания системы

2.1. Назначение системы

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

Основным назначением Системы является автоматизация мониторинга показателя консистентности качества данных.

2.2. Цели создания системы

Система создается с целью:

· улучшить качество поступающих данных;

· снизить число расхождений между информационными системами компании;

· повысить качество и достоверность формируемой отчетности.

3. Характеристика объекта автоматизации

Объектом исследования при создании и внедрении системы является компания ХХХ и департамент бизнес-анализа компании.

Предметом исследования являются процессы мониторинга качества данных в компании ХХХ.

4. Требования к системе

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию систем

4.1.1.1. Требования к структуре системы

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

4.1.1.2. Перечень подсистем, их назначение и основные характеристики

В состав системы должны входить следующие подсистемы:

1. Подсистема сбора и преобразования данных, которая предназначена для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных.

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

3. База данных, предназначенная для хранения информации о проверках.

4. Подсистема отображения результатов мониторинга, предназначенная для формирования графической отчетности.

4.1.1.3. Требования к режимам функционирования системы

К функционированию системы предъявляются следующие требования:

- круглосуточная работоспособность системы;

- наличие обработки исключительных ситуаций;

- защита информации от несанкционированного доступа;

- обеспечение сохранности информации при авариях;

- обеспечение хранения и распространения форм отчетности.

4.1.2. Требования к надежности

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

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

4.1.3. Требования к безопасности

Защита от несанкционированного доступа должна происходить при помощи разграничения полномочий и обеспечения безопасности хранения, предоставляемых программным обеспечением СУБД и операционной системой, на которых функционирует Система.

В Системе должно обеспечиваться разграничение прав доступа по следующим уровням:

- разграничение доступа к данным

- разграничение возможностей работы с данными (просмотр, редактирование)

В рамках Системы должны присутствовать функции администрирования:

- настройка полномочий пользователей

- ведение мониторинга ошибок Системы

- ведение списка пользователей, имеющих доступ к системе

- ведение списка всех действий пользователя

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

4.2. Требования к функциям, выполняемым системой

4.2.1. Требования к подсистеме сбора и преобразования данных

1. Подсистема сбора и преобразования данных должна обеспечивать возможность извлечения данных из систем-источников, использующих различные виды баз данных (PostgreSQL, MySQL, Oracle и тд.).

2. Подсистема сбора и преобразования данных должна поддерживать извлечение данных измененных или добавленных с момента последнего успешного извлечения данных (инкрементальное извлечение данных).

3. Подсистема сбора и преобразования данных должна обеспечивать возможность отслеживания статуса ETL-процесса с указанием количества элементов данных, извлеченных из систем-источников.

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

5. Подсистема сбора должна отправлять отчет о работе подсистеме управления проверками.

4.2.2. Требования к подсистеме управления проверками

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

2. Подсистема управления проверками должна запускать скрипты проверок к базе данных системы мониторинга.

3. Подсистема управления проверками должна формировать excel-файлы с результатами проверок.

4. Подсистема управления проверками должна выполнять рассылку excel-файлов с результатами проверок ответственным департаментам.

5. Подсистема управления проверками должна формировать html-файлы с результатами проверок для дальнейшей передачи их в подсистему отображения результатов мониторинга.

6. Подсистема управления проверками должна передавать html-файлы с результатами проверок подсистему отображения результатов мониторинга.

4.2.3. Требования к базе данных системы мониторинга

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

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

a. Промежуточный раздел, в котором консолидируются данные с систем-источников.

b. Раздел служебных данных, в котором хранятся настроечные таблицы для функционирования системы:

i. текущие значения инкрементов;

ii. SQL-скрипты для реализации каждой из проверок;

iii. cписки получателей результатов проверок и тд.

c. Раздел результатов проверок, в котором содержатся найденные расхождения. Должен включать как список с результатами по каждой проверке, так и уникальный список расхождений.

d. Раздел, содержащий таблицы, используемые средствами визуализации - подсистемой отображения данных мониторинга.

4.2.4. Требования к подсистеме отображения результатов мониторинга

1. Подсистема отображения данных мониторинга должна обеспечивать пользователям доступ через WEB-браузер без установки дополнительного программного обеспечения.

2. Система должна поддерживать браузеры Internet Explorer, Safari, Mozilla Firefox, Google Chrome.

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

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

4.3. Требования к видам обеспечения

4.3.1. Требования к информационному обеспечению

Хранение данных в системе должно быть реализовано при помощи современных реляционных или объектно-реляционных СУБД.

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

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

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

4.3.2. Требования к лингвистическому обеспечению

Система должна быть реализована с использованием языков программирования высокого уровня, имеющих промышленные масштабы развития и сопровождения: SQL, Java, Python.

Запуск работы Системы должен быть реализован с использованием командной оболочки UNIX (Shell).

Для реализации алгоритмов манипулирования данными в базе данных необходимо использовать стандартный язык запроса к данным SQL и его процедурное расширение PL/pgSQL.

При взаимодействии системы с web-приложением должен применяться язык HTML.

4.3.3. Требования к программному обеспечению

База данных Системы должна быть построена на базе СУБД PostgreSQL 9.5.2 (64-bit).

Управление проверками и взаимодействие web-приложения с базой данных должны осуществляться при помощи Python 2.7.

Для построения графиков на основе проверок используется JavaScript-библиотека d3.js.

4.3.4. Требования к техническому обеспечению

Под разрабатываемую Систему должны быть выделены сервера компании.

Сервер базы данных и сервер web-приложения должны быть развернуты на серверной платформе со следующими характеристиками: CPU Intel Xeon Processor E5-2650 v3, ОЗУ: 16 Гб, HDD: 500 Gb, тактовая частота процессора: 2,3 GHz.

5. Состав и содержание работ по созданию системы

Процесс создания Системы, согласно ГОСТ 34.601-90, представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания Системы, соответствующей требованиям, описанным в предыдущих разделах данного документа. В Таблице 1 приведено подробное поэтапное описание состава работ по созданию системы.

Таблица 1

Состав работ по этапам

5.1. Содержание работ первого этапа

5.1.1. Устав проекта

Устав проекта является основным документом, регламентирующим проект, в котором определяются:

- состав проектной группы

- сроки согласования проектных документов

- политика информационной безопасности

5.1.2. Техническое задание

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

- подсистема сбора и преобразования данных;

- подсистема управления проверками;

- база данных системы мониторинга;

- подсистема отображения результатов мониторинга.

5.2. Содержание работ второго этапа

На третьем этапе проводится разработка программного обеспечения Системы согласно утверждённому техническому проекту, описаниям информационного и программного обеспечения и другим документам первого этапа проекта.

С целью проведения испытаний Системы должен быть реализован пользовательский интерфейс для проверки работоспособности web-приложения. К дизайну и удобству использования данного пользовательского интерфейса требований не предъявляется.

5.3. Содержание работ третьего этапа

На третьем этапе проводится ввод в действие Системы.

1. Должны быть проведены предварительные испытания Системы по утверждённой программе и методике испытаний.

В ходе предварительных испытаний должно быть проведено функциональное тестирование Системы.

2. Должна быть произведена отладка взаимодействия со смежными системами.

3. Должны быть проведены приемочные испытания Системы согласно п.6 «Порядок контроля и приемки Системы» настоящего документа.

6. Порядок контроля и приемки Системы

Результатом работ должна являться работоспособная Система и комплект документации на Систему.

Испытания представляют собой процесс проверки выполнения заданных функций системы, определения и проверки соответствия требованиям технического задания характеристик Системы, выявления и устранения недостатков в действиях Системы, в разработанной документации.

Система проходит следующие виды испытаний:

· предварительные испытания;

· приёмочные испытания.

Предусмотренные испытания проводятся аналитиками департамента бизнес-анализа.

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

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

Для проведения испытаний необходимо обеспечить программно-аппаратный комплекс, характеристики которого соответствуют требованиям, указанным в техническом задании к Системе.

Объем работ по каждому виду испытаний приведен в Таблице 2:

Таблица 2

Объем работ по видам испытаний

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Для создания необходимых условий функционирования Системы и гарантии ее соответствия требованиям, описанным в настоящем техническом задании, необходимо провести комплекс мероприятий.

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

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

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

Приложение 2 SQL-скрипты проверок

В Таблице 1 представлены скрипты проверок. В колонке «Проверка» указано наименование проверки в формате «Источник А > Источник Б «Наименование проверки», в колонках «Запрос к источнику А», «Запрос к источнику Б» - sql-скрипты, выполняющие выгрузку данных из систем-источников, в колонке «Запрос проверки» содержит sql-скрипт, сравнивающий данные с двух систем.

Таблица 1

Скрипты проверок систем-источников