Современное развитие IT технологий позволило обуздать громадные потоки данных.
У бизнеса появились различные инструменты: CRM, ERP, BPM, бухгалтерские системы или в крайнем случае просто Excel и Word.

Компании тоже бывают разные. Некоторые, состоят из множества обособленных филиалов. В таком случае у бизнеса возникает проблема синхронизации данных в зоопарке IT систем. Тем более, что у филиалов отличаются вендоры или версии ПО. А частые изменения требований к отчётности от управляющей компании вызывают приступы неконтролируемой “радости” на местах.

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

Универсальный формат

Заказчик поставил задачу по сбору данных для отчётов со всех филиалов компании. Для понимания масштаба бедствия — это десятки систем, среди которых как самописные, так и монстры типа SAP, ну и, конечно, 1C — куда без него.

В одном отчёте могли пересечься данные от: бухгалтерии, ремонтников, пиарщиков, МЧС, метеорологов.

До старта проекта основная часть данных отправлялась в головную компанию по email в виде Word/Excel вложений. Далее процесс напоминал закат солнца вручную: данные обрабатывались специально обученными людьми и заносились в пару систем. Результатом труда были десятки отчётов, на основе которых принимались управленческие решения.

На выбор подхода нас натолкнул формат пересылаемых файлов, а именно xlsx/docx. Даже “древние” системы в филиалах поддерживали выгрузку данных в эти форматы, ну или на крайний случай copy-paste никто не отменял.

Наш замысел упрямый был таков:

1. описываем структуру каждого отчёта и регламент его передачи;
2. спускаем в филиалы требования по настройке систем на отправку документов по email согласно регламенту. Где систем нет — отправка, как и раньше, руками;
3. разрабатываем программу, которая:
   
   • отбирает определенные документы из входящей почты;
   • извлекает из них данные;
   • записывает извлеченные данные в БД, а так же “бьёт по рукам” нарушителей регламента.
   
   

Реализация

Организационные вопросы

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

Проблема первая

Отличие структуры документов от эталонных и качество данных. В отчётах порой не сходились суммы, колонки были перепутаны местами или имели некорректные наименования. Проблема в основном наблюдалась в филиалах, где данные вбивались вручную.

Решение — внедрение трёхэтапной проверки:

1. Создание эталонных Excel документов с жёсткой структурой, средствами самого Excel. В таких документах были доступными только ячейки для ввода данных. На которые дополнительно накладывались проверки: типа, схождения сумм и т.п.
2. Проверки при извлечении данных из отчёта. Например, сопоставление текущей даты и даты в абзаце Word документа или арифметические проверки для данных из Excel документа (если их нельзя задать в самом документе).
3. Глубокий анализ данных после сбора. Например, обнаружение значительных отклонений по ключевым показателям в сравнении с предыдущими периодами.

Проблема вторая

Систематическое нарушение графика передачи данных или бессовестные попытки саботажа: «Мы вообще данные никому и никогда не отправляли, а тут вы со своей этой ...», «Да я отправил все, вовремя, это пинг наверное плохой».

Решение — обратная связь. Система автоматически оповещает ответственных лиц в филиале, при нарушении графика. Позже подсистему обратной связи прикрутили к системе проверки качества входных данных и к системе формирования конечных отчётов, чтобы филиал сразу получал свод по своим данным и сравнение с “соседями”. Чтобы было понятно, за что он огребёт.

Разработанные подсистемы

1. Конфигуратор типов документов с данными, в котором можно быстро описать:
   
   • признаки для идентификации документа;
   • регламент передачи;
   • алгоритм извлечения данных;
   • прочие атрибуты вроде пути к коду, который проверяет и сохраняет данные.
   
   
2. Получатель почты, перемещающий вложения в изолированное хранилище (песочницу) и сохраняющий сопутствующую информацию о письме;
3. Парсер вложений, который определяет типы документов и извлекает из них данные.

Конфигуратор

Исторически сложилось так, что все документы с данными приходят на общую почту, где полно других важных и не очень писем. Нужны признаки, по которым будут определяться нужные документы. Название документа или текст в теле email — это все ненадёжно и неудобно для отправителя. Поэтому было принято решение, что принадлежность к отчёту будет определяться только по содержимому документа. Кроме того, нужно однозначно определять, что за тип отчёта содержит документ.

Мозговым штурмом напридумывали хрен знает сколько признаков для идентификации документа: цвет текста в ячейке, шрифт и прочее. Но самым правильными оказалcя признак наличия подстроки в определенной ячейке “слот” или массиве ячеек для Excel и абзаце или заголовке для Word. Для “слота” добавили простую формальную логику: “равно”, “неравно”, “больше”, “меньше” и пр. Пример для Excel: в диапазоне A2-E4 текст ячейки должен быть равен “Ежедневная сводка о загрузке оборудования”.



Схожим образом настраивается область документа, в которой нужно искать начало и окончание данных (прим. условия поиска окончания: 2 пустые строки подряд).



Перечень других полезных настроек: список разрёшенных отправителей, тип документа (Excel/Word) и путь для экспорта данных.

На выходе получаем JSON структуру (шаблон), описывающую отчёт.

Получатель почты

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

Тут есть 2 вопроса по безопасности:

1. что, если данные отправят за другой филиал?
2. что, если данные отправят злоумышленники?

Первый вопрос решается путём сверки email адреса филиала-отправителя и филиала, указанного в теле отчёта.

Второй — с помощью SPF.

Парсер вложений

Почти все библиотеки для парсинга Word и Excel имеют серьёзные ограничения по поддерживаемым версиям, потому для начала документ необходимо сконвертировать. Libre Office решает эту проблему на пятёрку.

После конвертации:

1. отсеиваем массив шаблонов по базовым признакам из конфигуратора (Word/Excel, отправитель ...);
2. прогоняем документ оставшимися шаблонами;
3. если шаблон найден — извлекаем данные и передаём в хранилище.

Итог

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

Для себя мы узнали, что интеграция — это не всегда больно и выделили главные аспекты успеха:

1. мы не лезли внутрь систем в филиалах;
2. формализовали и утвердили единую структуру отчётов и регламент их передачи;
3. создали общедоступные для всех систем шаблоны выходных форматов в виде Excel и Word документов;
4. выбрали самый распространенный способ доставки данных — email.

И два основных недостатка:

• Невысокая скорость доставки данных.
• Размер пакета данных не должен превышать размер обычного email вложения.