До внедрения

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

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

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

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

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

Автоматизация процессов

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

Рис. 1. Общий сценарий работы систем

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

Помимо этого условия, система должна была обеспечивать:

1. Возможность загрузки исходных данных из файлов в формате csv с разделителем «;».

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

3. Создание интерактивных визуальных представлений данных.

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

5. Возможность доступа пользователей к данным следующими методами:
   - «толстый клиент» - десктопное приложение;
   - веб-браузер Internet Explorer, Chrome, Mozilla FireFox, Safari;
   - доступ через мобильные устройства на платформах iOS и Android;
   - выгрузку аналитических данных в формате xls.

6.  Авторизацию пользователей с использованием доменной учетной записи Active Directory.

7. Возможность настройки доступа пользователей в систему, используя ролевой механизм.

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

Исходя из полученных требований, была предложена одна из ведущих аналитических платформ и определена архитектура, изображенная на рисунке 2.

Рис. 2. Архитектура системы

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

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

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

Анализ данных

При реализации проекта требовалось учесть объемы анализируемых данных в конечных приложениях – предполагалось, что объем таблиц фактов по каждому бизнес-направлению не будет превышать 10 млн строк фактов, а также глубину хранения анализируемых данных – с 2008 года. Планировалось, что количество одновременно работающих с системой пользователей не превысит 10 человек, а количество запросов составит до 5 запросов в минуту.

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

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

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

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

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

Как только заявленное судно пришвартовалось, начиналась погрузка продукции на судно, в то время как часть судов находилась на рейде (в очереди на погрузку) и в ожидаемом подходе (держат курс на порт).

Саму концепцию приложения можно охарактеризовать как «весь бизнес перед глазами». Как видно на рисунке 3, на одном экране реализован весь бизнес-процесс от перевалки до отправки судна из порта. Эта концепция позволяет топ-менеджменту заказчика видеть как картину бизнеса в целом, так и оценивать его отдельно взятые части.

Рис. 3. Конечное приложение. Dashboard.*

* Все данные сгенерированы автоматически и не имеют сходства с реальным бизнесом

Рис. 4. Конечное приложение. Analysis.*

* Все данные сгенерированы автоматически и не имеют сходства с реальным бизнесом

Плюсы аналитического приложения

Оценивая приложение целиком, можно говорить о том, что у пользователя не было опыта работы с BI-приложениями. Его восприятие – это тип Bottom Up, то есть восприятие первичное, которое не основывается на предыдущем опыте и формируется практически мгновенно при работе с приложением. В отличие от Top Down (на восприятие влияет полученный ранее опыт) главная задача разработчика не запутать и не запугать пользователя сложным интерфейсом, а максимально просто привести его к нужной ему аналитике, например, попасть на отдельную страницу «выгрузка вагонов» с более детальной информацией по этой области.

При разработке нового приложения предполагалось, что топ-менеджмент оценивает верхнеуровневые показатели на вкладке Dashboard (рис. 3), в то время как аналитики проводят наибольшее количество времени, работая с более детализированными Analysis (рис. 4) и Reporting (предлагает информацию с наибольшей гранулярностью, обычно в виде простых таблиц). Однако в данной работе Reporting отсутствует, поскольку необходимости в создании отчета только с таблицами не было.

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

В целом трехступенчатый подход, Dashboard-Analysis-Reporting (последние 2 блока совмещены и используются совместно с ассоциативной моделью), позволил эффективно обращаться с полученной информацией, анализировать бизнес быстро, наглядно и, при необходимости, детально.

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

Источник: журнал «Морские перевозки»