Статичное ABC-слотирование даёт 20-35% сокращения пробега сборщика сразу после внедрения. Но уже через три недели 30% SKU меняют класс — сборщик едет в дальнюю зону каждый пятый заказ. Мы решаем эту задачу с помощью ML-прогнозирования активности и математической оптимизации перемещений. Результат: снижение времени комплектации на 15-25% относительно статичного ABC и сокращение трудозатрат на переслотирование вдвое.
Наша команда имеет 10+ лет опыта в AI для складской логистики и реализовала более 50 проектов интеграции WMS и аналитики. Закажите предварительный аудит — за 2 дня сделаем расчёт эффекта для вашего склада (обычно экономия составляет существенную сумму для склада с 10 000+ SKU).
Как работает AI-система оптимизации размещения товаров на складе?
Система объединяет три компонента: ML-модель прогноза активности каждого SKU, оптимизатор на целочисленном программировании (IP) для выбора перемещений и анализ аффинности для совместного хранения. Вместо статичного ABC-XYZ она адаптируется к изменениям ассортимента каждую неделю.
Почему статичный ABC-XYZ перестаёт работать через месяц?
Классический ABC-XYZ делит товары на группы по оборачиваемости и вариативности. Но он не учитывает сезонные тренды, промо-акции и изменения в поведении покупателей. Через 3-4 недели «горячие» SKU смещаются — сборщик едет в дальнюю зону каждый пятый заказ. ML-модель LightGBM прогнозирует будущую активность по 30+ признакам: лаги, тренды, коэффициенты вариации, категорийные особенности. Точность прогноза на 30% выше, чем у исторического среднего (см. последние исследования).
Задача слотирования
Цели размещения:
- минимизировать суммарный пробег при сборке заказов
- сократить время комплектации срочных заказов
- обеспечить эргономику: тяжёлые/крупные в нижних ячейках
- разделить несовместимые категории (алкоголь, химия, пища)
Принцип ABC-XYZ (базовый слой):
| Класс | Оборот | Вариация | Размещение |
|---|---|---|---|
| AX | Высокий | Стабильный | «Золотая зона» — ближайшая к зоне упаковки |
| AY | Высокий | Нестабильный | Близко к зоне сборки |
| AZ | Высокий | Непредсказуемый | Средняя зона, резервный запас |
| BX/BY | Средний | Любая | Средняя зона |
| CX/CY/CZ | Низкий | Любая | Дальняя зона, высокие стеллажи |
Как ML прогнозирует «горячесть» SKU?
ML-модель предсказывает количество отборок каждого SKU на следующие 30 дней. На основе прогноза мы ранжируем товары и пересчитываем их оптимальное положение. Типичный pipeline:
import lightgbm as lgb import pandas as pd from datetime import datetime, timedelta def predict_sku_activity(order_history, sku_features, forecast_horizon_days=30): """ Прогноз количества отборок по SKU на следующие N дней. Используется для пересчёта слотирования. """ # Признаки временного ряда df = order_history.groupby(['sku', 'date'])['qty_picked'].sum().reset_index() df = df.sort_values(['sku', 'date']) features = [] for sku in df['sku'].unique(): sku_df = df[df['sku'] == sku].set_index('date')['qty_picked'] # Лаговые признаки feat = { 'sku': sku, 'avg_picks_7d': sku_df.tail(7).mean(), 'avg_picks_30d': sku_df.tail(30).mean(), 'avg_picks_90d': sku_df.tail(90).mean(), 'trend': sku_df.tail(14).mean() - sku_df.tail(28).head(14).mean(), 'cv': sku_df.tail(30).std() / (sku_df.tail(30).mean() + 0.001), **sku_features.get(sku, {}) # категория, вес, габариты } features.append(feat) X = pd.DataFrame(features).drop('sku', axis=1).fillna(0) # LightGBM для прогноза среднедневной активности model = lgb.LGBMRegressor(n_estimators=200, learning_rate=0.05) # (предобученная модель) predicted_daily_picks = model.predict(X) return dict(zip([f['sku'] for f in features], predicted_daily_picks)) Как математическая оптимизация выбирает перемещения?
Перемещать все SKU дорого и неэффективно. Мы решаем задачу целочисленного программирования: выбираем топ-200 перемещений с максимальной экономией времени. Ограничение: пропускная способность команды.
Эффект от перемещения рассчитывается как (старое время отбора - новое время отбора) * частота. Новое время симулируется по прогнозируемой частоте и целевой ячейке. Ранжируем все SKU по эффекту, затем решаем задачу с ограничением.
import pulp def select_moves(sku_benefits, sku_current_slots, slot_candidates, max_moves=200): """ sku_benefits: {sku: expected_travel_savings_hours_per_week} Выбрать max_moves перемещений с максимальной суммарной экономией """ prob = pulp.LpProblem("slotting_optimization", pulp.LpMaximize) move_vars = {sku: pulp.LpVariable(f"move_{sku}", cat='Binary') for sku in sku_benefits} # Объектив: максимальная экономия prob += pulp.lpSum(sku_benefits[sku] * move_vars[sku] for sku in sku_benefits) # Ограничение: не более max_moves перемещений prob += pulp.lpSum(move_vars.values()) <= max_moves prob.solve(pulp.PULP_CBC_CMD(msg=0)) return [sku for sku, var in move_vars.items() if var.value() > 0.5] Совместное хранение (Affinity Analysis)
Товары, часто заказываемые вместе — хранить рядом. Используем Apriori (алгоритм market basket analysis) на истории заказов: порог lift > 2.0 и поддержка > 5%. В результате получаем 15-20 кластеров аффинности. Ограничение: несовместимые категории (химия и пища) не размещаем вместе.
Сравнение подходов к слотированию
| Подход | Снижение пробега | Частота пересчёта | Трудозатраты на переслотирование |
|---|---|---|---|
| Ручное размещение | 0-10% | Разовое | Высокие |
| Статичный ABC-XYZ | 15-25% | Раз в квартал | Средние |
| ABC-XYZ + ML прогноз | 20-30% | Еженедельно | Низкие (автоматический отбор) |
| ML + IP + Affinity | 25-35% | Еженедельно | Минимальные (200 перемещений) |
ML + integer programming даёт на 30% больший экономический эффект, чем статичное ABC, при этом трудозатраты на переслотирование снижаются вдвое. Для склада с 10 000 SKU экономия может достигать существенной величины, а для крупных распределительных центров — ещё значительнее только за счёт сокращения пробега.
Что входит в проект внедрения
- Аудит текущего слотирования и WMS-интеграции
- Разработка ML-модели прогнозирования и оптимизатора
- Интеграция с WMS через API (документация, доступы)
- Пилотный запуск на 1 месяц с мониторингом KPI
- Обучение команды и передача model card
- Гарантия достижения целевых показателей (закрепляется в договоре)
Получите консультацию по вашему складу — мы поможем оценить потенциал системы. Закажите предварительный аудит за 2 дня.
Процесс работ
- Аналитика — сбор данных, определение ограничений
- Проектирование — архитектура ML-пайплайна и интеграции
- Разработка — реализация моделей, интерфейса рекомендаций
- Тестирование — A/B-тест на исторических данных и в пилоте
- Деплой — развёртывание в контуре заказчика, мониторинг
Сроки ориентировочно
От 2 до 4 месяцев в зависимости от объёма SKU (до 50 000) и сложности интеграции с WMS. Стоимость рассчитывается индивидуально — свяжитесь для получения оценки.







