Принимаем проекты на I полугодие 2027 · 2026 sold out МСК · UTC+3 · 09:00-20:00
Все материалы Playbook
PB-01 · Playbook WMS · Distribution Center Lamoda · 2012-2014 · 18 мин чтения

Lamoda WMS: storno report
с 0,18% до 0,0008%.

Distribution center Class-A на 68 000 м² (сегодня этот DC вырос до 200 000 м²), команда склада в пик четыре смены по 750 человек, hyper-growth fashion e-commerce от Rocket Internet. Пришёл в core operations team в феврале 2012, Head of Operations DC. К концу 2014 года storno report снижен в 225 раз: с 0,18% до 0,0008%.

  • // storno report0,0008%было 0,18% · −225×
  • // команда3 000в пик, четыре смены по 750
  • // DC68 000 м²Class-A · с пустого бетона
  • // срок18 месс диагноза до стабилизации
// Контекст

Февраль 2012. Lamoda, fashion e-commerce от Rocket Internet, два года после запуска, hyper-growth: каждый квартал ассортимент растёт на десятки процентов, sales удваивается, склад захлёбывается. Я пришёл в core operations team как Head of Operations DC, мандат: навести порядок в качестве операций склада, который рос быстрее своих процессов. Дашбордов на старте не было. Главной метрикой качества работы склада через год стал storno report, и на старте замера он показывал 0,18%.

0,18% не звучит много, но за этой цифрой стояли ошибки на приёмке, при подборе, при отгрузке и в учёте ассортимента. У каждой категории было своё объяснение и своя хозяйственная природа, и это была первая проблема.

Диагноз · первые 30 дней

Четыре гипотезы. Пятая оказалась правильной.

  1. Гипотеза 1 (неверная)

    «Воруют, нужна security»

    Классический impulse. Усилить охрану, поставить камеры, ввести металлодетекторы. Цифры показали: прямых хищений было около 0,02%, десятая часть проблемы. Усиление security съело бы бюджет и убило бы темп команды без эффекта на главные 0,16%.

  2. Гипотеза 2 (неверная)

    «WMS-баги, нужна новая система»

    Manhattan WMS показывал странные расхождения. Vendor предлагал апгрейд за серьёзные деньги. Но при глубоком разборе оказалось, баги были не системные, а конфигурационные: некорректные правила скана, неправильные validation rules. Это уже §2 ниже, Интервенция #2.

  3. Гипотеза 3 (неверная)

    «Подборщики ошибаются, нужны штрафы»

    Ввести штрафы за ошибки. Стандартный подход. Просчитал: при текущей плотности ошибок штрафы съели бы 15-20% зарплаты, и подборщики просто разбежались бы. Hyper-growth, дефицит кадров, конкуренция за линейный персонал в Москве, это бы убило операции.

  4. Гипотеза 4 (неверная)

    «Нужны новые KPI для shift managers»

    Поменять метрики смен-менеджеров. Сделали это, оказалось малозначимо без изменения базовой топологии и incentive system. Метрики без поведенческой основы, просто отчётность.

  5. Гипотеза 5 (правильная)

    «Это композитная проблема, нужны 5 интервенций, не одна»

    Через 4 недели стало ясно: 0,18% по storno report, это не одна причина, а пять связанных. Топология DC давала ошибки на подборе. WMS-конфигурация маскировала эти ошибки. Incentive system наказывала за признание ошибок. Data layer не отслеживал паттерн. Культура передавала ошибки как «допустимый шум». Нужно было работать со всеми пятью одновременно, иначе каждая отдельная интервенция давала бы временный эффект, а потом откатывалась.

5 интервенций · 18 месяцев

Что мы реально сделали.

  1. #1 · нед. 5-16

    Топология DC: ABC по weight × velocity

    Перерисовали зоны хранения по матрице (вес × оборачиваемость). Тяжёлые быстрые SKU, на низких ярусах рядом со shipping. Лёгкие медленные, на высоких. Это сократило средний путь подборщика на 22% и физическую усталость в смене, что напрямую влияло на ошибки.

    Эффект на storno report: −0,04% за 3 месяца. Не дотягивает до главной цели, но даёт momentum.

  2. #2 · нед. 8-24

    WMS-конфигурация: правила скана и валидация

    Manhattan WMS работал, но в 60% случаев показывал false positive на «расхождения», которые потом оказывались процессными. Переконфигурировали 23 правила скана: добавили двойную сверку для weight-mismatch, ввели mandatory rescan при отклонении более 5%, убрали auto-correction в местах, где она маскировала проблемы.

    Эффект: −0,03% по storno report, плюс резко улучшилась visibility, мы стали видеть проблемы вместо того чтобы их «считать решёнными» автоматически.

  3. #3 · нед. 12-36

    Incentive system: с production на quality

    Самая сложная интервенция. Подборщики получали бонусы за производительность (units/час). Это давало стимул прятать ошибки. Перешли на двухосный KPI: производительность × точность. Подборщик с 95% точностью и средней производительностью получал больше, чем с 92% точностью и высокой.

    Первые 60 дней, падение производительности на 8%, рост вычитания заработка у 30% персонала, недовольство, увольнения. Через 90 дней, восстановление производительности и снижение потерь на 0,06%. Через 6 месяцев, рост производительности выше старого уровня и потери ниже целевых.

  4. #4 · нед. 16-40

    Data layer: real-time dashboards для смен

    До этого supervisors видели агрегированные данные за вчера. Поставили real-time экраны в зоны подбора: смена видит свои текущие точность и производительность, видит лидеров, видит проблемы в моменте. Это убрало пространство для «потом разберёмся», проблема становилась видимой сразу.

    Эффект: −0,03% по storno report дополнительно, плюс серьёзное сокращение времени реакции на отклонения.

  5. #5 · нед. 24-72

    Культура замечаний: «лучше одна лишняя заклёпка»

    Самая нематериальная и самая мощная интервенция. Не штрафы за ошибки, а позитивный contract: «заметил несоответствие, остановись и сообщи, без последствий». Первые 90 дней, рост числа отчётов о расхождениях в 5 раз. Это была паника для финансов: «у нас потери выросли». На самом деле, это были потери, которые раньше прятались. Через 6 месяцев, резкое снижение реальных потерь, потому что проблемы поднимались на поверхность и решались до того, как становились хроническими.

    Эта интервенция дала финальное снижение к 0,0008% и, критически, обеспечила устойчивость результата на годы вперёд.

Результат

Цифры до и после, 18 месяцев.

// февраль 2012 → конец 2014 метрики DC
0,0008%
storno report
было 0,18% · −225×
+22%
picking productivity
после новой топологии + KPI
3 000
человек в команде склада
в пик, четыре смены по 750, без сокращений
unit cost ↓
operational leverage
снижался по мере роста объёма
// Что бы сделал по-другому

1. Начал бы с культуры, а не с топологии. Интервенция #5, самая мощная, но я поставил её пятой. Если бы поставил первой, остальные четыре дали бы эффект быстрее и устойчивее. Просто мы не верили, что культурная интервенция в hyper-growth среде сработает за разумное время.

2. Не пытался бы починить WMS-конфигурацию до конца за один заход. Мы пересмотрели 23 правила, лучше было сделать 8 за первые 60 дней, увидеть эффект, потом ещё 8. Большая порция изменений в WMS дала шум, который мы потом 2 месяца разбирали.

3. Заранее объяснил бы board, что incentive change даст временное падение производительности. 60 дней падение −8%, это нормально, но финансы и sales были недовольны. Я не подготовил «narrative», пришлось защищаться постфактум.

// Применимо ли к вам

Этот кейс применим, если:

1. У вас DC от 30 000 м² с командой 500+ человек

2. Потери склада выше 0,1%, это уже системная проблема, не «шум»

3. WMS стоит, но вы подозреваете что используете его на 40% потенциала

4. Производительность растёт, но точность стагнирует

5. Вы готовы пройти 60-90 дней «turbulence» при изменении incentive system

Если 4+ ответа «да», это полный профиль OP-01 Executive Cohort. Если есть конкретная WMS-миграция в планах, OP-03. Если хотите personalised intervention, IDEAL Services.

Узнайте, применимо ли к вам, 30 минут.

Бесплатный 30-минутный screening call. Расскажете о вашей операционной задаче, скажу, какой формат подойдёт (cohort / retainer / разовый аудит) и подойдёт ли вообще.