Управление товарными запасами. Выступление Никиты Логинова на Loginom Day 2018

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

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

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

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

Проблемы и предпосылки к выбору платформы

Для чего нам потребовалось покупать Loginom, почему не другое решение?

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

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

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

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

Последняя проблема: это – очередь в IT. Это боль всех заказчиков: желаний много, IT-ресурсов мало, рынок меняется быстро, нужно что-то делать.

Получился некий список проблем, который был до внедрения Loginom:

• большой объем данных;
• медленная скорость расчетов;
• человеческие ошибки;
• отсутствие гибкости существующей модели;
• очередь на разработку в IT.

Выбор решения

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

1. Написать код на языке программирования (Python, Java Script и т.д). Получаем очень гибкие модели. Я – сторонник этого решения, потому что можем написать что угодно и как угодно. Но есть большие риски: команда разработчиков – это 2-3 человека, один человек уходит – начинаются проблемы, два человека уходят – встает операционная деятельность.
2. Купить готовое решение (Saas, Saap, Oracle). Но, как только вы пытаетесь заточить программное решение под себя, это становится очень долго, дорого, не все могут себе это позволить.
3. Купить какую-либо аналитическую платформу и самим делать модели. Вариантов на рынке много.

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

По затратам: наиболее затратные либо готовые решения, либо язык программирования.

Мы решили покупать аналитическую платформу и писать алгоритмы под себя с учетом специфики продаж конкретно.

Мы определились, что будем брать аналитическую платформу. Теперь нужно было выбрать, какую. Было четыре варианта на рассмотрении. Первые две: RapidMiner и IBM SPSS. Они являются лидерами рынка в этом направлении. В них огромное количество готовых компонент. Программы достаточно устойчивые, известные, стабильные, решают большой спектр задач. Loginom - новый продукт, его пока никто не знает, отзывов мало.

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

Но есть ещё KNIME - «открытая», бесплатная платформа. Почему бы не выбрать ее?! Но при анализе возникли следующие проблемы: программа громоздкая, количество компонент зашкаливает, интерфейс не достаточно удобен.

Поэтому остановились на Loginom.

Внедрение Loginom

Теперь немножко о внедрении. Я бы разбил на два больших блока:

1. Интеграция Loginom с текущими информационными системами, которые есть в компании.
2. Написание сценариев, моделей в Loginom.

Какие плюсы можно назвать при работе Loginom и его интеграции с текущими информационными системами:

• Достаточно простая установка и обновление версий. За все это время мы обновлялись до каждой новой версии в один клик, и никогда никаких проблем не было. В этом плане очень удобно.
• Удобный коннект с различными источниками данных - база данных, Excel, xml, Web Services, всё что угодно - настраивается достаточно просто, быстро, и проблем не возникало.

Однако Loginom - платформа аналитическая, обычные юзеры с ней не работают. Любая модель требует ввода параметров. Где вводить эти параметры? Логично, что в текущей ERP-системе, которая у вас сейчас есть.

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

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

• Очень порадовала скорость обработки данных. В первом зале уже поднимали вопрос: какой объем обрабатывается? Это, действительно, порядка 50-100 млн строк для стандартных кейсов. У нас, примерно, так и есть. Самое большое, что мы загружали в систему - это 80 Гб текст, есть порядка 100 млн строк. В принципе, считывание самого файла занимало 5 минут. Последующая обработка происходила достаточно быстро. На текущий момент для обработки 60 магазинов, если я не ошибаюсь, при ассортименте в 50 тыс. товаров, весь скрипт отрабатывает за 20 минут. То есть, очень быстро, не надо ждать часами - очень позитивный момент.

Если говорить о минусах, то на текущий момент Loginom немножко отстаёт от RapidMiner и IBM SPSS по количеству компонент. Хотелось бы видеть чуть больше аналитических функций, чуть больше компонент. Но, как уже говорил предыдущий докладчик, что в ближайшее время все должно быть реализовано. Набор необходимых модулей уже будет в Loginom, соответственно, можно будет пользоваться большими возможностями.

Сложности при написании сценариев

Сложности, которые возникали у нас в процессе написания сценариев. Писали сами, писали аналитики:

1. Изначальное разбиение на подмодели. Проблема в том, что прежде чем приступить к написанию какого-либо сценария, нужно сразу обозначить подмодели, либо логические блоки, которые у вас будут использоваться в сценарии. Если этого изначально не сделать, то можно зайти в небольшой тупик. Вы начинаете «накидывать» какие-то компоненты в сценарии, понимаете, что они у вас просто не вмещаются на экран, модель становится сложночитаемой. Поэтому приходится создавать подмодель и «запихивать» всё то же самое, что только что написали в эту подмодель. Копирования, к сожалению, на данный момент нет. Возможно, в версии 6.2 оно появится, тогда эта проблема устранится. Но, когда, условно, ты тратишь 2 часа на написание какого-то небольшого куска сценария, а потом понимаешь, что тебе это нужно опять переписывать – это, конечно, не очень удобно.
2. Работа с циклами. Это не проблема, но это очень непривычно. Если вы, например, бывший разработчик, то с циклами всё понятно - написал IF, далее FOR, WHILE, - все, что угодно пишешь. Здесь - визуальное проектирование, цикл – это отдельный компонент, и как только вы начинаете делать какую-то модель с циклами, количество взаимосвязей на экране, то есть «стрелочек» увеличивается в 2-3 раза. Потому что нужно подать набор данных как на основную вашу подмодель, также и на компоненты цикла. Если это какие-то внешние итерационные переменные, то это дополнительные данные, которые немного мешают восприятию модели на экране. Но к этому можно привыкнуть, мы к этому привыкли, в принципе, сейчас работаем с этим без проблем.
3. Запуск сценария по расписанию. Не все скрипты могут работать в интерактивном режиме. То есть зашел - нажал кнопочку. Хочется, чтобы, условно, в 5 утра, в 10 утра, в 3 дня сценарий запускался автоматически, без участия аналитика, т.к. всё-таки мы автоматизацией занимаемся, поэтому лучше максимально исключить человеческий ресурс. Но у нас возникли проблемы – при достаточно сложных сценариях, в которых есть множество вложенных циклов и параллельных обработок данных – сценарии периодически зависают. Это происходит не всегда, но периодически такое бывает. Мы сейчас с техподдержкой эту проблему пытаемся решить, частично решили, и, насколько я понимаю в следующем же патче – 6.1.3, это проблема должна быть устраниться, и, соответственно, всё должно быть хорошо. Если сценарий простой, то он отрабатывает хорошо, если сценарий какой-то сложный – могут возникать какие-то задержки.
4. Чем больше данных вы обрабатываете, тем больше памяти вы тратите. Если сценарии очень тяжёлые, если они параллельно начинают запускаться, у вас просто может не хватить оперативной памяти. Об этом стоит помнить. Сейчас у нас запущено, по-моему, 32 Гб, максимально, что мы можем сделать, если я не ошибаюсь. В принципе, нам этого хватает, но, если еще пару тяжелых сценариев туда включить, наверное, памяти будет переставать хватать. Как коллеги мне говорили, есть расширенные версии софта, где есть или нет ограничения по памяти, в зависимости от той вариации, которую вы собираетесь приобрести.

Оценка результатов

На старте проекта было выбрано две метрики – это уровень сервиса по товарным остаткам и уровень подзаказа.

Первая метрика нам говорила о том, насколько хорошо мы можем обеспечить товаром все наши магазины, есть ли у нас Out-Of-Stock (прим. «отсутствие в запасе»), всегда ли достаточно нужных товаров лежит в магазинах. Мы, примерно, подняли этот уровень на 5%, считаем, что это достаточно неплохой результат. Если видеть на графике, то есть резкий рост, потом плюс-минус идет некая стабильность.

Вторая метрика – это уровень клиентского подзаказа, по сути, это не совсем то же самое, но близкое к этому. Насколько мы можем обеспечить нужный ассортимент в магазинах, для того, чтобы клиент его мог купить здесь и сейчас. Ему не приходится ждать доставку, условно, два-три дня, неделя, клиент просто может уйти к конкуренту и купить у него. Соответственно, этот показатель нужно снижать.

График нам показывает снижение уровня подзаказа – результат хороший, поэтому, условно, проект считался успешно внедренным.

Дальнейшее развитие

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

• изменилась структура продаж,
• вводим такой-то новый ассортимент,
• изменение рынка.

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

Если говорить про ситуацию с IT, мы получаем всё тоже самую историю, когда очередь огромная, разработка идет год, - это неприемлемо. При покупке Loginom мы от этого ушли. Потому что сценарий пишет не программист, сценарий пишет аналитик.

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

О проекте

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

Состав группы проекта - 5 должностей. В данном случае, - заказчик, менеджер проекта, аналитик-консультант ERP. В нашем случае, менеджер проекта и аналитик – это было одно лицо, соответственно, потребовалось 4 человека на реализацию всего этого проекта.

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