У розничной сети бытовой техники и электроники «МИР» весьма серьезные и долгосрочные планы в отношении построения процессов управления ассортиментом и внедрения технологий автоматизации для данного класса задач. Сегодня уже реализованы некоторые задачи в части повышения эффективности складской логистики и распределения товаров. О том, как это происходило, мы беседуем с топ-менеджерами компании «МИР» — ИТ‑директором Алексеем Лымарем и директором по поставкам Николаем Водолазским.

Intelligent Enterprise: В чем заключались основные проблемы до того, как в компании было развернуто новое решение?

Алексей Лымарь: Чтобы картина была более полной, действительно надо сначала рассказать, как мы работали до того, как стали внедрять централизованные информационные бизнес‑системы. Процесс строился следующим образом. Почти каждую ночь группа специалистов, имея относительно достоверные данные о состоянии центрального распределительного центра и региональных складов, формировала подвоз товаров в магазины. Исходные данные для этого заключались в информации о наличии товара на складах, в магазинах и о товаре, который уже в пути. Методика определения потребности того или иного логистического объекта была упрощенной и в большей степени эмпирической, что, по сути, определялось имеющимися программными средствами: техническое оснащение на центральном складе ограничивалось мониторами с большой диагональю (по тем временам и это было роскошью), на которых, по крайней мере, хорошо отображались длинные ряды цифр, отражающие относительно верные исходные данные.

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

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

Каким образом эти вопросы были решены?

Алексей Лымарь: Базовой платформой прикладной информационной поддержки стала SAP ERP, и если формально отвечать на поставленный вопрос, можно сказать, что все получилось за счет ресурсов этой же системы. Однако упомянутые проблемы были решены принципиально разными инструментами.

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

Другая ситуация сложилась с автоматизацией процессов распределения. Мы принимали решение о приобретении системы SAP, исходя из рекомендаций поставщика и его консультантов, которые уверяли, что на основе их системы мы реализуем все ключевые бизнес-операции. На практике же все оказалось не совсем так. Тщательный анализ стандартных возможностей системы показал, что они не совпадают с потребностями нашего бизнеса, и для решения этой проблемы нам пришлось привлекать дополнительную консалтинговую компанию, специалисты которой глубже разбирались в тех бизнес-процессах, которые предстояло автоматизировать. Совместными усилиями консультантов, сотрудников бизнес-подразделений компании, ИТ‑специалистов был проведен анализ уже реализованных подходов к решению задачи распределения и возможностей ряда программных продуктов. В результате сформировалось концептуальное описание подхода к решению задачи.

Учитывая, что система SAP была и остается нашей стратегической платформой, а также то, что в рамках первого этапа уже обеспечивалось наличие в SAP на постоянной основе и в реальном времени всех исходных данных, необходимых для решения задачи, мы приняли решение реализовывать проект в рамках SAP. Хотелось бы подчеркнуть, что, говоря об использовании ABAP в SAP-проектах (а этот инструмент используют нередко), могут подразумевать и написание отчетности, и создание новых функций ИТ-поддержки, и интеграционные решения, а иногда и все вместе. Так вот, в нашем случае речь идет о создании прикладного решения в области распределения товаров с нуля.

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

Что можно сказать о тех алгоритмах, которые в конце концов легли в основу ИТ-решения? Как они создавались, и на чем тут делались основные акценты?

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

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

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

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

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

Что касается возможностей применения данных алгоритмов, то здесь имеется в виду достаточно серьезный уровень логистических задач. То есть это уровень оперативного планирования товарных потоков, в котором по крайней мере задействованы центральный распределительный центр, несколько смежных с ним региональных складов и множество магазинов. Фактически это уровень логистики региона, не меньше. Создавать такое решение для схемы «склад — несколько магазинов» не имеет никакого смысла. А значит, бессмысленно и тестировать его на подобной конфигурации.

Какую специфику в решении, построенном именно для вашего бизнеса, вы бы отметили?

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

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

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

Алексей Лымарь: Во-первых, еще раз подчеркну, что мы решали две смежные задачи: получение точной информационной картины состояния наших запасов по всей складской инфраструктуре и автоматизации потоков распределения товаров. Они связаны в очень значительной степени — первая без второй имеет мало практического смысла, а вторая просто не решается без решения первой. Но в данном случае в отношении бизнес-процессов входной точкой выступает центральный распределительный склад, а выходной — ворота магазина. Конечно же, это некоторое упрощение. Внутри магазина процессы товародвижения продолжаются вплоть до покупки товара потребителем. Однако здесь все задачи автоматизации давно нами решены в рамках информационной системы магазина, интегрированной, как уже было сказано, с SAP.

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

А решение, о котором я рассказывал выше, тоже будет развиваться. Что‑то потребуется в большей степени, что‑то в меньшей. Согласно нашим принципам построения бизнеса, думаю, в меньшей степени будут нужны процессы обратной логистики, равно как и соответствующие инструменты автоматизации, хотя таковые и существуют. Мы считаем, что товар, прибыв в магазин, должен быть продан там же (пусть в некоторых случаях и с уценкой), а не возвращаться на склад или путешествовать в другую торговую точку.

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