Гибкая система резервирования товара : Закупщик

Привет всем.

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

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

Ответ очевиден - приведенный под нетипичный спрос товарный запас надо было "занычкать", т.е. или переместить на место хранения "под промо", или выписать счет/резерв и т.п.

В принципе, это не сложно. Если бы не моя дурацкая привычка лесть в детали.
А когда я туда полез, выяснилось, что есть еще кучка моментов, в которых надо зарезервировать товар. К примеру, поставщик не смог отгрузить крупную партию и мы решили потихоньку накапливать товар сами (если такой метод удивляет, то надо заметить что склад - консигнационный и пополняется роботом поставщика в зависимости от текущих остатков. Поэтому если даже тебе не дали товар прямо, то можно ежедневно выкупая с консигнационного остатка, к примеру половину, вынудить за 2-3 недели поставщика фактически допоставить требуемое для промо количество).
Ситуации различные, но решают их как в каменном веке - выписывают счет, который действует 3 дня. Если на самом деле это не счет, то его надо не забыть продлить и т.п.

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

В итоге коллеги этими то вопросами и завалили. От чисто технических, до логических из теории множеств и систем, т.к. в моих набросках были выявлены узкие (частично противоречивые) места.
В итоге этот шум-гам разбудил мой внутренний голос, который и спросил - "а не изобретаешь ли ты велосипед? может это всё уже кем-то давным-давно придумано и обкатано?".

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

По поводу "сама". Всё равно любая [ система управления товарными запасами на предприятиях торговли ] должна узнать от оператора о том, что ей чего-то надо больше нормы. Это может быть реализовано через заявку на отгрузку (при ордерной системе), увеличение плана продаж (при плановой системе) или спецбуфер (при использовании теории ограничений систем). Дальше - почти любая программа эту ситуацию отрабатывает вполне себе корректно, увеличивая заказ. Но всякие хитрые случаи - типа автоматического постепенного добора необходимого количества под заявку при параллельном свободном остатке, чтобы и другим хватило - конечно, в стандартных системах отсутствуют. Их дописывают под свою логику - даже не бизнес-процессов, а приоритетов - в каждой компании по-своему. Поэтому лучше будет пойти от вопросов-проблем-задач, с которыми столкнулась конкретная компания, и обсуждения здесь возможных решений данных задач. ;)

Валера, спасибо за ответ!

Я, видимо, не очень удачно описал проблематику. Речь идет, скорее, не про систему управления товарным запасом, а про соседнюю область – систему учета и управления товародвижением. Т.е. передо мной не стоит сейчас задача (в данном вопросе, а не вообще в проекте) как и сколько заказать товара. Для начала мне надо помочь службе учета товародвижения неким нетрудоемким образом создавать резервы товара под те конкретные потребности, которые им указали отдел управления товарным запасом или отдел продаж. Если служба учета будет четко резервировать товарный запас, то я (уже как управляющий ТЗ):
а) смогу с большей вероятностью гарантировать, что товар будет отгружен именно тому КА, для которого Продажи его и прогнозировали 2 месяца назад;
б) буду видеть в учете, что консигнационный остаток снизился (все резервы без исключения – это выкуп товара у поставщика и перемещение его на свои остатки). Тоже самое будет видеть и «робот» поставщика, поэтому я увеличиваю вероятность того, что ТЗ на консиге будет пополнен более оперативно.

Вот что набросал сам себе при первичной проработке вопроса:
1. Система позволяет резервировать товар непосредственно из текущих остатков. Указывается КА, товар, количество, дата, после которой происходит автоматическое снятие с резерва.
Цель: товар, который есть на складе, зарезервировать под конкретного КА.

2. Система позволяет резервировать товар из текущих остатков+текущих транзитов.
Цель: аналогично предыдущему + если товара нет на складе, то когда фура приедет, товар не сможет забрать кто-то более проворный.

3. Упреждающее – как только товар приходит, он сразу же резервируется. Аналогия – принятый и оплаченный клиентом заказ на ранее отсутствующий товар.
Цель: практически полностью повторяет предыдущий функционал, но при этом не обязательно товар должен быть в наличии или даже в транзите. Фактически мы говори КА: «ок, отгрузим вам товар как только он появится у нас».

4. Постепенное _Х% - каждый день система пытается зарезервировать требуемое количество, но не более Х% от имеющегося на утро остатка. Это когда надо создать дополнительный (и значимый!) товарный запас для КА, который не известил об этом в установленные договором сроки. Поэтому мы считаем не корректным просто взять и забрать весь текущий на консигнации остаток под этого КА. Ведь это ущемляет интересы остальных. Но мы говорим «ок, мы постараемся вам за некоторое время сформировать требуемый запас".


5. Любое по типу резервирование может быть осуществлено на:
- конкретного КА
- перечень КА
- на всех, не входящих в указанную группу КА
- просто отдел УТПЗ (для кого данный товар - не указывается).

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

6. По типу цикличности резерв может быть одноразовым и пополняемым.
Это когда норматив ТЗ, установленный поставщиком явно ниже требуемого (например добавился новый КА), поэтому мы делаем пополняемый дополнительный резерв, который как бочка на даче должен быть по возможности всегда полным.

7. По типу учета интересов остальных КА резерв может быть «эгоистом» и «альтруистом». При резервировании документ-альтруист сначала должен попытаться взять товар из созданного под данного КА резерва, и только после этого – с общего склада. «Эгоист» же считает, что созданный под КА резерв должен быть неприкасаемым запасом, который тратится только в случае отсутствия данного товара на общем складе. Поэтому сначала надо попытаться удовлетворить заказ КА из общих остатков.
Цель: применять разные тактики для КА, в зависимости от жесткости штрафных санкций за недопоставку товара.

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

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

А если именно тому КонтрАгенту данный Товарный Запас не нужен?

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

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

Фактически третий пункт - это заявка, которая может автоматически превращаться в резерв на транзит. А он уже должен самостоятельно переходить в резерв на складе, когда зарезервированный в транзите товар приходуется. Другое дело, что не обязательно это всё оформлять, как документы резерва, которые превращаются друг в друга. Это могут быть и первоначальные заявки, которые не будут давать отгружать товар, если его вместе со свободным, ожидаемым до самой ранней даты отгрузки - меньше, чем зарезервировано. Тогда третий пункт будет полностью включать в себя второй.

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

Резерв - означает, что товар нельзя отгрузить любому желающему, хотя этот товар лежит на складе. Вопрос - зачем резервировать, просто под отдел Управления Товарно-Производственными Запасами?

Надо полагать, что сумма этих лимитов будут больше 100%? - Иначе не очень понимаю смысл и в таком групповом резерве.

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

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

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

Вложения

rezerv.doc (170.5 Кб, 209 просмотров)

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

Тем не менее, искренне считая данный сайт одним из лучших по УТЗ, в качестве своего вклада в общую победу УТЗ над всеми урезаниями и перетарками в мире, я размешаю некий "протокол" нашей беседы. Естественно, в моей интерпретации, но если что меня подправят :)

Речь идет не о покупке новой учётной системы, а о обкатанных и проверенных механизмах, которые можно было бы «одолжить» и запрограммировать в нашей.

Безусловно, надо понимать, кто, как много, как часто может создавать резервы. В одних компниях – чуть ли не любой продажник, в любых объемах, а в конце месяца сделают отчет и если что скажут ему «ай-яй-яй», а он скажет, что ему мамой поклялись, что возьмут. В нашей компании -создание резерва это откровенная редкость. Поэтому видимо и функционала кроме как перемещение на отдельное место хранения (естественно в учете) нет. Другими словами, у нас резерв – это действительно для VIP-заказчиков по особым поводам. Но если уж Бизнес посчитал разумным сделать резерв (читай – заморозить свои активы, возможно, со снижением уровня сервиса), то значит это ВЫГОДНО. Конечно, менеджер, который будет делать резервы, будет за них отвечать (и, таким образом, это точно не будет менеджер из отдела Продаж :)).
Пример, для чего нужен резерв. Мы убедили крупную сеть провести крупную промо-акцию нашего товара, выделили на это фонд в виде 35% скидки. Для нас это очень много. Но сеть действительно крупная и оно того стоит. Заказчик заявил, что через месяц возьмет свой 3х месячный товарооборот. Мы размещаем спец заказ у поставщика. Тот подтверждает, что готов нам отгрузить такую крупную партию. Мы подтверждаем КА. Тот изготавливает рекламные материалы, запуская у себя в сети радио-оповещение «только через неделю третья штучка бесплатно». Делает нам заказ, а мы отвечаем «да мы тут подумали, чего это у нас товар мертвым грузом лежит – короче мы половину продали». Куда пошлет нас КА в следующий (а может быть и в этот) раз, думаю понятно. Вот для таких случаев и нужен резерв. К примеру буквально недавно один КА заказал нам товара в размере 6-ти месячного товарооборота по всей РФ. Надо сказать пришлось побегать, посогласовывать с поставщиком. Если такую акцию сорвать….
Комментарий. При созвоне Валера указал на риск того, что удобный и работающий инструмент потихоньку становится популярным и в результате количество резервов становится все больше и больше. И вот тут есть риск перейти некую критическую черту, после которой выигрыш бизнеса от резервирования меньше, чем вред.
Согласен. Такой риск есть. Правда, не понятно, как снижать риски, когда товар уже выкуплен. Нет, понятно, что позвонить КА и закатить истерику – дело принципа. Но почему то зеркальная логика здесь не работает, и КА все равно оказывается прав :).
Но это так – поплакаться. Мысль Валеры абсолютно верная – руку надо держать на пульсе и коль мы уже выкупили товар, почаще звонить КА и спрашивать когда он его закажет. Пока писал даже пришла идея (а-ля CRM) – попросить операторов ставить примечание «что сказал КА когда ему звонили насчет этого резерва в последний раз» или даже указывать «обещанную по телефону дату заказа товара» (она может отличаться от даты автоснятия резерва). Когда это дата пройдет, то оператору автоматически сваливается – «позвони еще раз». Безусловно, это может сократить время хранения «сирот» (резервов, в реальности уже потерявших свою актуальность). Кстати, еще один тип «сирот» - под КА резервировали 1000, а он взял 700. Наверное, умная система могла бы подсказать оператору «позвони КА, узнай – он остальной товар будет брать или можно снимать его с резерва?». Гы. Остапа понесло :) - а еще можно при создании резерва указывать «автоматическое снятие остатков после первого заказа». Вы все еще сомневаетесь в моей способности усложнять простые вещи? :)

Валера, спасибо – раз! Спасибо – два! Обе мысли, безусловно, крайне полезны!

Согласен.

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

Это, к примеру, супер-новинки мега-акции общероссийского уровня, которые пока что запрещено вообще продавать. Отгрузки «iмыла» :) стартуют только по зеленому свистку поставщика.

Совершенно верно. К примеру, на оптовый отдел отдали 1000 штук из пришедших 1500 дефицитного товара. В отделе работает 3 торговых, которым дали 300, 300 и 400. У каждого торгового – 3-5 крупных заказчиков, потребности которых превышают выделенный торговому лимит. Вот здесь можно хотя бы как то смягчить ситуацию – чтобы 1 КА не выбрал совсем уж всё.
Или еще пример – торговый представитель 2 месяца назад заказал под КА-1 10 000 штучек. Их ему привезли. Но сейчас он начинает намекать, что проснулся еще один КА-2, и поэтому надо бы еще 3000-5000. Мы его горе понимаем, но заказано было 10 000. На остатках всего филиала 14 000. Поэтому всё, что можем сделать – это перевесить лимит 10 000 с КА-1 на группу «КА-1, КА-2». Расчет идет на то что КА-1 не выберет весь свой первоначальный прогноз (возможно, усилиями торгового). Впрочем, по иронии судьбы КА-2 сделает заказ пораньше да побольше (ибо ему уже дали понять, что с товаром проблема), а вот спокойно спавший КА-1 потом будет неприятно удивлен. Посему пишем в ТЗ программистам: «после реализации в системе данного функционала, отсчитать 60 дней и …. удалить данный функционал» :).
Соглаcен, хотя не вижу в циклах ничего опасного, хотя не вижу в циклах ничего опасного :).
Для чего такое может понадобиться. У робота поставщика (на основании статистики за прошедшие 3 месяца) установлен целевой товарный запас для данного нашего филиала по данному товару в 1000 штук (это Склад+Транзит). Соответственно, раз в 2 дня робот просто определят разницу факта от плана и (округляя до минимальной партии отгрузки) досылает нам недостающее количество.
Но вот случилось счастье – и одна из крупных сетей включила в листинг данный товар. Пусть даже под первую отгрузку мы сделали спецзаказ и удачно его получили и отгрузики КА. Но все равно наши регулярные потребности в данном товаре выросли. По идее нам бы надо установить у робота поставщика уровень 1300 – и всех делов. Но крупные поставщики не всегда могут менять настройки своих роботов каждый день, поэтому приходит ответ «к сожалению, пересмотр уровней целевых товарных запасов производится 1 раз в 3 месяца. Пожалуйста, до этого времени пользуйтесь инструментом дозаказа товара.» В итоге, девочка 2 раза дозаказала, третий раз забыла (у нее ведь тоже глубина истории может быть своя, с «инерцией»). Поэтому если бы мы сказали своей системе «всегда выкупай на собственный склад столько, чтобы на нем данного товара было бы 300» (по данному документу резервирования), то мы фактически бы косвенным образом сделали бы свой уровень товарного запаса в 1300 – что и требовалось. В конце квартала данный циклический резерв естественно удаляется.

Хорошая мысль. Надо обдумать. Спасибо! Ведь ситуации бывают разные. Если к примеру за товар конкурирует 2 заказа от 2-х КА, то товар можно отдать тому, чей заказ к текущему моменту удовлетворен на более низкий уровень (по другим товарам). Потому что совокупная громкость криков от КА при этом снижается. Первый итак получил 98% (снизили с 99%), а второму мы за счет этого подняли с 92%, до 93% Не цель, но уже полегче. Правда, в таком случае, надо рассматривать все заявки одновременно или по крайней мере волнами, чего я очень не люблю делать. По мне лучше «конвейер» - заявка пришла, обработана – улетела на склад. Никто никого не ждет. Впрочем, бизнес всегда имеет свою специфику, поэтому надо будет – будешь и одной волной в день все заявки обрабатывать.