10 августа 2026 г. 18:15

Ассортиментное планирование в фешен‑брендах

Источник:

PROfashion

Пока коллекция умещается в одну таблицу, Excel — идеальный инструмент для быстрых раскладок и календарей. Но есть момент, когда электронная таблица перестает быть единственным источником достоверной информации: данные плодятся в чатах, версии путаются, а команда тратит больше времени на сверку цифр, чем на бизнес-процессы. Эксперты платформы Omnidata сформулировали признаки того, что ваш ассортиментный план перерос формат таблицы, и предложили способы предотвратить кризис.

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

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

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

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

Разберем признаки, по которым можно понять, что процессы планирования коллекции и управления ее разработкой переросли Excel.

План есть, но разработка живет отдельно

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

На уровне планирования Excel обычно справляется. Проблемы начинаются позже, когда коллекция переходит в реальную разработку. Дизайнеры, конструкторы, технологи, закупщики, продакты и конфекционеры начинают работать с одними и теми же моделями, но часто в разных файлах. Данные из ассортиментного плана вручную переносятся в рабочие документы с данными по конечному товару, материалам и статусам.

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

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

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

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

Пример классно проработанного плана в excel-таблице, усредненные данные. Его проблема не в некорректном отображении, а в малой связи с последующими этапами разработки.

Что меняется с использованием PLM

В PLM-системе ассортиментный план становится основой для дальнейшей разработки. Из позиции в плане создается карточка модели. С ней дальше работают все участники процесса. В карточке фиксируются ключевые параметры: категория, сезон, дроп, статус, ответственные, сроки, материалы и другие данные.

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

Ассортиментная матрица стала слишком сложной для ручного контроля

Большая таблица сама по себе не проблема. В Excel можно вести и крупные матрицы, если у команды есть понятная структура и правила работы с данными.

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

Руководителю при этом нужно быстро получать ответы на простые вопросы:

Сколько моделей сейчас в разработке?
Какие позиции относятся к конкретному дропу?
Какие категории недоукомплектованы?
Какие модели закреплены за поставщиком?
Что уже согласовано, а что зависло?
Где есть риск срыва сроков?
Какие модели не укладываются в плановую маржинальность/себестоимость?

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

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

В проекте с BUNGLY похожая проблема была связана с планами-графиками, справочниками и аналитикой. Команда вела процессы в Google Таблицах, но при большом количестве участников становилось сложнее контролировать актуальность данных, отслеживать задачи и видеть загрузку команды. Поэтому в пилоте Omnidata. PLM отдельный фокус был на справочниках моделей и модуле ассортиментного планирования.

Дополнительная таблица — материалы по моделям. В каких-то случаях такой сводной таблицы вообще нет, и материалы указываются точечно в каждом файле модели

Что меняется с использованием PLM

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

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

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

Календарный план показывает даты, но не показывает реальность

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

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

Какие задачи уже выполнены?
Какие задачи просрочены?
Как расставлены приоритеты?
У кого накопилась нагрузка?
На каком этапе появилась задержка?
Какая задача блокирует дальнейшую работу?
Где руководителю нужно вмешаться?

Если календарь обновляется вручную, его актуальность зависит от дисциплины команды. Кто-то сразу внес перенос. Кто-то сообщил в чате. Кто-то не обновил статус. Кто-то продолжает работать в своем файле.

Формально календарный план есть. Но управлять по нему становится сложно, потому что он не всегда отражает фактическое движение моделей.

Пример отображения общих статусов одного из наших клиентов. Бывают разные варианты: диаграммы ганта со смещениями, подсвеченные красным даты и так далее. Это не решает главную проблему — непонятно, когда и кем был проставлен такой статус

Что меняется с использованием PLM

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

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

Сводная таблица календарного плана для коллекции SS27.

Статусы и справочники начинают плыть

Когда коллекцию ведет несколько человек, данные постоянно меняются. Это нормальная часть процесса. Уточняются составы, меняются поставщики, корректируются сроки, появляются новые комментарии, модели возвращаются на доработку.

Проблема возникает, когда все эти изменения фиксируются вручную и в разных местах.

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

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

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

В примере таблицы – одинаковые данные записаны в разных терминах, допущены ошибки в названиях и так далее

Что меняется с использованием PLM

В PLM для этого используются единые справочники мастер-данных. Доступ к изменению справочников можно ограничить ответственными сотрудниками. Категории, поставщики, материалы, статусы и другие параметры ведутся централизованно и обновляются в связанных разделах системы.

За счет этого команда работает с одной терминологией и одной актуальной версией данных.

Сотрудник не придумывает данные, статусы и другие переменные. Система сама подсказывает ему, какие варианты доступны и уместны. Проверяющий сотрудник — ответственный за конечный товар — согласует выбранные данные, прежде чем перевести модель на новое состояние.

Накопленные данные сложно использовать повторно

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

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

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

В итоге Excel перестает работать как база знаний. Он остается удобным файлом для текущей задачи, но не помогает полноценно использовать накопленную информацию.

Похожая задача была у Lassie. Компания уже работала с большим объемом продуктовой информации, но данные хранились в Excel-файлах, из-за чего внесение информации занимало время, а ошибки приходилось исправлять вручную. В пилоте Omnidata. PLM команда сфокусировалась на библиотеке данных: едином хранилище, справочниках, шаблоне карточки модели и формировании техпака на основе данных из системы.

Что меняется с использованием PLM

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

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

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

Руководитель видит проблему слишком поздно

Один из самых понятных признаков, что Excel уже не закрывает процесс полностью: руководитель узнает о проблеме тогда, когда она уже повлияла на сроки, качество или бюджет.

Например, модель зависла на согласовании, но это не попало в общую картину. Материалы заказали по старой версии данных. Стоимость перенесли вручную с ошибкой. Задача осталась у конкретного сотрудника, но в календаре это не видно. Статус поменялся, но до части команды обновление не дошло.

Здесь проблема не только в самой ошибке. Главный риск в том, что отклонение сложно заметить вовремя.

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

Что меняется с использованием PLM

В PLM линейный план, ассортиментная матрица, карточки моделей, календарь и задачи связаны между собой. Руководитель может открыть систему и увидеть текущую картину по моделям, этапам и ответственным. Команде не нужно отдельно собирать сводку, потому что статус формируется по ходу работы.

Система нативно показывает просрочки, ответственных и влияние на итоговые сроки по модели.

Когда Excel уже недостаточно

Excel может оставаться частью рабочих процессов и после внедрения PLM. Вопрос не в полном отказе от таблиц. Вопрос в том, где проходит граница между удобным инструментом и ручным управлением сложной системой:

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

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

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

Все изображения предоставлены Omnidata.