Полный бэк-офис для селлера домашнего текстиля на Wildberries: 763 карточки, 4 бренда, около 6 000 заказов в день, производство в Узбекистане с циклом ~60 дней. Система охватывает: досорт на буферах ТОС, ежедневная таблица РНП, 7 типов алертов, дашборд экономики с прогнозом месяца, комбинаторика наборов, ABC-анализ, заказ производителю в один клик и справочник складов. А на складе работает модуль FBS: поставки собираются прямо в ERP, код маркировки проверяется в момент скана, срочные заказы идут первыми, недостающий товар дозаказывается у поставщиков в МойСклад, а владелец видит выработку сборщиков и приёмку по поставщикам.
Быстрорастущий селлер полотенец, халатов и текстильных наборов. Цифры жили в трёх несвязанных сервисах. Главное решение бизнеса, что и когда досортировывать, принималось вручную.
Кабинет маркетплейса: заказы и реклама. МойСклад: склады и составы наборов. TrueStats: юнит-экономика. Плюс ручные выгрузки файлами. Единой картины не видел никто.
Какой SKU везти на склад маркетплейса, сколько и когда: владелец решал это ежедневно, в личном Excel, по 763 карточкам в ~27 категориях. Процесс не масштабировался и не переживал отпуск.
Производство занимает около 60 дней, плюс ~10 дней доставка, плюс внутренние плечи. Заказал поздно - пропустил сезон. Заказал рано - заморозил деньги в остатках. Права на ошибку почти нет, а в сезон его нет совсем.
Обнуление остатков, падение заказов, негативные отзывы и расхождения данных всплывали, когда кто-то случайно посмотрел. При 6 000 заказов в день "случайно посмотрел" - это не система контроля.
Каждую ночь Celery-задачи стягивают маркетплейс, МойСклад и TrueStats в PostgreSQL. Расчётные модули превращают сырые строки в буферы, алерты и прогнозы. Люди работают в React-портале или в Google-таблице, которую бэкенд рендерит для менеджеров. Днём, в рабочую смену склада, модуль FBS опрашивает площадку каждую минуту и пишет наружу ровно то, что ему поручено: поставки в кабинет площадки и заказы поставщикам в МойСклад, каждую запись с журналом.
Контракты между модулями означают, что ничего не считается дважды: достаточность даёт одна функция, светофор 33/67 живёт в одной настройке, классы ABC отдаёт один сервис. РНП, Google-витрина и алерты потребляют одни и те же цифры.
Заказчик попросил проверить его формулы досорта и предложить улучшения. Его классический расчёт покрытия остался в таблице видимыми колонками. Поверх система ведёт динамическое буферное управление (DBM): у каждого SKU есть целевой буфер, буфер делится на зоны-светофор, и буфер сам корректируется по фактическому потреблению. Это ТОС по учебнику, реализованная кодом и тестами.
×1.1 - это запас "на паранойю" от заказчика на каждый буфер, в духе Голдратта. M - множитель DBM: стартует с 1.00 и меняется шагами по 1/3.
Буфер заполнен достаточно. Ничего не делать. Двенадцать зелёных дней подряд предложат уменьшить буфер: капитал не должен спать в остатках.
Планировать пополнение. SKU попадает в досорт-таблицу с рассчитанным количеством, а не с догадкой.
Заказывать сейчас. Красные дни копятся в 12-дневной истории; красная серия запускает рекомендацию увеличить буфер.
Остаток ноль при живых продажах. Потерянная выручка каждый день. Чёрная считается красной в сериях и кричит с верха ленты алертов.
| Константа | Значение | Обоснование |
|---|---|---|
| Окно DBM | 12 дней | Три плеча пополнения склада маркетплейса (4 дня). Короче - реакция на шум, длиннее - реакция с опозданием. |
| Триггер увеличения | ≥80% красных из 12 | Буфер, живущий в красной зоне, буфером не является. Рекомендация: +1/3 от целевого. |
| Триггер уменьшения | 12 зелёных подряд | Буфер, не выходящий из зелёной зоны, - это замороженные деньги. Рекомендация: -1/3, и считается только непрерывная серия. |
| Пол | M ≥ 1/3 | Множитель никогда не падает ниже трети. Если шаг пробил бы пол, уменьшение даже не предлагается. |
| Кулдаун | 12 дней | После любой корректировки система молчит целое окно: сначала измерить эффект одного решения, потом предлагать следующее. |
| Паранойя | ×1.1 | Правило заказчика: +10% к каждому буферу. Оформлено именованной константой, закрыто тестами. |
| Плечи поставки | 4 / 14 / 74 дня | До склада маркетплейса / со склада производителя / с производства (цикл 60 дней + 10 доставка + внутренние плечи). |
| ТОП-правило | 90% | Правило заказчика: SKU класса A с покрытием ниже 90% всегда прыгает в верх досорт-таблицы, выше любого SKU класса C, и досортировывается минимум до 90%. |
У каждой категории есть окно сезона и коэффициент. Ручной коэффициент заказчика всегда приоритетнее автоподсказки. Подсказки считаются из прошлогодних заказов: суммы по неделям, сглаживание MA-3, сезон = сегмент выше 50% пика.
Вне сезона скоростная формула игнорируется. Категория держит фиксированный запас в штуках, распределённый по SKU пропорционально их доле в заказах за 90 дней. Совсем нет истории - поровну.
В закрывающем окне сезона буфер линейно снижается к запланированному дефициту. Сезон заканчивается пустыми полками по плану, а не остатками на год вперёд.
Автоприменение корректировок буфера по умолчанию выключено. Ежедневная задача лишь пишет рекомендацию в строку: кнопка ±1/3 с подсказкой, почему. Менеджер нажимает, изменение логируется, стартует кулдаун. Это дисциплина самого Голдратта: буферы адаптируются, люди утверждают.
РНП, "Рука на Пульсе", - ежедневная панель по каждому SKU: воронка продаж, экономика рекламы, остатки и цены, около 60 колонок на SKU, с виртуализацией, чтобы 763 строки листались как шёлк. Дашборд отвечает на вопрос владельца: чем закончится месяц, если едем как едем?
763 строки × ~60 колонок со sticky-колонкой SKU и настраиваемыми светофорами. Карточный режим для работы по исключениям. Каждый SKU раскрывается в карточку: продажи, реклама, остатки, цены и комментарии в окнах 7 / 14 / 30 дней.
Выгрузка воронки маркетплейса прилетает drag-and-drop. Колонки матчатся нечётким маппингом; переименованная колонка вызывает диалог подтверждения, а не тихое неверное чтение. Битые строки отклоняются поштучно, файл целиком не падает.
Выручка TrueStats и маркетплейса сравнивается ежедневно. Расхождение больше 5% поднимает баннер. В проде это поймало реальные 13,31% на первом же боевом прогоне.
Экономика кабинета и категорий из файла, API или их слияния по SKU. Прогноз конца месяца по тренду 15 дней. Расходные метрики инвертируют окраску: растущая реклама красная, а не зелёная. Ответ: 61 мс с кэшем, 101 мс без.
Бэкенд рендерит витринные листы прямо в привычную таблицу: главная, сезон, распределение,
новые цены, контроль остатков, алерты. Запись только RAW, чтобы штрихкоды не превращались
в 2.05E+12. Ручные правки возвращаются дифф-пуллом каждые 10 минут, и рендер
никогда не затирает ячейку человека. Кнопка в таблице отправляет новые цены назад через
вебхук с проверкой токена.
Проблемы должны сами находить людей, а не ждать, пока их найдут. Семь детерминированных типов алертов следят за бизнесом; страница здоровья со светофорами следит за самой системой.
| Алерт | Триггер | Детали |
|---|---|---|
| Крайняя срочка | ≤100 штук на маркетплейсе | Всегда красный, всегда закреплён вверху ленты. |
| Низкая достаточность | покрытие ниже порога | Тот же контракт достаточности, что и в досорт-таблице. Одна формула, одна правда. |
| Падение заказов | скорость за 3 дня против 10 дней, ≥30% вниз | Ловит умирающий SKU за дни, а не за недели. |
| Всплеск заказов | скорость за 3 дня резко вверх | Всплеск - тоже сигнал досорта: продавать, пока летит. |
| Негативные отзывы | новые отзывы на 1-3 звезды | Попап с текстами отзывов, серверная пагинация. На приёмке в базе было 1 447 негативных. |
| Старт производства | <90 дней запаса | Отсчитывает 60-дневный цикл производства назад от прогнозного обнуления, вне сезона смягчается. |
| Расхождение данных | разрыв TrueStats и WB >5% | Система не доверяет своим входам раньше, чем предложит доверять своим выводам. |
Алерт - это эпизод: активен, решён, реактивирован в тот же день, если условие вернулось. Ноль дублей по построению. Отметка "видел" - на каждого пользователя, чужое "видел" проблему не прячет.
Если данным маркетплейса больше 24 часов, весь пересчёт алертов пропускается. Никаких алертов на устаревших данных: тишина честнее шума.
Первый боевой прогон поднял 388 активных эпизодов. Это накопленный слой проблем, которых раньше просто не было видно. Лента их отсортировала; крайняя срочка встала первой.
Крон каждое утро в 05:00 прогоняет все автотесты, 1 286 backend и 440 frontend, в чистой отдельной базе. Результат ложится в таблицу и показывается на странице Здоровье, рядом со светофорами контейнеров, памяти, диска и свежести бэкапа. ERP ежедневно доказывает владельцу, что всё ещё работает. Не обещание, а зелёный свет.
Полотенца продаются поштучно и в наборах. Одно и то же сырьё может уйти десятком способов, у каждого своя цена за штуку, маржа и потолок по остаткам. Раньше эту комбинаторику держал в голове заказчик. Теперь её считает система и объясняет каждое предложение в колонке "Почему".
Для каждого сырья-полотенца: все варианты продажи, поштучно или внутри любого из 349 составов из техкарт МойСклад. По варианту: цена за штуку, маржа, потолок по текущим остаткам, лимитирующий компонент и жадный план распределения. 294 сырья × 349 составов = 1 813 вариантов за 3,0 секунды, сверено вручную SQL-ом на боевых данных.
Мерчандайзинговое правило заказчика, переведённое в код: розовый сам не продаётся, а в связке с серым улетает. Движок разбирает модельную основу артикула, ставит в пару топ-цвет и неликвид той же основы, скрещивает основы и оценивает экономику каждого кандидата по аналогам.
У каждого кандидата есть человеческое обоснование: какой цвет тянет, какой остаток разморозит, какая ожидаемая экономика на штуку. Оптимизация сознательно жадная, без LP-солвера: заказчик может проследить каждый шаг, а доверие важнее последнего процента оптимальности.
Плавающая ABC-классификация сразу по трём критериям: прибыль, выручка и заказы, с настраиваемыми порогами 80/95 под защитой CHECK-ограничения в базе.
Первый боевой прогон оцифровал интуицию: класс A - это 134 SKU, 17,6% каталога, держащие 80,2% прибыли. Классы сверяются с собственным ABC аналитического сервиса, а убыточные SKU и SKU без данных показываются отдельными корзинами с разложением причин, а не тихо выпадают.
Классы считаются один раз и отдаются по контракту: РНП и досорт-таблица подтягивают букву без пересчётов. ТОП-правило досорта питается именно этими классами.
SKU класса A с покрытием ниже 90% буфера прыгает в верх заказа поставщику, выше любого SKU класса C с худшим процентом. Бизнес защищает те 134 SKU, которые платят за всё остальное. Этот приоритет - оттестированное правило, а не привычка в чьей-то голове.
Буфер говорит, чего не хватает. Модуль заказа говорит, где это взять и к какому сроку, и собирает тот самый Excel, который ждёт производитель в Узбекистане.
Q(L) = max(0, ceil(V_план × (N + L) × 1.1 - общий остаток)). Проход первый смотрит склад производителя: хватает - режим "со склада", плечо 14 дней. Иначе режим "производство", плечо 74 дня (60 производство + 10 доставка + внутренние плечи), с пометкой, если часть количества есть уже сейчас.Склад собирал заказы руками: кабинет площадки, лист подбора, Excel, сканер в Excel, ручная замена скрытых разделителей и загрузка шаблона обратно. Главная потеря времени наступала уже после загрузки: площадка проверяет каждый код в национальной системе прослеживаемости и часть отбраковывает, а люди идут искать эти товары по коробкам. Модуль переносит проверку в момент скана: сборщик узнаёт о плохом коде, пока товар у него в руках. Следом в ERP переехали и сами поставки: как они собираются из очереди, рассказано в следующем разделе.
| Вердикт | Что видит сборщик и что делает дальше |
|---|---|
| Код принят | зелёный, задание закрыто, стикер уходит на печать |
| Принят без проверки | жёлтый: реестр не ответил, код принят по настройке, ночью перепроверяется |
| Код чужой | владелец кода другая компания: отложить, взять другой экземпляр |
| Уже продан | код выбыл из оборота: отложить, взять другой экземпляр |
| Не в обороте | код не введён в оборот: отправить в карантин |
| Заблокирован | карантин |
| Нет в базе | карантин |
| Дубль | красный, с номером задания-владельца: оттуда можно перепечатать стикер |
| Экземпляр лишний | все задания этого размера в поставке уже собраны: сканер называет товар, размер и время последней сборки и просит отложить экземпляр |
| Другой товар | сканер называет товар и размер и говорит, где ждут его задания: в этой поставке, в другой партии или в другой поставке |
| Код не распознан | код прочитан не целиком: пикнуть ещё раз. Срезанный хвост кода не выдаётся за чужой код |
Порядок проверок важен. У чужого проданного кода причин отказа несколько, а сборщику нужно назвать одну: ту, с которой он что-то может сделать.
Сервер сам классифицирует ввод: штрихкод, код маркировки или стикер, и двигает состояние задания. Переключать режимы человеку с товаром в руках нечем.
У каждого нажатия свой идентификатор, и повторный запрос отдаёт тот же ответ, а не пересчитанный. Иначе сборщик увидел бы "этот код уже отсканирован" на собственный же скан.
Повторный импорт обновляет поля площадки и не трогает наши: статус, партию, сканы и коды. Ночной прогон не стирает то, что сделали люди.
Задание с плохим кодом уходит в карантин с причиной, а не исчезает из списка. Начальник склада видит, сколько заданий встало и почему.
Право администратора модуля даёт заводить и выключать сборщиков без администратора портала. Только выключение, не удаление: на человеке висят сканы и сводки.
Смена это день по московскому времени. По каждому сотруднику видно: взял с полки, код принят, готово, проблем, отклонённых сканов, первый и последний скан. Число отклонённых сканов открывается списком: время, товар, что пикнули и что ответил сканер.
Сканер выдаёт символы за миллисекунды, поэтому 300 мс тишины после похожего на законченный кода уже означают конец ввода. Пик ловится на всей странице: клик по вкладке или кнопке его больше не съедает.
Сканер нажимает клавиши по английской раскладке, и при русской код приходит кириллицей и чужими знаками. Карта исправления применяется одним проходом и только если в строке есть кириллица: точка и запятая в серийнике законны.
Код маркировки находит задание сначала по штрихкоду задания, потом по штрихкоду размера в карточке площадки и только потом по связкам, выученным на складе. Признак, нужен ли товару код, тоже берётся у карточки. Лишний запрос кода стоит одного пика, а пропущенный отправил бы товар без кода.
Молчаливая деградация здесь недопустима. Если токен доступа к реестру умер, модуль поднимает системный алерт и продолжает работать в режиме "принят без проверки", честно помечая такие коды. Именно тихий отказ и стоил бы той самой отбраковки на площадке, ради которой всё затевалось.
Поставку создавали в кабинете площадки: галки по списку новых заданий сверху вниз. В одну поставку попадала сотня разных артикулов, и сборщик обходил с ней весь склад. Заказы юрлиц в кабинете никак не помечены: отметишь сто заданий, а поставку создать нельзя, и ищи, какое мешает. Теперь очередь живёт в ERP, а поставка складывается из того, что удобно собирать одним походом к полке.
До этого модуля ERP ничего не писала во внешние системы. Исключение сделано узким: создать поставку, добавить задания, задать параметры отгрузки и передать в доставку. Каждая запись ложится в журнал с запросом и ответом, его видно на вкладке поставки. Если площадка потеряет поставку, есть чем ответить в поддержку. Коды маркировки по-прежнему уходят шаблоном, который загружает человек: это честное ограничение.
Задания добавляются пачками по 100. Если площадка отвергла пачку, она делится пополам, пока не найдутся конкретные задания-отказники. Они остаются в очереди с причиной, остальные доезжают. Одно плохое задание не роняет поставку.
Строка поставки сохраняется сразу после её создания у площадки, до добавления заданий. Если дальше что-то упадёт, ERP знает о пустой поставке и удаляет её. От двойного клика защищает замок, а задания в очереди блокируются, чтобы параллельный опрос их не переставил.
Смешанную выборку система режет сама: крупногабаритное отдельно, юрлица отдельно, и в строке плана об этом написано. Человеку не нужно помнить правила площадки, чтобы не получить отказ.
Если поставку расформировали на стороне площадки, ERP это замечает при опросе. Задания возвращаются в очередь, собранное остаётся собранным, а пустая поставка из ERP удаляется.
Сканер работает по партии. Задания, которые площадка перенесла в другую поставку, на каждом опросе сами отвязываются от старой партии, а баннер предлагает объединить партии, если их всё же стало несколько.
Новые задания того же артикула можно добавить в уже открытую поставку из панели выбора или со страницы поставки. Они встают в ту же партию, и сборщик продолжает с того места, где был.
Иногда собирать нужно не по типу товара, а по возрасту заказа. В кабинете видно самый старый заказ, а в очереди раньше не было ни даты, ни возраста. Теперь у очереди две вкладки: вся очередь и горящие. На горящих стоит лесенка ждут дольше 20, 24, 36, 48 и 72 часов со счётчиками, а колонка Ждёт показывает возраст самого старого задания: от порога янтарный, от 48 часов красный.
Дерево приходит уже суженным, поэтому выбор, план и создание поставок ничего не знают про срочность и остаются теми же. Отметил категорию на горящих, и в поставку уходят только горящие задания этой категории, а свежие остаются в очереди.
При пороге 20 часов в выходной горит половина очереди. Самые старые менеджер берёт ступенью от 48 часов, а не правкой настройки. Вкладка живёт в адресе страницы, на неё можно дать ссылку.
Задания, по которым площадка уже отдала конечный статус, но которые у неё висят новыми, из расчёта возраста исключены. Иначе они навсегда остались бы самыми старыми и прятали настоящие срочные.
Когда поставки и сканы живут в ERP, у владельца появляются ответы на вопросы, которые раньше решались на глаз: чем был занят сборщик, какие товары дают отказы сканера, чего не хватает на складе и сколько товара поставщика площадка на самом деле приняла.
До четырёх сборщиков работают параллельно. Смен и норм в системе нет, поэтому всё считается по сканам. Присутствие длится от первого до последнего скана дня. Активное время складывается из пауз между соседними сканами короче порога: 5, 10 или 15 минут на выбор, длиннее это простой, обед или другая работа. Скорость это штуки за активный час, загрузка это активное время к присутствию. Эффективность одним числом сравнивает человека со средним по складу за тот же период, а скорость и загрузка рядом объясняют, за счёт чего оно такое. Динамику по людям видит только владелец.
Цифры статистики за день обязаны совпадать со сводкой по смене, и это закреплено тестом. Агрегатных таблиц нет, всё считается на лету, а миграция добавила только индексы, построенные без блокировки горячих таблиц посреди смены.
У двух третей отказов задание не найдено: сканер отказал раньше. Поэтому товар восстанавливается по самому коду той же цепочкой, что у сканера. Так видно, какие товары поставщика дают отказы, и с этим можно идти к поставщику.
Учётная запись без единой собранной штуки и меньше чем с десятью сканами в статистику не попадает: это проверка сканера или тестовый вход. Маркированный товар собирается дольше, и экран прямо пишет, что сравнение людей на разном товаре условно.
Раньше сборщик глазами находил, что товара нет, и к обеду писал об этом в имени поставки. Список уходил поставщику, тот собирал его ещё несколько часов и привозил на следующий день: терялись сутки, а просрочка сборки бьёт по рейтингу. Теперь кнопка в очереди раскладывает несобранные задания по поставщикам из карточек МойСклад и создаёт по заказу поставщику на каждого. Наборы раскладываются на компоненты по техкарте, упаковка не заказывается. Это другая функция, чем заказ производителю из раздела 08: там буфер ТОС, здесь конкретные задания FBS.
Заказали 100, пришло ещё 7, и следующий заказ будет на 7, а не на 107. Это держит частичный уникальный индекс в базе. Если заказ удалили или отменили в МойСклад, его задания снова идут к заказу: статусы сверяются перед каждым предпросмотром.
Строка журнала с внешним кодом сохраняется до запроса. При обрыве или таймауте документ сначала ищется по этому коду, и только если его нет, задания освобождаются. Иначе повтор создал бы второй заказ поставщику.
Заказ создаётся непроведённым, остаток склада пока не вычитается: лишнее люди вычёркивают в МойСклад. Это осознанная первая итерация. После создания документ перечитывается, и сверяются число строк и штук.
Одним токеном МойСклад читает ночной синк и создаются заказы, менять его может только суперпользователь. Карточки читаются в момент нажатия: поставщика и штрихкод менеджер правит днём, и кнопка сразу видит правку.
Часть поставщиков работает как фулфилмент: сами везут товар на склад площадки, а платят им по принятому. Передали 600, площадка приняла 599, оплатят 599. Экран учёта показывает, сколько товара каждого поставщика сдано в поставках FBS и сколько из этого принято, по дате приёмки или по дате сдачи, с разбивкой по дням и товарам и отдельной вкладкой того, что сдано и до сих пор не принято.
Поставщик фиксируется в момент сдачи, а отметка принято липкая. Заказ, отменённый покупателем уже после приёмки поставки на складе площадки, тоже считается принятым: поставщик сдал, склад получил.
Дата приёмки берётся по скану поставки на складе площадки. Если скана нет, ставится момент, когда ERP увидела приёмку, с пометкой неточно, и позже уточняется.
Одно поле на экране поставок ищет по номеру, артикулу, штрихкоду, названию, заданию и стикеру во всех поставках, включая закрытые. Около 155 тысяч заданий проходятся за 150-270 мс по замеру на боевой базе, поэтому индекс и миграция с блокировкой горячей таблицы посреди смены пока не нужны.
Справочника складов в системе не было: имя склада жило голой строкой внутри дневных снимков остатков, и выключить склад из расчётов было нечем. Заказчик держал заметную часть товара на складах, которых уже нет, а досорт, товарооборот и РНП считали этот товар живым остатком.
Заказчик просил указывать, с какого числа склад отключён, и пересчитывать историю начиная с неё. Снимки остатков старше этой даты остаются как были: прошлое не переписывается.
Два поля в строке склада отвечают только на вопрос "кто выключил его сейчас". Вопрос заказчика был другой, и на него отвечает история: кто, когда, с какой даты и по какой причине.
Повторное сохранение с теми же данными журнал не пополняет. Иначе за неделю он зарастает шумом и перестаёт отвечать на исходный вопрос.
Псевдосклады "в пути" и точки приёмки исключать нельзя: они не хранят товар, а обозначают его движение. Попытка выключить такую строку отвергается сервером, а не только гардом на фронте.
Сначала бизнес-анализ. Каждый этап начинался с самодостаточного письменного ТЗ: контракты данных, формулы, критерии приёмки. Реализация шла шаг за шагом по железным правилам, записанным после предыдущего ERP-проекта. Каждое изменение небольшим проверяемым шагом.
Автоматический сезонный коэффициент пока равен 1: API маркетплейса хранит только ~6 скользящих месяцев истории, поэтому сезонность год к году физически недоступна. Система честно пишет "мало истории" и копит собственную. Ключ сервисного аккаунта Google на приёмке ещё не был передан, поэтому модуль мягко пропускает работу, а не падает. Парсинг конкурентов написан, но ждёт прокси. Все три пункта записаны в отчёте приёмки, а не обнаружены потом.
| Область | Было | Стало |
|---|---|---|
| Решения по досорту | Личный Excel владельца, ежедневно, по ощущениям. Держалось на одном человеке. | Буферы ТОС с зонами-светофором по каждому SKU, самокоррекция шагами ±1/3, каждое изменение подтверждает человек. |
| Данные | Три сервиса плюс ручные выгрузки. Единой картины нет. | Один PostgreSQL, ночной конвейер с гейтами свежести и идемпотентными импортами. |
| Обнаружение проблем | Глазами, когда кто-то случайно посмотрел. | 7 типов алертов; 388 ранее невидимых эпизодов подняты в первый же день, крайняя срочка всегда сверху. |
| Экономика месяца | Понятна после окончания месяца. | Дашборд с прогнозом конца месяца по тренду 15 дней, за 61 мс. |
| Планирование наборов | Комбинаторика в голове владельца. | 1 813 рассчитанных вариантов за 3,0 с, у каждого нового кандидата письменное "Почему". |
| Заказ производителю | Собирался вручную под каждый заказ. | Галки плюс одна кнопка: точный Excel-формат производителя, с историей и снапшотами. |
| Поставки FBS | Галки в кабинете площадки сверху вниз, в одной поставке сотня разных артикулов. | Очередь по складу и предложенная сборка: артикул своей поставкой, горящие заказы первыми, передача в доставку из ERP с журналом. |
| Нехватка товара | Сборщик к обеду писал, чего нет, в имени поставки, список уходил поставщику. | Заказ поставщику в МойСклад из очереди FBS, наборы разложены по техкарте, каждое задание заказывается один раз. |
| Контроль склада | Кто чем был занят и какие товары дают отказы, видно не было. | Статистика сборщиков по сканам и учёт приёмки по поставщикам: сдано, принято площадкой, ждёт. |
| Доверие | "Должно работать." | 1 286+440 автотестов каждое утро в чистой базе, результат виден заказчику на странице Здоровье. |
Бизнес-аналитик и строитель систем. Начинаю с бизнес-процесса и контракта данных, потом автоматизирую. Эта ERP спроектирована, описана и выведена в прод и ведёт досорт заказчика на буферах Голдратта, а не на интуиции.