Архив форума

Добрый день всем!
Надо решить наболевшую проблему, кто её как решает и вообще что можно сделать.
Есть склад, с которого происходят продажи как в опт так и в розницу. В сезон существует определенный дефицит товара. Есть менеджеры оптового отдела, которые резервируют этот товар под существующих покупателей, которым этот товар не нужен. Просто ставиться резерв на всякий случай. В итоге по дефициту почти весь товар в резервах, которые кочуют от менеджера к менеджеру. Реально доказать это сложно  . Есть максимальный срок резерва 1 неделя, после которого товар снимается с резерва, если к нему не привязаны деньги. но как уже заметил резерв кочует "С одного сняли на другого поставили". В итоге страдает розница. Вот и интересует как разорвать этот замкнутый круг, чтоб никому не было обидно.
Предложение в виде штрафа не принимаются, оштрафовать мы всегда успеем  

Может быть стоит оставить резервирование только под конкретные обязательства, подтверждаемое финансовым контролером (ну фьючерс, что ли), а остальные совсем отменить и пользоваться только резервированием, которое делает документ на конкретную отгрузку, редактирование которого запретить?
Пробовал внедрить у себя. Не дали. Собственная розница - дело тонкое.

Евгений, привет!
 
Очень знакомая проблема. Вижу 2 решения:
 
1. Запретить резерв оптовому отделу на время дефицита (или резервировать только оплаченный товар).
 
2. Распределять товарный поток на входе в соответствии с планами продаж. Возможно и последующее перераспределение, если есть менеджеры товарных групп, как их модно сейчас называть - Категорийные менеджеры.

Скажу, что по второму варианту начали работать. Проблема "мертвых" резервов ликвидирована.

Да. Логично, коллеги.  
Путь 2 решит некоторые проблемы, но только в условиях устойчивого спроса. Иначе перераспределение, о котором пишет Андрей, измучает.
Позволю себе предостереч Вас от проблемы, которую могут создать бестселлеры: как из "знакомого" товара, так и особенно из "нового".

Добрый день!
 
Давно непосредственно с этой проблемой не сталкивался. Но, Евгений, могу рассказать несколько правил. которые мы у себя ввели и которые помогли снять остроту проблемы. Это больше управление продажами.
1. срок резервирования - стандартный срок оплаты в компании не более. Это нормально и, думаю, Вы уже сделали.
2. Жесткий контроль неоплаченного товара. На складе лежит товар в неск. состояниях: 1. физический остаток всего; 2. оплаченный клиентами, но еще не отгруженный; 3. неоплаченный товар.
3. ЛЮБОЙ неоплаченный товар состояние 3 п.2. может быть передан оплатившему его клиенту. Кто превый встал - того и тапки. Менеджеры должны соревноваться за то, чей клиент быстрее оплатит товар, а не кто быстрее зарезарвирует.
4. Жесткий контроль оплаты счетов/резервов клиентами по менеджерам. Оплачиваемый % от общего числа/суммы сформированных менеджером резервов. Регулярность оплаты резервов. Это нечто вроде абсхуза по менагерам.
 
Конечно требует определенной воли и организации. Но несколько раз таким подходом удавалось снять остроту проблем, подобных Вашей.
 
Будут вопросы - отвечу. Пишите на почту.
 
С уважением.
 
Шиков.

Процитировано сообщение: Шиков Виктор от 25.10.2007 :: 17:59:28:

Спасибо Виктор.
1,2 и 3 пункт конечно же сделаны. Только 3 немного в другой модификации, но это не принципиально.
А вот над 4 пунктом подумаю, как то не приходило в голову  , хотя это элементарно.

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

Процитировано сообщение: Семенов Дмитрий от 29.10.2007 :: 12:48:17:

 
Хорошо бы так, Дмитрий. Но не получится у нас так в силу ряда обстоятельств и людей  

В том то и дело, что человек себе не враг. Договориться можно, но вот соблюдать эти договоренности сложно манагерам и я их понимаю. Мы работаем на строит. рынке, и все идет от неродивых прорабов и строителей, которым все нужно было вчера. Но их тоже можно понять, какое у нас финансирование все знают, на бумаге деньги выделят, а реально дадут за несколько дней (недель) до завершения стороительства и крутитесь вы прорабы как хотите. Можно сказать что "давайте отсрочки и т.п.", но они же тоже не резиновые.
Вот и получается палка о двух концах, с одной стороны у менеджера есть суммовой план продаж, с другой стороны есть дефицит товара НЕ ПО НАШЕЙ ВИНЕ - так у нас работают заводы, у которых мощности производства не справляются с пиковыми потреблениями в сезон.
В итоге возникает проблема опта и розницы, вернее дележки товара  

Процитировано сообщение: Филимонов Сергей от 30.10.2007 :: 09:18:06:

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

Цитата:

 
Ага, это как два крана на два газовых обогревателя открывать. Хотите - крутите сами, а можно поставить термодатчики. Если их правильно настроить, открываться будет самостоятельно тогда и настолько, когда для дела это нужно и выгодно, а не по максимуму или по личному желанию кранооткрывателя.
 
Вопрос, сумеем ли настроить датчики, чтобы на автомате было лучше, чем вручную и стоит ли это требуемых усилий. У нас при двух десятках оптовых и розничных подразделений - стоило. И сумели.
 
См. ответы #13 и #19

Цитата:
Идеи не новы - это к месту примененный старый добрый хозрасчет (или, в более современных терминах, деление на бизнес-единицы).
Цитата:
С точки зрения линейного руководителя - минимум автоматизации, максимум зависимости от его личных решений, чем и определяется его "незаменимость" в компании. (Если, конечно, никого не заботит эффективная мотивация его должностных действий и устойчивость компании в целом.)  
Цитата:
Настройка заключается в степени ответственности опта, розницы и др. за зарезервированный товар. Рассчитывается напрямую через доходность инвестиций в товар (параметры: стоимость денег, стоимость хранения, наценка, оборачиваемость. Если копнуть глубже, то еще экспертный параметр, определяющийся политикой компании, стратегическими задачами, приоритетами, конкурентной средой. Но это уже настройка второго порядка точности.)

Андрей, я Вас хорошо понимаю. У меня такая система работала, когда я был именно руководителем. Одна важная деталь: господ продавцов пришлось ОБУЧИТЬ грамотно пользоваться этим элементом хозрасчета. В противном случае, премируй, депремируй - будут резервировать, исходя из личных произвольных соображений с убытком для себя.

Пишете такое ТЗ (просто привел текст из нашего), только подставляете свои значения в кач-ве ограничительных параметров (красные циферки заменяете на свои).
После того, как его реализуют, проблема на 90% решена.
Заколебутся они (продажники), работая в такой системе, перекидывать резервы.
Потребуется, конечно, модификация ТЗ под конкретную специфику, но смысл идеи, думаю понятен.
Контроль резервов, автоснятие, борьба с хитрыми людьми - вполне автоматизируемо. Немножко подумать только нужно.
 
Описание ТЗ.
 
Вводится признак клиента, характеризующий срок, на который для этого клиента позволено резервировать товар.
Вводятся процедуры контроля правильности создания резервов.
Вводится процедура автоматического удаления резервов.
 
Изменения в системном документе "Карточка контрагента".
 
     В системный документ, содержащий описание контрагента (название, юр.реквизиты, скидки, отсрочки и т.д.) вводится новый параметр:
     Признак клиента.
     Выбор из справочника признаков.
     Справочник признаков содержит 2 поля (помимо ключа) – Признак клиента и Срок резервирования.
Справочник признаков должен быть пополняемым (редактируемым), и на момент реализации ТЗ содержать следующие строки:
-      обычный клиент                  14
-      зарубежные продажи            30
-      FMCG клиент                  60
-      библиотека                  180
По умолчанию присвоить каждому существующему клиенту значение: Обычный клиент.
 
Информация о признаке будет в дальнейшем использована в процедуре автоматического контроля срока резервирования.
 
Изменения в тр-циях, создающих заказ клиента и резервирующих товар.
 
В существующие тр-ции работы с заказом вводятся следующие изменения.
 
Поле: Требуемая дата поставки – сделать обязательным к заполнению, по умолчанию = Сегодня.
 
Добавить поле, сохраняемое как атрибут заказа "Счетчик изменений", по умолчанию=0, заполняется автоматически, редактированию пользователем не подлежит.
 
При попытке резервирования товара по заказу, должна запуститься автоматическая процедура контроля корректности установленной Даты отгрузки.
Процедура сравнивает установленную Требуемую дату поставки на соответствие политике резервирования для соответствующего клиента.
Если Требуемая дата поставки > (Сегодня + Срок резервирования), резервирования не происходит, пользователю выдаётся сообщение: "Нарушение политики резервирования по дате отгрузки", после нажатия кнопки ОК сообщение закрывается, а фокус ввода помещается в поле: "Требуемая дата поставки".
Иначе – заказ резервируется.
 
При дальнейших попытках пользователя войти в заказ и изменить поле "Требуемая дата поставки", поле "Счетчик изменений" увеличивается на 1 при каждом сохраненном изменении "Требуемой даты поставки".
 
Если при входе в заказа текущее значение счётчика >= 2, то при попытке пользователя изменить значение в поле "Требуемая дата поставки", пользователю выдаётся сообщение: "Превышен лимит изменений даты поставки", и после нажатия ОК в поле Требуемая дата поставки восстанавливается предыдущее значение (то, которое было до ручного изменения).
 
Таким образом, при работе с заказом, должны быть заблокированы следующие ситуации:
- Требуемая дата поставки превышает допустимый срок резервирования для этого клиента
- Попытка свыше 3-х раз (включая самый первый раз) назначить заказу новую Требуемую дату поставки
 
Создание процедуры автоочистки резервов.
 
Создать процедуру, производящую удаление из таблицы резервирования всех строк заказов, которые удовлетворяют условию:
Требуемая дата поставки < Сегодня  
или
Дата создания заказа < (Сегодня – 180)