Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли

А поделитесь опытом по поводу "Автоматизированного заказа"? : Системы автоматизации торговли

24.11.2024 7:32


24.09.2013 01:22
Когда-то (довольно давно) при попытке создания сети продуктовых магазинов ставили мне задачу (пытались ставить, если по честному) - "Автоматизация заказа товара у поставщика".

И я тогда этот вопрос не решил.
Почему не решил?
Не смог я справиться с (для меня) плохо алгоритмизируемыми вещами:
  • Минимальный объем (сумма) поставки от данного поставщика слишком велик (сумма необходимого заказа, как правило, получалась меньше, поэтому надо брать что-то, что не является необходимым к данному сроку);
  • У ряда поставщиков есть понятие "скорость реакции" (т.е. я знаю, что через 3 дня после размещения заказа данный заказ будет доставлен), у других - я знаю, что заказ будет доставлен в определённый день недели, и не раньше;
  • Моё "любимое" - этому поставщику мы слишком много должны, поэтому надо взять у другого :);
  • И прочие, сейчас уже не вспоминающиеся вещи.

Что я хотел узнать - если кто-то разрабатывал алгоритмы "Автоматизированного заказа" - какие вещи в данном просчёте учитываются? Простейшие, сразу приходящие в голову, такие
  1. предпочтительный продавец (у Васи - это по 2 рубля, у Пети - по 2.20);
  2. минимальная партия, которую готов поставить продавец (Вася - 1'000 бутылок, Петя - 400 бутылок);
  3. скорость реализации товара (20 бутылок/день);
  4. минимальный товарный запас (в штуках или днях) (Я вот не понимаю, как его можно считать, если известно, что Вася поставляет товар в течении 2 дней после заказа, а Петя - через 7дней. Заказывать у Васи надо, когда хотя бы 60 бутылок осталось, а у Пети - когда 160);
  5. максимальное количество товара, которое мы можем принять (???)
  6. что-то ещё.

Для чего я этим интересуюсь?
В первую очередь - из-за любопытства :)
Интересно же - а как далеко всё шагнуло?
Второе - опять же интересно - а что считают?
А то я тогда варился в своём котле, и, сдаётся мне, делал массу ошибок, считая не то и не так (складывая 11 ручек и 7 чернильниц - получал 18 ... чего-то. Неизвестно чего, но ведь 11+7 дают всегда 18 в сумме, ведь правда :)).
И третье - а всё же, как считают?

Что меня вообще побудило написать всё это?
Наткнулся на статью с заголовком (словами?) - "Сегодня вы не купили презервативы, а магазин уже в курсе, когда вам понадобятся подгузники".
И понимаю, что я, похоже, отстал навсегда от современных технологий и систем.
Хочется ... если не догнать - то хотя бы понять принципы работы.
03.10.2013 17:29
Кто сможет правильно реализовать эту весьма нечеткую задачу того, наверное можно считать "компьютерным гением", но на самом деле данная задача не "имеет решения"....

К счастью сейчас (в 90х было по другому), когда товары представляются, как правило единственным поставщиком всё становится гораздо легче:

Имеем по каждому наименованию:

1. среднюю ежедневную продажу
2. срок обработки заявки и поставки товара
3. остаток товара на складе

исходя из этого на каждый товар знаем минимальный остаток, следовательно автоматически создаётся заявка поставщику (с учетом падения или роста спроса), где заказываемое количество "добивается" до минимальной партии... затем уже закупщик корректирует ручками заявку до "минимальной" суммы или внося "новые" позиции и отсылает поставщику....
03.10.2013 17:34
Пробегаю, потому только лишь напоминаю про сезонность и выходные дни, а отсюда и неочевидность расчета скорости реализации "штука/день", период может быть разный. Срок хранения, например. Возможность поставлять именно в этот магазин, если речь идет о сетевом расчете...
04.10.2013 09:42
Цитата:
AndreyZh Кто сможет правильно реализовать эту весьма нечеткую задачу того, наверное можно считать "компьютерным гением", но на самом деле данная задача не "имеет решения"....
А я-то надеялся, что имеет.... :(

Цитата:
AndreyZh К счастью сейчас (в 90х было по другому), когда товары представляются, как правило единственным поставщиком всё становится гораздо легче:

Имеем по каждому наименованию:

1. среднюю ежедневную продажу
2. срок обработки заявки и поставки товара
3. остаток товара на складе

исходя из этого на каждый товар знаем минимальный остаток, следовательно автоматически создаётся заявка поставщику (с учетом падения или роста спроса), где заказываемое количество "добивается" до минимальной партии... затем уже закупщик корректирует ручками заявку до "минимальной" суммы или внося "новые" позиции и отсылает поставщику....
Ну, в таких условиях - довольно легко, но это (IMHO) - "идеальный конь в вакууме".
Понятно, что в случае "замены" поставщика на РЦ - мы можем так поступать.

Т.е. всё это - арифметика, а мне интересен переход к математике (не обязательно к высшей). Мы интересно, как эта задача решается современными методами, с учётом интереса к "большим данным", современным ПО и т.п.
04.10.2013 10:09
Понимаешь, в чем проблема. Тут получается разрыв между квалификацией персонала в рознице и возможностями системы.
Если система предлагает заказать ХХ штук, то всегда есть товаровед магазина, который начинает кричать "Не надо нам столько, мы столько не продадим". И всё в итоге опять скатывается к банальной арифметике.
А так - да, BI, Data Mining и всё прочее.
04.10.2013 13:05
Про товароведа - очень хорошо понимаю.
Равно и про то, что он может быть "заинтересован" поставщиком, и начать кричать - "XX - это мало!!!"

Ещё раз попробую сформулировать вопрос - решают ли современные системы автоматизации торговли вопрос "автоматического заказа", при условиях, что товар:
1) Может быть заказан у разных поставщиков
2) У этих поставщиков разные цены поставки товара
3) У этих поставщиков разные условия поставки товара (минимальная партия, максимальная партия, необходимый ассортимент поставки (мы можем взять у поставщика А водку по 50рублей, если возьмём у него мангалы по 300 рублей. При этом количество мангалов должно быть равно количеству ящиков водки; а у поставщика Б эта же водка стоит по 60 рублей, но мангалы брать не надо), сумма товарного кредита, количество поставок в товарном кредите, сроки отсрочки платежей и т.д.)

И если да - то как?
Прописываем "коэффициенты значимости" для различных величин, с тем, что бы можно было сравнивать "мягкое" и "сладкое"?

"Коэффициенты значимости", к примеру, у нас прописывались для понимания "наиболее продаваемого товара". Понятно, что мы можем выбрать товар, продаваемый:
  • в максимальных количествах,
  • с максимальной маржой,
  • на максимальную сумму
А как эти показатели "соединить"? Только через эти самые "коэффициенты".
Для штук - у нас был коэффициент 0.9, для суммы продажи - 1.1, для маржи - 1.4 (1.5? не помню, давно было. Чем были обоснованы - тоже не вспомню).
07.10.2013 12:27
Такие системы есть, например JDA всё это поддерживается кроме вот этого:
(мы можем взять у поставщика А водку по 50рублей, если возьмём у него мангалы по 300 рублей. При этом количество мангалов должно быть равно количеству ящиков водки; а у поставщика Б эта же водка стоит по 60 рублей, но мангалы брать не надо)

Таких процессов нет ни у одной сети, которая может себе позволить решения такого класса.
Никто уже давно не сравнивает теплое с мягким т.к. место в магазинах на которое ты можешь поставить мягкое уже давно продано другому поставщику теплого или холодного.
20.11.2015 14:38
подскажите все таки какую систему выбрать?
23.11.2015 05:05
вам для чего надо, ресторан или цех по производству еды?
23.11.2015 05:06
вот посмотрите вакуматор тут ...
отличные модели
Часовой пояс GMT +3, время: 07:32.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.