IT в помощь готовой еде.

Любому руководителю важна информация, отражающая скорость и качество работы области, за которую он отвечает. В 2020 году мы в Х5 Tech начали поддерживать производство готовой еды Smart Kitchen («Фабрика кухни») и изучать его внутренние процессы. Оказалось, что руководители поздно получают важную для бизнес-процессов информацию. К примеру, отчёты о сроках отгрузки или списанных позициях IT-платформа считает лишь к середине или даже концу следующего дня.

Smart kitchen — производство площадью 26 000 м², на котором работают 700 сотрудников. Они производят более 200 различных видов кулинарии, а контролировать процессы помогают две основные системы:

• SAP EWM, в который входят приёмка сырья, логистика, комплектование и отгрузка.

• SAP FK, отвечающее за производство: выпуск продукции, контроль их качества и прочее.

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

Так у нас появилась идея создать сервис, который будет отвечать следующим требованиям:

Содержать в себе важную бизнес и IT-информацию: доступность тех или иных серверов приложение, SAPов и баз данных.

• Быстро и постоянно обновлять большую часть собираемых данных — раз в пять минут.

• Будет отправлять оповещения пользователям при отклонении от целевых показателей. Например, в какой-то день нельзя списать больше 100 тысяч, поэтому если списывается 101 тысяча, то руководителям разного уровня приходит смс или письмо об этом.

На чём строится решение

За основу реализации идеи выбрали open source систему мониторинга Zabbix. До этого мы уже работали с ней в качестве системы отображения ключевых бизнес-показателей в распределительном центре.

Так мы пришли к следующему архитектурному решению:

Первый вариант, в виду малого количества метрик, использовал связку Grafana+Zabbix. Такое решение было обосновано тем, что это open source, а соответственно не требовало дополнительных затрат и с их помощью довольно просто собирать и визуализировать данные.

Но от Grafana пришлось отказаться, т.к. планировалось увеличение количества метрик и с ними необходимо было производить вычисления.

В итоге мы решили использовать собственное решение, основанное на Python (Django), плюс bootstrap и пара самописных js-скриптов для фронтенда.

Принцип работы получался такой:

Zabbix с определенным интервалом обращается к методу, предварительно разработанному в SAP Odata, тем самым запуская алгоритм сбора и предоставления данных. После этого Zabbix получает данные в формате xml, где они парсятся на отдельные значения.

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

После авторизации пользователя (запрос проходит через AD), сервер отображает страницу шаблон, а js-скрипты забирают данные по внутреннему api, при этом стороне бэкенда делается запрос в Zabbix api, где мы получаем последние собранные данные и в итоге всё выводится в структурированном виде в браузере.

Реализовав первую метрику (время отгрузки), мы обсудили результат с руководителями производства. Каждый предложил своё видение метрик, которые должны быть на платформе. При этом для разных отделов важны свои показатели.

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

Чтобы метрики верно считались, мы прорабатывали их с коллегами из финансового отдела. Это позволило достичь максимальной точности в сборе данных.

На следующем этапе развития появилась необходимость отображать табличные данные. С этого момента стало понятно, что собирать данные через Zabbix уже больше не вариант, и необходимо искать альтернативу, т.к. это всё-таки система мониторинга, а не база данных, плюс позволяет хранить только отдельные значения (метрики) и их историю, а не целые таблицы. Был вариант сохранять xml полностью, но это вызывало неоправданный рост объема БД и снижение производительности, особенно, если нужны были исторические данные и несколько пользователей обращались к одной и той же странице.

Поэтому в проект добавили celery в качестве сборщика данных.

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

Пример такого таска:

@app.task
def sl_task():
    result = {}
    try:
        result = parser_fiwr.parser_page_sl('SLNew')
    except Exception as err_res:
        logger.error(f'Данные для блоков не найдены: {err_res}')
    if result:
        try:
            record_fc = AccumSlFoodcost(
                per_min_fc = result['sl_result']['min_fc_percent'],
                per_avg_fc = result['sl_result']['avg_fc_percent'],
                per_max_fc = result['sl_result']['max_fc_percent'],
                per_w_avg_fc = result['sl_result']['w_avg_fc_percent'])
            record_fc.save()
            logger.info('Данные для блока `SLNew` сохранены')
        except Exception as err:
            logger.error(f'Не удалось сохранить данные для блока `SLNew`: {str(err)}')
    else:
        logger.error(f'Не удалось сохранить данные для блока `SLNew` нет данных в источнике')

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

@app.task
def clear_old():
    old_date = datetime.today() - timedelta(days=10)
    try:
        AccumSlFoodcost.objects.filter(created_at__lte=old_date).delete()
        logger.info('Очистка старых данных завершена')
    except Exception as err_res:
        logger.error(f'Не получилось очистить старые данные: {err_res}')

Что в итоге

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

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

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

Что хотим добавить

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

• Уведомления руководителей в случае отклонения производства от целевых показателей.

• Дэшборд производства:

• Дэшборд по сырьевому складу:

• Дэшборд логистического центра:

• IT показатели: