Размерный ряд в учёте швейного цеха: 1 модель = 18 SKU

Закройщица приносит мастеру таблицу: «толстовка худи базовая — 120 штук в работе». На эту строку считают расход футера, заказывают молнии у поставщика, обещают маркетплейсу отгрузку к среде. А через три недели менеджер бежит к технологу: «WB просит 30 штук размера M в антраците, у нас в остатках 12, на сборке шесть. Где остальные?». Открывают тетрадь — «осталось около сорока». Каких размеров — никто точно не знает, потому что считали худи одной строкой, без разбивки.

Толстовка — это не одна строка остатка. Это 18 строк: три цвета × шесть размеров. Дальше — почему ваш Excel врёт про остатки, как ловить дефицит размеров за пять секунд, а не в момент упаковки, и как размерную матрицу автоматически разводит на отдельные позиции MRP-система.

Без терминологии ради терминологии — на примере одной толстовки, шести размеров и трёх цветов. Цифры везде реальные, такими их видит маленький цех, который пошёл на WB и через два месяца понял, что Excel не справляется.

Почему размерный ряд взрывает Excel

В классической карточке товара «Толстовка худи базовая» в табличке остатков обычно стоит одно число. Это удобно для бухгалтерии и для собственника, который раз в неделю смотрит «сколько у нас всего». Но швейный цех живёт другой задачей: ему нужно понимать остаток по каждой комбинации размер × цвет × модель.

Причины три:

1. Клиент покупает конкретный размер. Маркетплейс, шоурум, оптовик — никому не нужно «толстовка вообще». Нужен M-чёрный или L-беж. Если в остатках 50 худи, но из них ни одной L, продать ничего нельзя.
2. Размеры расходуются неравномерно. S и XL обычно «висят», M и L уходят первыми. Через две недели «средние» закончились, а на складе формально полсотни штук — но всё S, XS и XXL.
3. Раскладка ткани разная. На XL расходуется на 12–18% больше ткани, чем на S. Если планировать партию «120 худи», не зная разбивки по размерам, расход ткани улетает на 5–10% в любую сторону.

Excel-таблица «одна строка на модель» эти три задачи не решает. Чтобы решить, нужно либо разнести модель на много строк (по строке на каждый SKU), либо завести вторую таблицу-матрицу — и эти две таблицы синхронизировать вручную. И там, и там через месяц работы данные расходятся.

Пример: толстовка → 6 размеров × 3 цвета = 18 SKU

Возьмём базовую женскую толстовку худи. Цех шьёт её в трёх цветах:

• чёрный
• антрацит
• молочный

И в шести размерах:

• XS, S, M, L, XL, XXL

Это даёт 18 уникальных учётных позиций — 18 разных SKU. Каждая позиция — это:

• свой остаток на складе
• своя цена закупки (себестоимость зависит от размера: разный расход ткани и фурнитуры)
• своя статистика продаж и оборачиваемости
• свой план производства
• свой штрихкод и карточка на маркетплейсе

Цвет / Размер	XS	S	M	L	XL	XXL
Чёрный	SKU-001	SKU-002	SKU-003	SKU-004	SKU-005	SKU-006
Антрацит	SKU-007	SKU-008	SKU-009	SKU-010	SKU-011	SKU-012
Молочный	SKU-013	SKU-014	SKU-015	SKU-016	SKU-017	SKU-018

Это базовая модель. Если завтра добавится четвёртый цвет (например, оливковый) — это +6 SKU, итого 24. Если добавится размер 3XL — это +3 SKU (один на каждый цвет), итого 21. Реальные цеха с десятью моделями толстовок, футболок и брюк легко получают 200–600 SKU только по верхней одежде.

Формула простая, но эффект мультипликативный. Шить три модели по три цвета по шесть размеров — это не «3 номенклатуры» и не «9 артикулов», а 54 уникальные позиции, каждая со своим остатком, своей раскладкой ткани, своим штрихкодом для WB. Дальше — два важных следствия.

Главная ошибка ателье, переходящего в формат «маленький цех под маркетплейсы», — продолжать считать в карточках моделей. К моменту, когда менеджер начинает физически путаться, в учёте уже хаос на месяцы назад: непонятно, какой остаток реален, и любая инвентаризация выявляет минус-плюс 15–30% по конкретным позициям.

Остатки по каждому SKU: как не узнать об «исчезновении» 42-го в момент отгрузки

Сценарий из жизни. Цех договаривается с локальным шоурумом на поставку 40 худи: по 8 штук каждого размера, цвет «антрацит». Менеджер смотрит в общую таблицу: «антрацит, остаток 53». Подтверждает заказ, обещает отгрузить в среду.

В среду упаковщица достаёт антрацитовые худи с полки — и быстро становится видно, что:

• M — 14 шт (хорошо)
• L — 17 шт (хорошо)
• S — 11 шт (норм)
• XL — 6 шт (мало на 2)
• XS — 4 шт (мало на 4)
• XXL — 1 шт (катастрофа)

В итоге шоуруму уезжает 32 толстовки вместо 40, менеджер звонит, извиняется, договаривается на «допоставку через две недели». Цех в спешке ставит в план срочный раскрой XS и XXL — и они идут поверх уже запланированных партий, ломая график другим заказам и расход ткани.

Источник проблемы — не в скорости упаковки. Источник в том, что в момент подтверждения заказа менеджер видел агрегат, а не матрицу. Цифра «53» была математически верной, но операционно бесполезной: она не отвечала на вопрос «можем ли мы отгрузить 8×8 матрицу размеров».

Правильный учёт остатка по SKU отвечает на этот вопрос за пять секунд:

• запрос: «есть ли 8 шт по каждому размеру в антраците?»
• ответ: «по M, L, S — да; по XS — нет (4 из 8); по XL — нет (6 из 8); по XXL — нет (1 из 8). Дефицит: 13 шт».

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

Почему именно маркетплейс ловит дефицит размеров жёстче всего

Шоурум и оптовик прощают «допоставку через две недели» — устно договорились, поехали дальше. Маркетплейс не прощает. Wildberries и Ozon работают по карточке товара = одна карточка на каждый SKU (комбинация модель + цвет + размер), и обещанные остатки сверяет автоматически:

• Если в карточке стояло «6 шт XL антрацит», а в коробке упаковщица собрала 2 шт — заказ закрывается недокомплектом, маркетплейс начисляет штраф (от 1500 ₽ за позицию у WB).
• Если по карточке стояло «0», а покупатель её всё-таки заказал из остатков FBO-склада — продаётся то, что физически лежит на складе маркетплейса. Карточка обновляется не в реальном времени, и в момент покупки склад может быть уже пуст.
• Возврат «не подошёл размер» приходит обратно на ваш SKU. Если вы вели учёт по модели, а не по размеру, его уже некуда «положить»: технически в Excel позиция одна, физически коробок шесть, и они не складываются обратно правильно.

Подробно про экономику маркетплейс-возвратов — в материале «Возвраты на маркетплейсах: учёт, перепродажа, снижение»: там разобраны причины и стоимость, и больше половины из них упирается именно в нехватку размеров на FBO-складе. Если выбираете между FBO и FBS-схемой, отдельный разбор юнит-экономики и остатков — «Маркетплейсы для крафта: FBO vs FBS vs DBS».

Главная разница между шоурумом и WB — куда падает риск:

• В шоуруме риск падает на менеджера: «извинились, договорились на допоставку».
• На WB риск падает в деньги: штраф + потерянный slot отгрузки + рейтинг продавца. И всё это автоматически, без шанса «договориться».

Поэтому переход в маркетплейс — это та точка, в которой Excel с одной строкой на модель ломается окончательно. Цеху нужно либо начать вести 18 строк руками (и синхронизировать их между складом, маркетплейсом и менеджером), либо завести учёт, который сам разводит модель на матрицу.

Как MRP-система управляет размерной матрицей

В MRP-системе для швейного цеха карточка «толстовка худи базовая» — это не одна номенклатура, а модель с атрибутами-вариантами. Атрибуты — размер и цвет (для других категорий могут быть длина рукава, посадка, артикул ткани). Каждая комбинация атрибутов автоматически даёт отдельный SKU, у которого свои:

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

Когда менеджер заводит заказ покупателя на «толстовка худи антрацит, 8×8 матрица размеров», система:

1. Резервирует 8 шт по каждому SKU отдельно (не одной строкой на 48 шт).
2. Сразу показывает дефицит — какие именно SKU нельзя зарезервировать целиком (XS: 4 из 8, XL: 6 из 8, XXL: 1 из 8).
3. Предлагает создать производственный заказ только на недостающие 13 шт по конкретным размерам и цвету — не на 48 шт «партии» и не на 6 шт XS «всех цветов», а ровно XS-антрацит 4 шт, XL-антрацит 2 шт, XXL-антрацит 7 шт (последнее с учётом минимального остатка после отгрузки).
4. Сообщает технологу расход ткани с учётом раскладки конкретно этих размеров — а не среднее по модели.

Сборка планируется не от модели целиком, а от конкретных SKU. Это позволяет складывать в одну партию раскроя несколько маленьких заказов от разных покупателей по тем же размерам — то, что цеха старого формата делают в голове и регулярно ошибаются. О том, как такую сборку планировать вручную, мы писали в материале «Как составить график пошива на одну швею при нескольких заказах» — там же объяснено, почему сводить заказы по размеру выгоднее, чем шить «строго по очереди клиентов».

Что должна уметь карточка модели в MRP

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

• Матрица размер × цвет в одной карточке (а не 18 отдельных карточек, заведённых руками)
• Норматив расхода ткани в формате «базовый расход на M + поправочный коэффициент на размер» (например, XS = −10%, S = −5%, M = 0%, L = +6%, XL = +12%, XXL = +18%)

• Шаблон фурнитуры на модель — одинаковая для всех размеров (молния, шнурок, бирка) считается на штуку, не на партию
• Минимальный остаток в разрезе SKU, а не модели (для XS можно держать минимум 6 шт, для M — 20 шт)
• Себестоимость по SKU — пересчитывается автоматически из стоимости ткани/фурнитуры × расход на конкретный размер

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

Реальный кейс-пример расчёта

Цех получает заказ от маркетплейса:

• 10 шт XS-чёрный
• 25 шт S-чёрный
• 40 шт M-чёрный
• 35 шт L-чёрный
• 18 шт XL-чёрный
• 5 шт XXL-чёрный

Итого 133 шт чёрной толстовки в шести размерах. Если бы цех планировал «партия 133 шт чёрного худи», расход ткани он считал бы по средней раскладке на M и закупил бы условно 133 × 1,7 м = 226 м ткани.

Реальный расход с учётом размерной матрицы:

Размер	Кол-во	Расход на шт, м	Итого, м
XS	10	1,53	15,3
S	25	1,62	40,5
M	40	1,70	68,0
L	35	1,80	63,0
XL	18	1,90	34,2
XXL	5	2,00	10,0
Итого	133		231,0

Разница — 5 метров. Кажется немного, но при цене футера 380 ₽/м это +1 900 ₽ к закупке. На партии в 500 шт ошибка раздуется до 7–10 тысяч рублей, а если ткань пришла «впритык» по средней — на двух последних XXL её просто физически не хватит, и партия встанет за 12 метрами антрацита.

Второй сценарий: цех планирует следующую закупку ткани под месячный план. План складывается из истории продаж конкретных SKU, не из «продали 400 худи». MRP-система видит:

• XS-чёрный продаётся в среднем 8 шт/мес → план на следующий месяц 10 шт (запас +25%)
• M-чёрный продаётся 45 шт/мес → план 55 шт
• XXL-чёрный продаётся 3 шт/мес → план 4 шт

И так по каждому из 18 SKU. Сложив, получает реалистичный объём раскроя и точную потребность в ткани — без перезакупки на «всякий случай» и без дефицита по средним размерам. О том, как пересчитать график раскроя в случае задержки ткани от поставщика, мы писали отдельно — «Что делать, когда ткань встала на таможне».

Что забрать из статьи

• Одна модель в швейном цехе — это не одна учётная позиция, а десяток-другой SKU (комбинации размер × цвет). Без этой разбивки невозможно достоверно ответить на вопрос «что у нас на остатке».
• Общий остаток по модели маскирует дефицит по конкретным размерам. Менеджер узнаёт о нём в момент отгрузки, и каждый такой случай — это срыв договорённости с клиентом плюс срочный незапланированный раскрой.
• MRP-система разводит модель на SKU автоматически — через матрицу атрибутов в одной карточке. Каждый SKU получает свой остаток, минимальный запас, себестоимость и норматив расхода ткани с поправочным коэффициентом на размер.
• На партии в сотню штук точный учёт по SKU экономит 5–10% ткани и убирает аврал из-за «вдруг закончился 42-й».

Если ведёте швейный цех или ателье под маркетплейсы — посмотрите страницу Zolotenkov MRP для швейного цеха. Расскажем, как уже сегодня вести учёт по моделям с вариантами, какие куски размерной матрицы автоматизируем в первую очередь под ваш ассортимент и как состыковать остатки по SKU с выгрузкой на WB и Ozon, чтобы дефицит размеров ловился до того, как маркетплейс выставил штраф.