Информационные технологии

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

SCM & IT. Who is where... part I

Информационные системы и SCM. Кто есть где.
 

Отмазки (disclaimer).

Зачем я все это пишу? Применение ИС к управлению цепочками поставок на просторах xUSSR пока еще мало распространено. Если и не зачаточное состояние, то уж младенческое точно. Хочется немного остановиться на этом вопросе, поскольку существует явно выраженная потребность сегодняшнего бизнеса в хороших и удобных инструментах управления цепями поставок, при этом существующий рынок остается совершенно непрозрачным даже для специалистов, не говоря уже о потенциальных потребителях.
Несколько прошедших в последнее время конференций лишь подтвердили большой интерес к этой теме со стороны профессионалов, обеспечивающих ежедневное управление потоком ценностей.

Лирическое отступление.

Да-да-да, я опять про кризис. Во-первых, по закону жанра надо бы как-то зацепить читателя, задеть его за живое, а во-вторых пресловутый кризис со всей очевидностью продемонстрировал недостатки системы управления запасами в наших компаниях. До этой черты мы как правило работали в условиях либо стабильного, либо стабильно растущего рынка, вот в чем фокус. Что это означает для управления запасами? Прежде всего малую цену ошибки. Образовался дефицит - заработали меньше, но за счет другой номенклатуры общую рентабельность вытягиваем "не хуже, чем обычно". Закачали в трубу цепочки поставок больше, чем надо - плохо, тяжело, но на растущем рынке достаточно немного прикрутить краник на входе, и через разумное время "само рассосется". Тем более, что существующая система мотивации как служб продаж, так и служб закупок чаще всего провоцирует "заложиться" по максимуму. Организовали график поставок абы как? да кто это заметит, рентабельность все покрывает.

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

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

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

Раз ликвидного ассортимента не хватает, доходная часть сокращается, бюджет начинает расползаться, приходится сокращать расходную часть. Быстро сократить расходы можно только за счет персонала, снижения арендных ставок, распродажи части (желательно непрофильных) активов. Последнее, впрочем, затруднительно, ибо где сейчас найти покупателя, расширяющего свой бизнес?

Каким образом реагирует сложивщаяся система управления? Да привычным! Подать сюда Пупкина, накрутить ему хвоста за избыточные запасы. Пупкин на свое усмотрение снизит заказы на 20%, вот только не решит это проблему, поскольку происходит борьба со следствием. И вообще, такое, с позволения сказать, управляющее воздействие мне сильно напоминает рассказ Эдварда Деминга:

На одном из автомобильных предприятий известной азиатской страны работал станок с ЧПУ. Станок точил вал для коробки передач, причем у него стояла система контроля качества по обратной связи: на выходе измерялся диаметр вала, если наблюдалось отклонение от положенного, в систему управления вводилась поправка. Результат - дикое количество брака. Во всяком случае, по меркам азиатского завода. Что было предложено первым делом - отключить систему корректировки. После первой же недели измерения четко показали, что количество брака явно уменьшилось. Причина для любого, знакомого со статистикой, тривиальна: станок (Система) работал в рамках отклонений, определенных его устройством, технологией и материалом. Любое корректирующее воздействие приводило лишь к тому, что помимо "естественных" отклонений результата от номинала добавлялось отклонение на величину воздействия, что в итоге приводило к увеличению размаха.

Так же и реакция Системы в виде наказания Пупкина. Помимо "люфтов" самой системы мы добавляем еще одно неконтролируемое возмущение, разве тут можно ждать устойчивости и предсказуемости? Не зря же считается, что в любом результате доля исполнителя - не более 5%, остальное обусловлено свойствами Системы. Есть даже прецеденты компаний, где в принципе не существует формальных наказаний исполнителя, ибо считается, что вина за брак в работе - следствие свойств самой Системы.

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

И вот тут уж, как водится, на сцену выходят информационные технологии. Понятно, что если компания имеет размер более 10 человек, без систем учета, контроля и, соответственно, управления никуда.

SCM & IT. Who is where... part II

Лирическое отступление.

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

  • учет
  • контроль
  • анализ
  • определение политики управления
  • планирование
  • исполнение

При первом взгляде здесь все на месте, именно в такой последовательности менеджер изо дня в день крутится в этом цикле. Я, однако, хочу обратить внимание на коренной недостаток такой картины. Да нет, недостаток - это сказано слабо. Тут имеет место быть целая парадигма, принцип управления, когда Лицо, Принимающее Решения, реагирует на уже случившиеся факты. Способ управления, известный как "тушение пожаров". Если не перевернуть кое-что в собственной голове, мы так и будем заниматься этим самым тушением. А нужно-то немного, сначала изменить последовательность действий:

 а затем признать, что

  • каждый уровень является производным от более верхнего, так что
  • если в результате анализа ситуации мы получили совсем не то, к чему стремились,
  • значит нужно не только (даже не столько) тушить этот пожар,
  • а прежде всего обнаружить тот самый шаг, на котором возникла причина расхождений;
  • четко понять, что привело к такому результату;
  • отделить системные причины от случайных;
  • принять решения, которые устранят системные причины (помните про станок???) возникновения расхождений в будущем.

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

Классификация по уровням принятия решения

 

Политика управления:

Определение стратегии развертывания

  • Целевые сегменты
  • География распространения
  • Товарные категории и объемы

Исключительно маркетинговая задача, так что в современном понимании supply chain management не включает в себя решение таких задач. Но обсуждать программное обеспечение на этом уровне я не буду по другой причине: мне таковое просто неизвестно. Конечно, существуют специфические пакеты типа SPSS, но они закрывают такую мизерную часть этой огромной и очень сложной работы, что и говорить не о чем.
На основании полученных на этом шаге данных нужно решить проблемы следующего уровня:

Использование ресурсов

  • Размещение центров обслуживания клиентов и промежуточных складов
  • Целевой уровень обслуживания
  • Выбор поставщиков
  • Оптимальные политики пополнения

Вот здесь как правило начинается епархия SCM, это стратегический уровень управления цепями поставок. Программные решения этого класса пока не имеют устоявшегося наименования и аббревиатуры (как ERP, например), отличить их можно по присутствию в названии чего-то вроде Global SCM Optimization, Inventory Optimization, Strategy Planning. Также в последнее время начали применять пакеты имитационного моделирования.

Определение операционных процессов

  • организационная структура
  • функции, полномочия, ответственность подразделений
  • процессы
  • информационные потоки
  • технологии
  • контроль и мотивация

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

SCM & IT. Who is where... part III

Планирование

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

Решение этой задачи естественным образом распадается на две независимые подзадачи, выполняемые последовательно.

Определение спроса на будущий период времени.

Грубо говоря, под какой расход должна подстроиться система поставок. Особо хочу обратить внимание на вот это "грубо говоря". Дело в том, что менеджмент часто не делает различия между

  • потребностью рынка (спросом) и планом продаж (отгрузок)
  • потребностью рынка (спросом) и фактическими продажами (отгрузками)

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

Все системы прогнозирования прогнозируют СПРОС (объективная реальность), но не продажи. На вход процесса прогнозирования должна быть подана информация об истории СПРОСА, и на выходе мы получим прогноз СПРОСА. Отсюда следуют два вывода:

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

Итак, для планирования нам необходимо спрогнозировать расход по каждому продукту в каждом ЦОК с заданной точностью по времени и на заданный горизонт планирования.
Вот такая простая задачка. Прочувствуйте, для скромной сеточки в 10 магазинов и 50 тыс. номенклатуры мы должны вычислить понедельный расход по каждому из 500 тыс. SKU. И делать это нужно опять же каждую неделю. Поэтому понятно, что карандашом на листке бумаги такое уже не сделаешь принципиально, отсюда и повсеместная компьютеризация.

Если у меня "под крылом" небольшое количество SKU, я, возможно, обойдусь и электронными таблицами. Правда, мне не верится, что товар у меня имеет настолько "хорошую" историю продаж, что встроенных средств таблиц хватит, а значит нужно либо писать собственные подпрограммы (а кто это будет делать?), либо брать специализированные пакеты статистической обработки.

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

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

Подобные инструменты существуют и в составе систем класса ERP, и в составе специализированных пакетов управления класса DRP, и как отдельные решения. Каждый вариант имеет свои плюсы и минусы, впрочем и вариант электронных таблиц тоже их имеет.
Но об этом чуть позже, что же мы имеем на рынке? Отдельные приложения или модули в составе комплексов, в названии которых имеется что-то типа Demand Forecasting. Таковых уже на порядки больше, чем мы имели на стратегическом уровне.

Планирование пополнения системы товародвижения.

Итак, мы получили прогноз спроса по каждой номенклатуре по каждому центру обслуживания. Теперь у нас появляется возможность спланировать поставки, чтобы удовлетворить этот спрос с нужным уровнем обслуживания. Прежде всего, не будем забывать, что спрос и реальный план продаж - две вещи разные. Может случиться так, что наша система с ее ограничениями не способна выполнить задачу по объективным причинам - не успеем закупить, не хватит размера склада, не справится транспорт или завод, ... список можете продолжить сами. Хороший модуль планирования знает про ограничения системы и умеет если не планировать с их учетом, то хотя бы сигнализировать о нарушениях таких ограничений.

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

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

Понятно, что не все эти факторы актуальны для всех компаний с одной стороны, а с другой - список явно неполон. Но существующие программные решения стараются в меру сил учесть все эти моменты, ибо пропуск хотя бы одного сразу ведет к увеличению издержек. И решения эти опять же могут быть как модулями в составе ERP, так и модулями в составе DRP(1,2,...). Как правило, в названии будет что-нибудь из разряда Replenishment Planning. Решения такого уровня без проблем расчитывают СОГЛАСОВАННЫЙ план по всем SKU с нужной точностью за один проход.

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

Исполнение.

Здесь мы выходим на операционный уровень управления. План работ составлен, теперь эта информация переезжает к исполнительным механизмам, коих уже существует море разливанное. Прежде всего - это поддержка документооборота. Если сформированы потребности в закупке, они трансформируются в конкретные документы, обеспечивается их конкретная форма, контроль исполнения. Для этого используются учетные системы или функционал ERP. Если сформирован мастер-план производства, он подается на вход Manufacturing Execution System (MES). Если сформирован план дистрибуции, задания на отгрузку поступают на вход Warehouse Management System (WMS). Абсолютно то же самое происходит с транспортом и другими операционными подразделениями.
Как видим, на этом уровне управления появляется целый букет всяких management systems: ERP, Wms, CTms, Yms, Tms, Dms, MES... Опять мы встречаемся с ситуацией, когда на более низком уровне степень автоматизации процессов гораздо выше.

Контроль.

Здесь все совершенно очевидно и уже давно является вчерашним днем. Есть управленческий (да и бухгалтерский) учет, есть система отчетности разной степени детализации. Все это совершенно спокойно поддерживается учетной системой предприятия, даже если она не носит гордого звания ERP.


Итого:

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

SCM & IT. Who is where... part IV

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

Если продолжить ассоциацию, то мы получим соответствие

Политика управления 0. ЦПР - Отдел Главного Технолога
1.конвейер будет выпускать шалабуху с гайкой
2.длина конвейера 10м, форма - буквой ЗЮ
3.будет установлено 9 роботов-накрутчиков гаек на шалабуху и 1 робот-укладчик в ящик
Планирование 0. ЦПР - Центральный Процессор управления конвейером
1.заготовки на вход подавать со скоростью 1шт/сек
2.робот за 0.5 сек до подхода шалабухи правым манипулятором берет из отсека №3 гайку
3.при подходе левым манипулятором фиксирует ш. и правым накручивает гайку
Исполнение 0. ЦПР - Большая Интегральная Схема (чип) управления роботом
1. звено правого манипулятора №1 установить под 78 градусов к вертикали
2. звено №2 согнуть под 95 градусов по отношению к №1
3. совместить звенья 3а,3б,3в так, чтобы зафиксировать гайку.
.........
Учет и контроль сколько подано заготовок
сколько на выходе изделий
процент брака
израсходовано масла на ТО
ремонты
........

Думаю, каждый может придумать свою детскую картинку.

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

 

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

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

Формализуемые процедуры.

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

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

Входная информация:

  • сумма проводки
  • счет-кредит
  • счет-дебет

Тогда процедура

  1. получить сумму остатка на кредитуемом счете
  2. уменьшить ее на сумму проводки
  3. получить сумму остатка на дебетуемом счете
  4. увеличить ее на сумму проводки
  5. конец транзакции

После того, как мы написали это на бумаге, можем все это запрограммировать. Почему вообще бухгалтерия - самая автоматизируемая и самая автоматизированная область? Все очень просто. Там все процедуры уже за нас формализовали законами и инструкциями, 90% работы сделано, осталось только перевести это все в электронный вид. Поэтому автоматизация в этой области проходит для любой компании легко и безболезненно, а значит нет "неудавшихся проектов".
В любой другой области внедрение решений обычно связано с изменением каких-то или многих процедур, поскольку нет единых, узаконенных методов работы. Правда, существуют общепринятые, те самые пресловутые best practices (ой, не люблю я почему-то это словосочетание!). Более того, сплошь и рядом фактически принятые в компании методы работы либо в принципе не могут быть формализованы, либо менеджмент не испытывает желания приводить их к формальному виду.
Отсюда растут ноги у

Мифа №1
Вот поставим Крутую Информационную Систему (КИС), и она нам все приведет в порядок. Будем нажимать на Большую Зеленую Кнопку (БЗК) и получать результат.

Я думаю, все уже поняли, к чему я веду. БЗК не бывает, волшебные палочки проходят по другому ведомству. А все из-за того, что невозможно формализовать все процедуры. Так что делаем выводы: чем больше нам удастся формализовать, тем больше потенциально можно автоматизировать. Но формализация не только средство (да и не столько, откровенно говоря), она имеет собственную ценность, и, возможно, гораздо большую. Как только процедура формализована, получение нужного результата ГАРАНТИРОВАНО вне зависимости от исполнителя, помните? Ну а уж следить, чтобы исполнитель двигался исключительно по регламенту - это уж, извините, другой контур управления, здесь об этом не будем.

Мы лучше обратим внимание на обратный

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

Я хотел бы спросить, ваша компания занимается разработкой Единой Теории Поля? Нет? Может быть, Теорией Всеобщего Счастья? Тоже нет? Так чем же, не томите!
Ах, вы занимаетесь производством и/или поставками продуктов и/или услуг! Что ж вы молчали, мы уже идем к вам, ибо вне зависимости от свойств продукта или услуги, львиная доля процессов в таких компаниях по сути неотличима. Даже свойства продукта, существенные для процессов управления в цепи поставок, везде одинаковы.

Так что можно сказать с уверенностью даже с закрытыми глазами, что уж 80-то процентов процедур совершенно одинаково формализуемы. А правда состоит в том, что регламентация процессов на самом деле просто невыгодна по разным причинам самим менеджерам. К тому же невредно напомнить старую истину: "Люди всегда будут противиться любым изменениям. Даже вопреки собственной выгоде". И аргументы под это будут выискивать с удивительной изобретательностью.

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

  1. Рассчитать точность прошлых прогнозов (определение методики) по существующей модели.
  2. Если удовлетворительно (определение нормативов), рассчитать по прежнему алгоритму.
  3. Если неудовлетворительно
    1. Определить список альтернативных моделей (ограничить список).
    2. По каждой рассчитать ошибку (определение методики).
    3. Выбрать лучшую модель
    4. Рассчитать по выбранной модели.
  4. Утвердить прогноз.
  5. Зафиксировать в ИС для последующего план-фактного анализа

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

SCM & IT. Who is where... part V

А надо ли вообще хоть что-то автоматизировать, коли априори понятно, что полностью это сделать не удастся, а все вроде "и так работает"? Хороший вопрос, и отвечать на него нужно с осторожностью.

Так и представляется диалог:

- у вас бухгалтерская программа стоит?
- конечно!
- а зачем? ведь жили как-то раньше, писали в амбарных книгах, баланс сводили как-то, перед налоговой отчитывались?
- да вы что? мне сейчас для этого штат бы понадобился больше, бухгалтеры бы занимались складыванием цифр вручную (за их-то немаленькую зарплату), к тому же они имеют скверную привычку делать ошибки, а найти их потом крайне сложно. да и ошибка в отчетности чревата такими штрафами, что уж лучше вложить немного денег и добиться ГАРАНТИРОВАННОСТИ результата.

BINGO!
Вполне разумное рассуждение, не находите? А теперь попробуйте заменить слово "бухгалтер" на, например, "закупщик". Не находите, что все это рассуждение можно повторить от А до Я без всяких изменений? Только ошибка будет не в отчетности, а в инвестировании реальных денег, и штрафы проявятся также вполне реально в виде потерь от перекосов товарного запаса.

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

Выбираем программное обеспечение.

Итак, мы приняли решение. нашей supply chain нужен не просто management, но и толика автоматизации. Более того, мы выделили критические участки трубы, на которых автоматизация даст эффект. На что же обратить внимание?

Ваш покорный слуга как из врожденной любознательности, так и по долгу службы попытался изучить рынок SCM Software, в результате чего сформировались некоторые выводы и наблюдения. Прошу иметь в виду, это лишь личное мнение автора, не претендующее на истину в последней инстанции. Если у кого-то имеются собственные наблюдения, опровергающие или дополняющие изложенное ниже - you're welcome, на этом сайте можно как комментировать статьи, так и писать собственные. Думаю, это будет полезно очень многим.

Если в названии системы управления присутствует аббревиатура SCM, это не говорит ни о чем.

Кроме шуток. Необходимо понять, ЧТО делает система НА САМОМ ДЕЛЕ. Прочтите внимательно функционал. Посмотрите на диаграмму классификации, предложенную автором, поймите, к какому уровню управления она принадлежит. Оцените, какой участок вашей работы она будет закрывать. Иначе может получиться, что под SCM производитель предлагает поддержку адресного хранения на складе или учет товара в пути (примеры невыдуманные). Имеет право, кстати, ибо это тоже часть управления трубой.

"Приблизься к оленю". Не только ЧТО, но и КАК? К примеру, обе программы заявляют о возможности планирования с учетом EOQ. Только одна потребует ввести его вручную, а другая рассчитает самостоятельно. Обе декларируют прогнозирование сезонных товаров, но одна профиль сезонности посчитает сама, а вторая опять же потребует ввести вручную.
Имеет смысл также интересоваться? каких исходных данных требует система. Бывает так, что возможность расчета декларируется, но в исходных данных явно не хватает для этого параметров. Как говорил Козьма Прутков, Бди!

Если производитель заявляет о себе как о всемирно признанном лидере отрасли, это не говорит ни о чем.

Поройтесь в интернете, там этих лидеров столько, что миров на всех не хватит.

"Мы решим все ваши проблемы" - наглая ложь или наивная простота.

Волшебные палочки проходят по соседнему ведомству, об этом мы уже поговорили. Имейте в виду, что если вы общаетесь со службой продаж поставщика, там по определению не могут знать всех тонкостей. Ну а на что мотивирован сейлз, не мне вам рассказывать. Более того, автор слышал сплетню, что многие компании специально не дают всей информации сейлзам: во-первых, зачем забивать голову лишним, но самое главное - человек должен быть внутренне убежден, что "Мы решим все ваши проблемы". Гораздо легче убеждать другого, если уверен сам, не так ли? Выражаясь языком Тарасова, сейлзу таким образом обеспечивается право на незнание. Ну, сплетня - она сплетня и есть.

Оценить эффект от внедрения программного решения объективно невозможно, это лукавство.

Не шучу. Посудите сами:

  • Чем более «запущена» ситуация до того, тем круче эффект.
  • Как ни крути, течение процессов изменится, что приведет к косвенным эффектам. Даже простое освобождение персонала от рутинных операций позволяет ему переключиться на задачи, до того откладываемые или недостаточно проработанные.
  • Как правило, до, во время и после внедрения в компании происходят и другие изменения, приводящие к изменению структуры, процессов, происходят сдвиги или эволюция рынков, так что выделить эффект только одного мероприятия невозможно.
  • Самые главные, самые важные показатели бизнеса нельзя измерить количественно.
  • Процессы становятся более управляемыми. Необязательно резко повысится точность прогнозирования, но само введение системности гарантирует, что ситуация не выйдет из-под контроля даже из-за проблем с персоналом.

Необходимое условие успешности проекта — партнерские отношения между командами.

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

http://www.zdnet.com/blog/projectfailures/understanding-marin-countys-30...

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

 

 


Итак, что же такое автоматизация управления?
Это лишь удобный и точный инструмент, позволяющий быстро выполнять стандартизованные процедуры. Тем самым, это лишь 5% решения задачи. Остальные 95 лежат в области чисто управленческой - разработка и стандартизация бизнес-процессов, описание информационных потоков, их поставщиков и потребителей, и пр., и пр.
Воспринимать ИС как некую волшебную палочку, которая неведомым образом изменит саму стратегию управления, - значит обманывать самого себя.

Обзор программного обеспечения для автоматизации управления запасами

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

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

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

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

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

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

Внимание! Все данные, приведенные в таблицах, предоставлены разработчиком или его представителем, за соответствие их истине сайт ответственности не несет.
Прикрепленный файлРазмер
Check List for IT solutions_en.doc54.5 кб
Check List for IT solutions_ru.doc67 кб

Deductor Inventory Stock Optimization

Название: Deductor Inventory Stock Optimization
Производитель: BaseGroup Labs
Официальные представители:
http://www.basegroup.ru/partners/list/

 

Блок "Прогнозирование спроса"

возможность "чистки" истории продаж
автоматическое детектирование выбросов
реакция на выбросы для упорядоченных данных:
редактирование – с помощью
робастной фильтрации,
сглаживание – с
использованием алгоритмов БПФ,
вейвлет-анализ
исключение нестандартных продаж
исключение рекламных продаж и прочих маркетинговых результатов
исключение влияния out-of-stock на отгрузки
используемые математические модели
простое скользящее среднее
взвешенное скользящее среднее
поддержка определенных пользователем профилей сезонности
простое экспоненциальное сглаживание
экспоненциальное сглаживание с учетом тренда (Holt)
экспоненциальное сглаживание с учетом сезонности (Winters)
ARIMA
прогнозирование редких продаж
Croston
log-Croston (Boylan)
Willemain
Другая  
линейная регрессия
классическая
множественная
Фурье
Другая  
Другие модели
Нейросеть
Мультипликативная модель
Декомпозиция
Аддитивная модель
Оценки точности прогнозирования
расчет величины ошибки модели
расчет величины отклонения факта от прогноза
метод оценки
среднеквадратическое отклонение (MSE)
абсолютное процентное отклонение (MAPE)
другая оценка
среднее процентное отклонение (MPE)
среднее процентное отклонение (MAD)
Возможность использования для прогнозирования жизненных циклов товара
Возможность включения планов продвижения в итоговый прогноз
Возможность расчета прогнозов по всей номенклатуре за один проход
Возможность расчета прогнозов по части номенклатуры на основании пользовательского фильтра

 

Блок "Планирование поставок" (включая закупки, собственное производство и дистрибуцию)

Возможность сквозного планирования товаропроводящей сети в целом
Возможность использования разных цепочек поставок для разных товаров
Возможность автоматической консолидации закупок по каналам/поставщикам
Стратегии формирования размера поставки
с постоянным периодом
с постоянным размером
с размером, соответствующим EOQ
ручной минимакс
с постоянным максимальным уровнем
автоматическое определение размера по критерию максимизации прибыли
Стратегии формирования страхового запаса
установка вручную
установка по времени покрытия страховым запасом прогнозного спроса
установка по статистическим данным
по целевому уровню обслуживания с учетом вариативности спроса
по целевому уровню обслуживания с учетом вариативности времени исполнения заказа
автоматическое определение уровня по критерию максимизации прибыли с учетом всех вариаций
другое  
виды уровня обслуживания
1-го типа ( 1 - вероятность обнуления)
2-го типа ( 1 - вероятный размер упущенного спроса)
3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа)
используемые при расчетах вероятностные распределения
нормальное
логнормальное
показательное
пуассоновское
другие
   
Учет уже размещенных заказов на закупку/производство
Учет товара в пути
Учет поступивших заказов клиентов
Учет каннибализации (взаимного влияния аналогов)
Учет сроков годности товара
Учет затрат времени на доставку
Учет затрат времени на производство
Учет минимальной партии

 

Блок "Управление поставщиками"

 

Номенклатурная матрица поставщика
Время исполнения заказа
Стоимость доставки
Условия оплаты
Дисциплина исполнения заказа

на основании определения
надежности и качества

Другое
   
Процедура выбора оптимального поставщика товара

 

Блок "Отчеты, аналитика, оптимизация"

ABC анализ
XYZ анализ
План-график платежей поставщикам
План-график отгрузок клиентам
План поступлений денежных средств
План-график внутренних перемещений товара
План-график размера запаса
Планируемая оборачиваемость запаса
Планируемая рентабельность инвестиций в запас (GMROI)
План-график загрузки транспорта
План-график использования складских площадей
Ожидаемые дефициты
Ожидаемые сверхнормативные запасы
Расчет EOQ
Расчет оптимального размера страхового запаса
Расчет оптимального уровня обслуживания
Другое
Расчёт рентабельности товаров, её динамики
Расчёт оборачиваемости товаров, её динамики
Расчёт ликвидности товаров
Неликвидные товары
Рейтинг товаров
Динамика стоимости товара
Рейтинг товаров с учетом аналогов заменителей
Расчет среднего товарного запаса на складе по товарам
Расчёт скорости товарооборота
Расчёт времени обращения товаров
Расчёт готовности к поставке
Расчёт доли запасов в обороте
Расчёт доли неликвидного товара в обороте
Расчёт затрат на связанный капитал
Дисциплина поставок
Эффективность работы логистики
Расчёт «Интенсивность работы склада»
Эффективность использования складских площадей
Сохранность грузов
Экономическая эффективность использования склада
Оценка хранения товара
Расчёт экономической выгоды
Расчёт затрат
Оценка планирования и прогнозирования

 

Блок "Технические детали"

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

можно сказать, что не ограничено

операционная система

Минимум - Windows 2000, желательно - Windows XP, 2003

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

драйвера к нужной БД

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

 

Легенда:

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

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

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

исключение влияния out-of-stock на отгрузки:
Ситуация нехватки товарного запаса - не редкость, отклонение объема продаж от реального спроса в этом случае сильно искажает реальную картину. Нам необходимо учитывать этот фактор для более адекватного прогнозирования

поддержка определенных пользователем профилей сезонности:
Пользователь может вручную задать коэффициенты сезонности для товара

расчет величины ошибки модели:
После расчета модели по прошлым данным она сравнивается с фактическими данными за этот же период

расчет величины отклонения факта от прогноза:
После расчета модели строится прогноз на несколько периодов вперед. После прохождения этого времени рассчитывается отклонение построенного в прошлом прогноза с реализовавшимся фактом

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

Возможность использования разных цепочек поставок для разных товаров:
В магазин М товар А едет по пути РЦ1->РЦ2->М, а товар Б - по пути РЦ5->РЦ8->М

Возможность автоматической консолидации закупок по каналам/поставщикам:
Система умеет потребности в товаре консолидировать по поставщикам и формировать единый заказ для каждого из поставщиков

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

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

уровень обслуживания 1-го типа ( 1 - вероятность обнуления):
95% означает, что из 100 циклов поставок лишь в 5 запас к концу цикла обнулится

уровень обслуживания 2-го типа ( 1 - вероятный размер упущенного спроса):
95% означает, что из 100 единиц, заказанных клиентами, не хватит 5 единиц

уровень обслуживания 3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа):
95% означает, что из 100 заказов лишь в 5 появится хотя бы одна строка, на которую запаса не хватит

клиент-серверная архитектура, толстый клиент:
Для доступа к серверу используется специальная клиентская программа

клиент-серверная архитектура, тонкий клиент:
В качестве клиента используется web-browser

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

поддержка пользовательских характеристик товара:
Пользователь может определять собственные характеристики товара: ABC, товарная категория, закрепленный менеджер, основной/ассортиментный и пр.

Дополнительные комментарии производителя: 

Решение Deductor Inventory Stock Optimization разработано на базе аналитической платформы Deductor (http://www.basegroup.ru/deductor/description/). Данная платформа является идеальной средой для создания законченных аналитических решений. Реализованные в ней технологии позволяют на ее базе пройти все этапы построения аналитической системы: от создания хранилища данных до автоматического подбора моделей и визуализации полученных результатов.

Аналитическая платформа Deductor:

  • Поддерживает современные технологии анализа структурированных данных: Data Warehouse, ETL, OLAP, Knowledge Discovery in Databases и Data Mining.
  • Предоставляет аналитикам инструментальные средства, необходимые для решения самых разнообразных аналитических задач: аналитическая отчетность, прогнозирование, сегментация, поиск закономерностей.
  • Включает самые мощные технологии анализа данных: статистические и эконометрические модели, многомерный анализ, нейронные сети, деревья решений, самоорганизующиеся карты, спектральный анализ и множество других.
  • Позволяет снизить требование к подготовке персонала благодаря использованию самообучающихся алгоритмов и мастеров для настройки, делая современные технологии доступными широкому кругу пользователей.
  • Позволяет отобразить результаты при помощи десятков удобных визуализаторов. Система самостоятельно анализирует, что и каким образом отображать, предлагая пользователю оптимальный вариант.
  • Совместима практически со всеми популярными учетными системами, базами данных и форматами файлов.

 

Forecast NOW!

 

Название: Forecast NOW!

Производитель: Ingenious Team

Официальные представители: fnow.ru

 

Блок "Прогнозирование спроса"

возможность "чистки" истории продаж
автоматическое детектирование выбросов 
реакция на выбросы восстановление данных
исключение нестандартных продаж 
исключение рекламных продаж и прочих маркетинговых результатов 
исключение влияния out-of-stock на отгрузки 
используемые математические модели
простое скользящее среднее  
взвешенное скользящее среднее  
поддержка определенных пользователем профилей сезонности   
простое экспоненциальное сглаживание  
экспоненциальное сглаживание с учетом тренда (Holt)  
экспоненциальное сглаживание с учетом сезонности (Winters)  
ARIMA

 

Нейронные сети

  

Генетические алгоритмы

  

Многофакторная нелинейная регрессия

  

прогнозирование редких продаж
Croston  
log-Croston (Boylan)  
Willemain  

Другая

Деккер

Эфрон

 

 

линейная регрессия
классическая  
множественная
Фурье
Другая  
Другие модели

Нейросеть

Генетические алгоритмы

Многофакторная нелинейная регрессия

Оценки точности прогнозирования
расчет величины ошибки модели 
расчет величины отклонения факта от прогноза 
метод оценки
среднеквадратическое отклонение (MSE)
абсолютное процентное отклонение (MAPE)
другая оценка

нормированное среднеквадратичное отклонение (NRMSD)

симметричное абсолютное процентное отклонение (sMAPE)

взвешенное абсолютное процентное отклонение (WAPE)

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

 

Блок "Планирование поставок" (включая закупки, собственное производство и дистрибуцию)

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

 

Блок "Управление поставщиками"

 

Номенклатурная матрица поставщика   
Время исполнения заказа
Стоимость доставки  
Условия оплаты  
Дисциплина исполнения заказа
Другое
   
Процедура выбора оптимального поставщика товара

 

Блок "Отчеты, аналитика, оптимизация"

ABC анализ
XYZ анализ
План-график платежей поставщикам  
План-график отгрузок клиентам  
План поступлений денежных средств  
План-график внутренних перемещений товара
План-график размера запаса   
Планируемая оборачиваемость запаса  
Планируемая рентабельность инвестиций в запас (GMROI)
План-график загрузки транспорта  
План-график использования складских площадей
Ожидаемые дефициты  
Ожидаемые сверхнормативные запасы  
Расчет EOQ  
Расчет оптимального размера страхового запаса
Расчет оптимального уровня обслуживания
Другое
 

 

Блок "Технические детали"

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

потенциально не ограничено

операционная система

кроссплатформенное ПО

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

не требуется

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

 

Легенда:

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

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

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

исключение влияния out-of-stock на отгрузки:
Ситуация нехватки товарного запаса - не редкость, отклонение объема продаж от реального спроса в этом случае сильно искажает реальную картину. Нам необходимо учитывать этот фактор для более адекватного прогнозирования

поддержка определенных пользователем профилей сезонности:
Пользователь может вручную задать коэффициенты сезонности для товара

расчет величины ошибки модели:
После расчета модели по прошлым данным она сравнивается с фактическими данными за этот же период

расчет величины отклонения факта от прогноза:
После расчета модели строится прогноз на несколько периодов вперед. После прохождения этого времени рассчитывается отклонение построенного в прошлом прогноза с реализовавшимся фактом

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

Возможность использования разных цепочек поставок для разных товаров:
В магазин М товар А едет по пути РЦ1->РЦ2->М, а товар Б - по пути РЦ5->РЦ8->М

Возможность автоматической консолидации закупок по каналам/поставщикам:
Система умеет потребности в товаре консолидировать по поставщикам и формировать единый заказ для каждого из поставщиков

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

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

уровень обслуживания 1-го типа ( 1 - вероятность обнуления):
95% означает, что из 100 циклов поставок лишь в 5 запас к концу цикла обнулится

уровень обслуживания 2-го типа ( 1 - вероятный размер упущенного спроса):
95% означает, что из 100 единиц, заказанных клиентами, не хватит 5 единиц

уровень обслуживания 3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа):
95% означает, что из 100 заказов лишь в 5 появится хотя бы одна строка, на которую запаса не хватит

клиент-серверная архитектура, толстый клиент:
Для доступа к серверу используется специальная клиентская программа

клиент-серверная архитектура, тонкий клиент:
В качестве клиента используется web-browser

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

поддержка пользовательских характеристик товара:

 

Inventor

Название: Inventor
Производитель: Inventor Soft (ООО «Инвентор Софт»)
mailto:info@inventorsoft.ru
тел: 8 499 232 7256

http://www.inventorsoft.ru

Блок "Прогнозирование спроса"

возможность "чистки" истории продаж
автоматическое детектирование выбросов
реакция на выбросы В модуле «Верификация и фильтрация» системы «Инвентор» по заданным критериям выделяются нехарактерные по масштабу отгрузки. По согласованной с Заказчиком процедуре транзакции либо удаляются, либо сохраняются для учета при оптимизации.
исключение нестандартных продаж В модуле «Верификация и фильтрация» системы «Инвентор» по заданным критериям выделяются подозрительные (нехарактерные) отгрузки, например, отгрузки «под заказ». По согласованной с Заказчиком процедуре транзакции либо удаляются, либо сохраняются для учета при оптимизации.
исключение рекламных продаж и прочих маркетинговых результатов
исключение влияния out-of-stock на отгрузки
используемые математические модели
простое скользящее среднее
взвешенное скользящее среднее
поддержка определенных пользователем профилей сезонности
простое экспоненциальное сглаживание
экспоненциальное сглаживание с учетом тренда (Holt)
экспоненциальное сглаживание с учетом сезонности (Winters)
ARIMA
прогнозирование редких продаж
Croston
log-Croston (Boylan)
Willemain
Другая В системе «Инвентор» реализован оригинальный метод прогнозирования редких продаж
линейная регрессия
классическая
множественная
Фурье
Другая  
Другие модели
Оценки точности прогнозирования
расчет величины ошибки модели
расчет величины отклонения факта от прогноза
метод оценки
среднеквадратическое отклонение (MSE)
абсолютное процентное отклонение (MAPE)
другая оценка
коэффициент детерминации
Возможность использования для прогнозирования жизненных циклов товара
Возможность включения планов продвижения в итоговый прогноз
Возможность расчета прогнозов по всей номенклатуре за один проход
Возможность расчета прогнозов по части номенклатуры на основании пользовательского фильтра

 

Блок "Планирование поставок" (включая закупки, собственное производство и дистрибуцию)

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


реализуется как частный случай

с постоянным размером
реализуется как частный случай
с размером, соответствующим EOQ
реализуется как частный случай
ручной минимакс
реализуется как частный случай
с постоянным максимальным уровнем
реализуется как частный случай
автоматическое определение размера по критерию максимизации прибыли
Стратегии формирования страхового запаса
Понятие «страховой запас» в системе «Инвентор» не используется. При необходимости, результаты оптимизации могут быть выражены в любых терминах
установка по статистическим данным
автоматическое определение уровня по критерию максимизации прибыли с учетом всех вариаций
другое  
виды уровня обслуживания
1-го типа ( 1 - вероятность обнуления)
2-го типа ( 1 - вероятный размер упущенного спроса)
3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа)
используемые при расчетах вероятностные распределения
Система «Инвентор» использует эмпирические (фактические) распределения спроса. При необходимости, система может работать с любым распределением, заданным в произвольной, например, табличной форме
нормальное
логнормальное
показательное
пуассоновское
другие
Учет уже размещенных заказов на закупку/производство
Учет товара в пути
Учет поступивших заказов клиентов
Учет каннибализации (взаимного влияния аналогов)
Учет сроков годности товара
Учет затрат времени на доставку
Учет затрат времени на производство
Учет минимальной партии

 

Блок "Управление поставщиками"

 

Номенклатурная матрица поставщика
Время исполнения заказа
Стоимость доставки
Условия оплаты
Дисциплина исполнения заказа
Другое
Процедура выбора оптимального поставщика товара

 

Блок "Отчеты, аналитика, оптимизация"

ABC анализ
при оптимизации не используется
XYZ анализ
при оптимизации не используется
План-график платежей поставщикам
План-график отгрузок клиентам
План поступлений денежных средств
План-график внутренних перемещений товара
План-график размера запаса
Планируемая оборачиваемость запаса
Планируемая рентабельность инвестиций в запас (GMROI)
План-график загрузки транспорта
План-график использования складских площадей
Ожидаемые дефициты
Ожидаемые сверхнормативные запасы
Расчет EOQ
Расчет оптимального размера страхового запаса
Расчет оптимального уровня обслуживания
Другое
модуль отчетности системы «Инвентор» позволяет рассчитать и визуализировать любые необходимые плановые и фактические KPI

 

Блок "Технические детали"

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

Оптимизируется вход (поставка) на каждый объект. Количество объектов не ограниченное

операционная система

MS Widows XP(86/64)/Vista (86/64)/7 (86/64)

требуемый сервер баз данных MS SQL 2008+
другое программное обеспечение, требуемое для функционирования системы

-

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

 

Легенда:

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

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

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

исключение влияния out-of-stock на отгрузки:
Ситуация нехватки товарного запаса - не редкость, отклонение объема продаж от реального спроса в этом случае сильно искажает реальную картину. Нам необходимо учитывать этот фактор для более адекватного прогнозирования

поддержка определенных пользователем профилей сезонности:
Пользователь может вручную задать коэффициенты сезонности для товара

расчет величины ошибки модели:
После расчета модели по прошлым данным она сравнивается с фактическими данными за этот же период

расчет величины отклонения факта от прогноза:
После расчета модели строится прогноз на несколько периодов вперед. После прохождения этого времени рассчитывается отклонение построенного в прошлом прогноза с реализовавшимся фактом

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

Возможность использования разных цепочек поставок для разных товаров:
В магазин М товар А едет по пути РЦ1->РЦ2->М, а товар Б - по пути РЦ5->РЦ8->М

Возможность автоматической консолидации закупок по каналам/поставщикам:
Система умеет потребности в товаре консолидировать по поставщикам и формировать единый заказ для каждого из поставщиков

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

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

уровень обслуживания 1-го типа ( 1 - вероятность обнуления):
95% означает, что из 100 циклов поставок лишь в 5 запас к концу цикла обнулится

уровень обслуживания 2-го типа ( 1 - вероятный размер упущенного спроса):
95% означает, что из 100 единиц, заказанных клиентами, не хватит 5 единиц

уровень обслуживания 3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа):
95% означает, что из 100 заказов лишь в 5 появится хотя бы одна строка, на которую запаса не хватит

клиент-серверная архитектура, толстый клиент:
Для доступа к серверу используется специальная клиентская программа

клиент-серверная архитектура, тонкий клиент:
В качестве клиента используется web-browser

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

поддержка пользовательских характеристик товара:
Пользователь может определять собственные характеристики товара: ABC, товарная категория, закрепленный менеджер, основной/ассортиментный и пр.

KonSi-Forexsal

Название: KonSi-Forexsal
Производитель: Компания КОНСИ
Официальные представители:

 

Ответ производителя, полученный на запрос:

Благодарим за внимание к нашим разработкам.

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

Forexsal может быть использована в планировании продаж, но никак для оценки запасов и определения оптимальных размеров запаса. Оценка запасов это огромная тема. Известно более 300 моделей решения этих задач. Заметим, что эти задачи лишь отчасти используют понятие прогнозирование, большинство моделей SCM построены на других принципах и методаж. Это еще одно обстоятельство, которое следует учитывать при рассмотрении программы
прогнозирования для SCM.

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

Отдельные процедуры анализа ( а именно выбора ассортимента для продажи, но не решение задачи запасов ) можно увидеть в программе Оптимизация ассортимента www.assortment-analysis.ru

А самую примитивную процедуру ABC анализа можно найти на www.abc-analysis.ru

КонСи.
 

LLamasoft

Название: Supply Chain Guru®
Производитель: LLamasoft
Официальные представители:

 

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

Использует имитационное моделирование, линейное и целочисленное программирование.

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

Logility

Название: Logility Voyager Solutions™
Производитель: Logility
Официальные представители:

 

Подробности по-прежнему неизвестны, но на первый взгляд выглядит солидно.

SIMPLE-system

Название: SIMPLE-system
Производитель: компания Genobium.com
Официальные представители: http://www.logist-ics.ru
http://www.simple-logistics.com.ua

 

Блок "Прогнозирование спроса"

возможность "чистки" истории продаж
автоматическое детектирование выбросов
реакция на выбросы фильтрация
исключение нестандартных продаж
исключение рекламных продаж и прочих маркетинговых результатов
исключение влияния out-of-stock на отгрузки
используемые математические модели
простое скользящее среднее
взвешенное скользящее среднее
поддержка определенных пользователем профилей сезонности
простое экспоненциальное сглаживание
экспоненциальное сглаживание с учетом тренда (Holt)
экспоненциальное сглаживание с учетом сезонности (Winters)
ARIMA
прогнозирование редких продаж
Croston
log-Croston (Boylan)
Willemain
Другая  
линейная регрессия
классическая
множественная
Фурье
Другая  
Другие модели
   
Оценки точности прогнозирования
расчет величины ошибки модели
расчет величины отклонения факта от прогноза
метод оценки
среднеквадратическое отклонение (MSE)
абсолютное процентное отклонение (MAPE)
другая оценка
   
Возможность использования для прогнозирования жизненных циклов товара
Возможность включения планов продвижения в итоговый прогноз
Возможность расчета прогнозов по всей номенклатуре за один проход
Возможность расчета прогнозов по части номенклатуры на основании пользовательского фильтра

 

Блок "Планирование поставок" (включая закупки, собственное производство и дистрибуцию)

Возможность сквозного планирования товаропроводящей сети в целом
Возможность использования разных цепочек поставок для разных товаров
Возможность автоматической консолидации закупок по каналам/поставщикам
Стратегии формирования размера поставки
с постоянным периодом
с постоянным размером
с размером, соответствующим EOQ
ручной минимакс
с постоянным максимальным уровнем
автоматическое определение размера по критерию максимизации прибыли
Стратегии формирования страхового запаса
установка вручную
установка по времени покрытия страховым запасом прогнозного спроса
установка по статистическим данным
по целевому уровню обслуживания с учетом вариативности спроса
по целевому уровню обслуживания с учетом вариативности времени исполнения заказа
автоматическое определение уровня по критерию максимизации прибыли с учетом всех вариаций
виды уровня обслуживания
1-го типа ( 1 - вероятность обнуления)
2-го типа ( 1 - вероятный размер упущенного спроса)
3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа)
используемые при расчетах вероятностные распределения
нормальное
логнормальное
показательное
пуассоновское
другие
   
Учет уже размещенных заказов на закупку/производство
Учет товара в пути
Учет поступивших заказов клиентов
Учет каннибализации (взаимного влияния аналогов)
Учет сроков годности товара
Учет затрат времени на доставку
Учет затрат времени на производство
Учет минимальной партии

 

Блок "Управление поставщиками"

 

Номенклатурная матрица поставщика
Время исполнения заказа
Стоимость доставки
Условия оплаты
Дисциплина исполнения заказа
Другое
   
Процедура выбора оптимального поставщика товара

 

Блок "Отчеты, аналитика, оптимизация"

ABC анализ
XYZ анализ
План-график платежей поставщикам
План-график отгрузок клиентам
План поступлений денежных средств
План-график внутренних перемещений товара
План-график размера запаса
Планируемая оборачиваемость запаса
Планируемая рентабельность инвестиций в запас (GMROI)
План-график загрузки транспорта
План-график использования складских площадей
Ожидаемые дефициты
Ожидаемые сверхнормативные запасы
Расчет EOQ
Расчет оптимального размера страхового запаса
Расчет оптимального уровня обслуживания
Другое

 

Блок "Технические детали"

разграничение доступа к информации на основе ролей пользователей
допустимое количество планируемых объектов (складов, РЦ и т.п.) на одну инсталляцию 20
операционная система Windows
требуемый сервер баз данных не требуется
другое программное обеспечение, требуемое для функционирования системы не требуется
архитектура
локальное рабочее место пользователя
клиент-серверная архитектура, толстый клиент
клиент-серверная архитектура, тонкий клиент
дополнительно
поддержка разных единиц измерений одного товара
поддержка разных валют для стоимостных показателей
поддержка объемно-весовых характеристик товара
поддержка пользовательских характеристик товара
другое
   

 

Легенда:

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

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

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

исключение влияния out-of-stock на отгрузки:
Ситуация нехватки товарного запаса - не редкость, отклонение объема продаж от реального спроса в этом случае сильно искажает реальную картину. Нам необходимо учитывать этот фактор для более адекватного прогнозирования

поддержка определенных пользователем профилей сезонности:
Пользователь может вручную задать коэффициенты сезонности для товара

расчет величины ошибки модели:
После расчета модели по прошлым данным она сравнивается с фактическими данными за этот же период

расчет величины отклонения факта от прогноза:
После расчета модели строится прогноз на несколько периодов вперед. После прохождения этого времени рассчитывается отклонение построенного в прошлом прогноза с реализовавшимся фактом

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

Возможность использования разных цепочек поставок для разных товаров:
В магазин М товар А едет по пути РЦ1->РЦ2->М, а товар Б - по пути РЦ5->РЦ8->М

Возможность автоматической консолидации закупок по каналам/поставщикам:
Система умеет потребности в товаре консолидировать по поставщикам и формировать единый заказ для каждого из поставщиков

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

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

уровень обслуживания 1-го типа ( 1 - вероятность обнуления):
95% означает, что из 100 циклов поставок лишь в 5 запас к концу цикла обнулится

уровень обслуживания 2-го типа ( 1 - вероятный размер упущенного спроса):
95% означает, что из 100 единиц, заказанных клиентами, не хватит 5 единиц

уровень обслуживания 3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа):
95% означает, что из 100 заказов лишь в 5 появится хотя бы одна строка, на которую запаса не хватит

клиент-серверная архитектура, толстый клиент:
Для доступа к серверу используется специальная клиентская программа

клиент-серверная архитектура, тонкий клиент:
В качестве клиента используется web-browser

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

поддержка пользовательских характеристик товара:
Пользователь может определять собственные характеристики товара: ABC, товарная категория, закрепленный менеджер, основной/ассортиментный и пр.

 

Syncron

Название: SCM Software Solutions
Производитель: Syncron
Официальные представители:

 

Подробности по-прежнему неизвестны, но на первый взгляд выглядит солидно.

Закупочно-логистические системы

Название: Закупочно-логистические системы
Производитель: Клочков Александр Павлович http://www.plsystems.ru
 

Комментарий производителя:

Программный комплекс «Закупочно-логистические системы» представляет собой программное решение, имеющий стандартные функции, указанные ниже. Основной принципом внедрения данной системы является индивидуальный подход к каждому заказчику. То есть стандартные функции в процессе работы над внедрением обрастают многими дополнительными возможностями, которые, как правило, в итоге даже перевешивают стандартные по значимости. Появляются также и оригинальные, применимые к данному непосредственному случаю решения. Таким образом, если в списке, указанном ниже функция не присутствует – это не означает, что её нельзя в итоге применить.
Еще одним принципом является достижение максимальной простоты программного обеспечения для пользователя. Даже неподготовленный пользователь может очень быстро начать уверенно работать в системе.

Блок "Прогнозирование спроса"

Алгоритм Прогнозирования спроса вырабатывается совместно с клиентом.

 

Блок "Планирование поставок" (включая закупки, собственное производство и дистрибуцию)

Возможность сквозного планирования товаропроводящей сети в целом
Возможность использования разных цепочек поставок для разных товаров
Возможность автоматической консолидации закупок по каналам/поставщикам
Стратегии формирования размера поставки
с постоянным периодом
с постоянным размером
с размером, соответствующим EOQ
ручной минимакс
с постоянным максимальным уровнем
автоматическое определение размера по критерию максимизации прибыли
Стратегии формирования страхового запаса
установка вручную
установка по времени покрытия страховым запасом прогнозного спроса
установка по статистическим данным
по целевому уровню обслуживания с учетом вариативности спроса
по целевому уровню обслуживания с учетом вариативности времени исполнения заказа
автоматическое определение уровня по критерию максимизации прибыли с учетом всех вариаций
виды уровня обслуживания
1-го типа ( 1 - вероятность обнуления)
2-го типа ( 1 - вероятный размер упущенного спроса)
3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа)
используемые при расчетах вероятностные распределения
нормальное
логнормальное
показательное
пуассоновское
другие
   
Учет уже размещенных заказов на закупку/производство
Учет товара в пути
Учет поступивших заказов клиентов
Учет каннибализации (взаимного влияния аналогов)
Учет сроков годности товара
Учет затрат времени на доставку
Учет затрат времени на производство
Учет минимальной партии

 

Блок "Управление поставщиками"

 

Номенклатурная матрица поставщика
Время исполнения заказа
Стоимость доставки
Условия оплаты
Дисциплина исполнения заказа постоянно отслеживается статус заказа и выдается флаг-напоминание о задержках
Другое
   
Процедура выбора оптимального поставщика товара

 

Блок "Отчеты, аналитика, оптимизация"

ABC анализ
XYZ анализ
План-график платежей поставщикам
План-график отгрузок клиентам
План поступлений денежных средств
План-график внутренних перемещений товара
План-график размера запаса
Планируемая оборачиваемость запаса
Планируемая рентабельность инвестиций в запас (GMROI)
План-график загрузки транспорта
План-график использования складских площадей
Ожидаемые дефициты
Ожидаемые сверхнормативные запасы
Расчет EOQ
Расчет оптимального размера страхового запаса
Расчет оптимального уровня обслуживания
Другое

 

Блок "Технические детали"

разграничение доступа к информации на основе ролей пользователей
допустимое количество планируемых объектов (складов, РЦ и т.п.) на одну инсталляцию 1
операционная система Windows
Mac
требуемый сервер баз данных входит в лицензию базовой программы
другое программное обеспечение, требуемое для функционирования системы FileMaker Pro, сайт производителя www.filemaker.com
архитектура
локальное рабочее место пользователя
клиент-серверная архитектура, толстый клиент
клиент-серверная архитектура, тонкий клиент
дополнительно
поддержка разных единиц измерений одного товара
поддержка разных валют для стоимостных показателей
поддержка объемно-весовых характеристик товара
поддержка пользовательских характеристик товара
другое
 Возможна работа до 100 пользователей , находящихся в одной сети. Также возможен вариант работы через интернет для удалённых (от локальной сети) пользователей.  

 

Легенда:

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

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

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

исключение влияния out-of-stock на отгрузки:
Ситуация нехватки товарного запаса - не редкость, отклонение объема продаж от реального спроса в этом случае сильно искажает реальную картину. Нам необходимо учитывать этот фактор для более адекватного прогнозирования

поддержка определенных пользователем профилей сезонности:
Пользователь может вручную задать коэффициенты сезонности для товара

расчет величины ошибки модели:
После расчета модели по прошлым данным она сравнивается с фактическими данными за этот же период

расчет величины отклонения факта от прогноза:
После расчета модели строится прогноз на несколько периодов вперед. После прохождения этого времени рассчитывается отклонение построенного в прошлом прогноза с реализовавшимся фактом

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

Возможность использования разных цепочек поставок для разных товаров:
В магазин М товар А едет по пути РЦ1->РЦ2->М, а товар Б - по пути РЦ5->РЦ8->М

Возможность автоматической консолидации закупок по каналам/поставщикам:
Система умеет потребности в товаре консолидировать по поставщикам и формировать единый заказ для каждого из поставщиков

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

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

уровень обслуживания 1-го типа ( 1 - вероятность обнуления):
95% означает, что из 100 циклов поставок лишь в 5 запас к концу цикла обнулится

уровень обслуживания 2-го типа ( 1 - вероятный размер упущенного спроса):
95% означает, что из 100 единиц, заказанных клиентами, не хватит 5 единиц

уровень обслуживания 3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа):
95% означает, что из 100 заказов лишь в 5 появится хотя бы одна строка, на которую запаса не хватит

клиент-серверная архитектура, толстый клиент:
Для доступа к серверу используется специальная клиентская программа

клиент-серверная архитектура, тонкий клиент:
В качестве клиента используется web-browser

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

поддержка пользовательских характеристик товара:
Пользователь может определять собственные характеристики товара: ABC, товарная категория, закрепленный менеджер, основной/ассортиментный и пр.

Развитие торговых сетей

Цитата с их сайта:

"Развитие торговых сетей" (РТС) - молодая динамичная компания, основанная в Санкт-Петербурге в 2005 году. Нами накоплен бесценный опыт построения бизнес-процессов в торговых сетях, в частности - в организации эффективного управления запасами, планировании закупок, автоматизации логистики.

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

Увы, за 3 (ТРИ!) месяца мне так и не удалось связаться - каждый раз я получал отлуп от почтовой системы с диагностикой "в почтовом ящике закончилось место". Я бы с удовольствием порадовался за коллег, что у них почтовый ящик просто-таки ломится от обращений граждан, но по натуре я циник и к тому же немного представляю себе технологию. Коллеги, отлуп такого рода может означать только одно: никто в этот ящик никогда не заглядывает, иначе бы уже давно обеспокоились тем, что туда не приходит ни одного письма вот уже (как минимум) несколько месяцев.

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

СППР

Название: Система поддержки принятия решений
Производитель: Тримас Групп
Официальные представители:
http://www.logistware.com

 

Блок "Прогнозирование спроса"

возможность "чистки" истории продаж
автоматическое детектирование выбросов
реакция на выбросы графически
исключение нестандартных продаж
исключение рекламных продаж и прочих маркетинговых результатов
исключение влияния out-of-stock на отгрузки
есть возможность контроля отсутствия товара –сколько дней данный товар отсутствовал на складе
используемые математические модели
простое скользящее среднее
взвешенное скользящее среднее
поддержка определенных пользователем профилей сезонности
сложившейся статистически сезонности – по выбору опорного периода
простое экспоненциальное сглаживание
экспоненциальное сглаживание с учетом тренда (Holt)
экспоненциальное сглаживание с учетом сезонности (Winters)
ARIMA
прогнозирование редких продаж
Croston
log-Croston (Boylan)
Willemain
Другая  
линейная регрессия
классическая
множественная
Фурье
Другая  
Другие модели
   модель экспертной оценки: «продажи так же как в период с…по…» с заданием коэффициента роста
Оценки точности прогнозирования
расчет величины ошибки модели
расчет величины отклонения факта от прогноза
метод оценки
среднеквадратическое отклонение (MSE)
абсолютное процентное отклонение (MAPE)
другая оценка
   
Возможность использования для прогнозирования жизненных циклов товара
Возможность включения планов продвижения в итоговый прогноз
ручная корректировка
Возможность расчета прогнозов по всей номенклатуре за один проход
Возможность расчета прогнозов по части номенклатуры на основании пользовательского фильтра

 

Блок "Планирование поставок" (включая закупки, собственное производство и дистрибуцию)

Возможность сквозного планирования товаропроводящей сети в целом
Возможность использования разных цепочек поставок для разных товаров
Возможность автоматической консолидации закупок по каналам/поставщикам
Стратегии формирования размера поставки
с постоянным периодом
с постоянным размером
с размером, соответствующим EOQ
ручной минимакс
с постоянным максимальным уровнем
автоматическое определение размера по критерию максимизации прибыли
Стратегии формирования страхового запаса
установка вручную
установка по времени покрытия страховым запасом прогнозного спроса
установка по статистическим данным
по целевому уровню обслуживания с учетом вариативности спроса
по целевому уровню обслуживания с учетом вариативности времени исполнения заказа
автоматическое определение уровня по критерию максимизации прибыли с учетом всех вариаций
другое Исходя из зависимости продаж от запаса
виды уровня обслуживания
1-го типа ( 1 - вероятность обнуления)
2-го типа ( 1 - вероятный размер упущенного спроса)
3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа)
используемые при расчетах вероятностные распределения
нормальное
логнормальное
показательное
пуассоновское
другие
   
Учет уже размещенных заказов на закупку/производство
Учет товара в пути
Учет поступивших заказов клиентов
Учет каннибализации (взаимного влияния аналогов)
планирование аналогов как 1 позиции с дальнейшим распределением по поставщикам
Учет сроков годности товара
Учет затрат времени на доставку
Учет затрат времени на производство
Учет минимальной партии

 

Блок "Управление поставщиками"

 

Номенклатурная матрица поставщика
Время исполнения заказа
Стоимость доставки
Условия оплаты
Дисциплина исполнения заказа
вывод графика исполнения планов отгрузок: по плану- факт
Другое
   
Процедура выбора оптимального поставщика товара
полуручной режим, исходя из cashflow

 

Блок "Отчеты, аналитика, оптимизация"

ABC анализ
XYZ анализ
План-график платежей поставщикам
План-график отгрузок клиентам
План поступлений денежных средств
План-график внутренних перемещений товара
План-график размера запаса
Планируемая оборачиваемость запаса
Планируемая рентабельность инвестиций в запас (GMROI)
План-график загрузки транспорта
План-график использования складских площадей
Ожидаемые дефициты
Ожидаемые сверхнормативные запасы
Расчет EOQ
Расчет оптимального размера страхового запаса
Расчет оптимального уровня обслуживания
Другое

 

Блок "Технические детали"

разграничение доступа к информации на основе ролей пользователей
допустимое количество планируемых объектов (складов, РЦ и т.п.) на одну инсталляцию 1
операционная система Windows
требуемый сервер баз данных Firebird
другое программное обеспечение, требуемое для функционирования системы не требуется
архитектура
локальное рабочее место пользователя
клиент-серверная архитектура, толстый клиент
клиент-серверная архитектура, тонкий клиент
дополнительно
поддержка разных единиц измерений одного товара
поддержка разных валют для стоимостных показателей
поддержка объемно-весовых характеристик товара
поддержка пользовательских характеристик товара
другое
   

 

Легенда:

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

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

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

исключение влияния out-of-stock на отгрузки:
Ситуация нехватки товарного запаса - не редкость, отклонение объема продаж от реального спроса в этом случае сильно искажает реальную картину. Нам необходимо учитывать этот фактор для более адекватного прогнозирования

поддержка определенных пользователем профилей сезонности:
Пользователь может вручную задать коэффициенты сезонности для товара

расчет величины ошибки модели:
После расчета модели по прошлым данным она сравнивается с фактическими данными за этот же период

расчет величины отклонения факта от прогноза:
После расчета модели строится прогноз на несколько периодов вперед. После прохождения этого времени рассчитывается отклонение построенного в прошлом прогноза с реализовавшимся фактом

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

Возможность использования разных цепочек поставок для разных товаров:
В магазин М товар А едет по пути РЦ1->РЦ2->М, а товар Б - по пути РЦ5->РЦ8->М

Возможность автоматической консолидации закупок по каналам/поставщикам:
Система умеет потребности в товаре консолидировать по поставщикам и формировать единый заказ для каждого из поставщиков

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

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

уровень обслуживания 1-го типа ( 1 - вероятность обнуления):
95% означает, что из 100 циклов поставок лишь в 5 запас к концу цикла обнулится

уровень обслуживания 2-го типа ( 1 - вероятный размер упущенного спроса):
95% означает, что из 100 единиц, заказанных клиентами, не хватит 5 единиц

уровень обслуживания 3-го типа ( 1 - вероятность неудовлетворения заказа клиента хотя бы по одной строке заказа):
95% означает, что из 100 заказов лишь в 5 появится хотя бы одна строка, на которую запаса не хватит

клиент-серверная архитектура, толстый клиент:
Для доступа к серверу используется специальная клиентская программа

клиент-серверная архитектура, тонкий клиент:
В качестве клиента используется web-browser

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

поддержка пользовательских характеристик товара:
Пользователь может определять собственные характеристики товара: ABC, товарная категория, закрепленный менеджер, основной/ассортиментный и пр.

Дополнительные комментарии производителя:

  • Возможность планирования продаж и запасов по взаимозаменяемым товарам как по одной позиции с дальнешей возможностью распределения по поставщикам для оптимизации cash&flow.
  • Наличие анализа ассортиментных связей по 3 параметрам: вероятности совместных продаж разных позиций, продажи сопутствующей на 1 ед основной позиции, а также в стоимостном выражении, для более корректного управления ассортиментом.
  • Возможность проведения ABC-анализа по объему продаж и прибыльности, а также по количеству ед. измерения товаров.
  • Возможность проведения ABC-анализа и анализа ассортиментных связей за любой период.
  • Возможность формирования справочника пользователя с распределением товаров по группам по желанию пользователя. Например, исходя из ABC–XYZ, по менеджерам и т.д.
  • Возможность планирования продаж по подразделениям компании, торгующим с 1 склада. Например: крупный опт, средний опт и т.п.
  • Учет кратности партии.
  • Учет срока выполнения заказа (от размещения заказа до поступления на склад).
  • Возможность дробной цены. Например, 1000 ед. товара стоит 1,86 $
  • Возможность использования принципов объемно-календарного планирования.
  • Формирование страхового запаса несколькими стратегиями (ввод вручную):
    • мин-макс.
    • на основе зависимости запаса от продаж.
    • Рассчитанным внешне.
  • Корректировка планов с автоматическим пересчетом.
  • Расчет cash&flow на период по шагам планирования, как по фирме, там и по поставщикам или товарным позициям.
  • Анализ исполнения планов:
    • Плана продаж.
    • Плана поставок
    • Плана запасов
    • информация выводится графически и в виде таблиц.
  • возможность выгрузки планов в Excel.
  • Формирование графика оплат поставщикам: сумма, дата, кому.
  • Формирование графика выставления заявок.
  • Контроль полноты пакета: по всем ли позициям сформированы планы

Автоматизация многономенклатурных закупок без фиксирования периода между поставками.

Хватит ли одного пальца, чтобы пересчитать все модели автоматизированных закупок для многономенклатурных поставок? – Теперь, нет! 

Исходная предпосылка.
Большинство компаний, которые осуществляют многономенклатурные поставки продукции и пытаются автоматизировать свои закупки, сталкиваются с отсутствием выбора моделей для этого. После упорных поисков по дебрям Интернета они обнаруживают, что есть только одна такая модель, правда, предлагаемая в разных вариациях – это модель с фиксированным периодом между поставками.
В многочисленных диссертациях, статьях и научных трудах, посвящённых изучению и выводу этой модели, обычно очень мало говорится о том, почему была выбрана именно она. Большинство авторов старается, вообще, не затрагивать эту тему, те же, кто упоминает об этом, обычно сообщают читателям, что эта модель лучше всех подходит для автоматизации многономенклатурных поставок, без каких-либо объяснений этого вывода или ссылок на другие материалы. И совсем редко приводятся некие данные математического моделирования, где с некоторым отрывом лидирует, действительно, модель с фиксированным периодом между поставками. Правда, методики проведения этого моделирования и условия (данные, на которых оно проводилось) – не приводятся, дабы не искушать читателя найти в них ошибку, или заведомую неоптимальность альтернативных моделей. При этом на практике мы можем встретить ситуации, когда закупщики при осуществлении многономенклатурных поставок используют в своей работе алгоритмы, отличные от этой модели. Эти алгоритмы – не автоматизированы и не оптимизированы, зачастую даже не систематизированы: «Это заказываем так-то, а это – так-то,» – а, почему не наоборот, уже не скажут, но при этом работа осуществляется, и осуществляется нелохо… Так кто же из них прав: теоретики или практики?
Как обычно, истина – где-то посередине, и по-своему правы и не правы – и те, и другие. Практик-закупщик отвечает за результаты своей работы: привёз мало – дефицит, привёз много – неликвид, а начальника не порадует любой из этих вариантов – вот и выкручивайся, как хочешь. Они и выкручиваются – стараются возить почаще: тогда можно привозить сразу немного, а по мере продажи подвозить ещё. Однако, ясно, что такая практика выливается в дополнительные транспортные расходы – правда, это уже епархия транспортного отдела, а он не может заставить закупщика ездить за одним и тем же реже, да и не всегда перед транспортом стоит такая задача – обычно, их основная цель – это бесперебойное выполнение заявок на перевозку…
Что же на это скажут теоретики? Они затраты на транспорт учитывают обязательно! Более того, подбирают такие параметры модели с фиксированным периодом между поставками, чтобы эти затраты в совокупности со всеми остальными затратами были заведомо минимальными!.. Только не объясняют, почему используют именно эту модель, и не будет ли другая менее затратной… В чём же причина такой узкой направленности, – вроде бы очень умные люди, должны руководствоваться научным подходом: «прежде чем отбраковывать модель – сравни её эффективность с текущей»? – Да, просто, модель с фиксированным периодом между поставками – самая лёгкая, самая изученная и самая разработанная!.. Вот и ищут там, «где светло», а не там, «где потеряли», тем более сама модель, действительно, – очень хорошая, а не редко – и самая лучшая. Но, к сожалению, не всегда, а, значит, надо считать, сравнивать и выявлять те условия, в которых она будет давать лучший результат, и границы, за которыми надо использовать уже другие модели, а не, просто, в любой ситуации искать оптимальные параметры не обязательно оптимальной модели.
На практике я столкнулся с ситуацией, когда математическое моделирование модели многономенклатурных закупок с фиксированием периода между поставками выявило, что даже при самых оптимальных параметрах она даёт результат хуже, чем реально достигнутый практиками-закупщиками, работа которых не была ни автоматизирована, ни оптимизирована. Снижение результативности заключалось в том, что при использовании на том же спросе автоматизированной системы с фиксированным периодом между поставками даже с оптимальными параметрами: и дефицит, и затраты на транспорт, и средний запас – оказывались выше достигнутых на практике. Эта ситуация, стала причиной поиска, а затем создания альтернативной модели, которая давала бы лучший результат, чем до её использования, которую можно было бы автоматизировать, и параметры которой можно было бы оптимизировать.
 
Постановка задачи.
Есть поставщик, который поставляет нам много позиций: часть из них пользуется регулярным спросом, и соответственно мы их держим у себя на складе, а другие позиции этого же поставщика у нас покупают крайне редко (вплоть до единичных случаев за всё историю продаж), и, соответственно, мы их возим под заказ клиента. Сроки производства позиций до момента, когда поставщик сможет их отгрузить – разные и сильно варьирующиеся: от нескольких дней до месяца (определяется технологией производства и необходимостью закупки поставщиком нестандартных компонентов).
По каждой позиции регулярного спроса политически выставлен необходимый уровень удовлетворения спроса остатками на складе: от 90% до 99% (это главное конкурентное преимущество компании, поэтому при использовании любой из систем закупок это условие должно выполняться). При этом сам их спрос имеет большую вариацию даже на месячных периодах после очистки от тренда и сезонности имеет 50-200% белого шума. Из-за этого, а также в связи с тем, что оборотные деньги для компании – достаточно дорогие, а плечо доставки от поставщиков – достаточно короткое,  лучше лишних страховых запасов на складе не держать, а подвоз осуществлять не через равные точки времени, а по достижении точки заказа по одной или нескольким позициям.
В связи с этим была поставлена задача – получить автоматизированную модель расчёта точки и оптимальной величины заказа по каждой позиции регулярного спроса в системе многономенклатурных поставок с регулярными (не значит равномерными или прогнозируемыми) поставками заказных позиций, чтобы минимизировать суммарные затраты на их хранение и доставку. Кроме этого должна осуществляться экономия на транспорте за счёт одновременной поставки заказных поставок под запрос клиента и пополнения складских запасов – в случае, если мы везём в одной машине продукцию и под заказ клиента, и себе на склад, считается, что на склад мы везём её бесплатно, так как клиент оплачивает доставку заказных позиций в полном объёме, а в машине всегда остаётся место.
 
Решение.
Все формулы в этой статье рассчитываются  – отдельно по позициям; формулы, где переменные агрегируются – в сумме по каждому поставщику. Все сроки считаются в рабочих днях. Для экономии места и сохранения нити повествования, используемые формулы не выводятся.
 
Нахождение критического максимума, больше которого хранить на складе не рентабельно.
Для любой позиции на складе, вне зависимости от используемой вами модели закупок, есть определённое количество, выше которого вы храните остатки по этой позиции себе в убыток, даже, если они продаются в больших объёмах и с хорошей наценкой. Это обусловлено тем, что любые запасы требуют обслуживания, и даже если у вас свой склад, и вы не испытываете нужды в свободном месте, то денег не хватает всем и всегда, а вы их заморозили в эти запасы. Конечно, некоторую долю этих затрат несёт поставщик, давая вам товарный кредит, но и вы кредитуете своих клиентов, поэтому окончательный вариант формулы будет выглядеть так:
, где:
M – критический максимум остатков по позиции, выше которого хранить на складе убыточно [Единиц];
Ai – суммарные отгрузки из документов расхода за i-тую дату по позиции [Единиц];
Si – остатки по позиции на утро i-той даты без учёта оплаченных резервов [Единиц];
R – средняя маржинальная рентабельность продаж по позиции [%];
Н – альтернативная доходность вложенных в запасы денег [% / День];
Y – средняя отсрочка платежа клиентам компании [Дней];
W – отсрочка платежа у поставщика [Дней].
 
Дробь со «страшными» суммами в начале формулы – это просто среднедневные продажи, но не во всякий день, а только тогда, когда остатков на складе (вместе с приходами в этот день) было достаточно для обеспечения минимальных продаж за день. Это условие используется, чтобы не занижать это среднедневное значение из-за нулевых продаж в те дни, когда заведомо ничего продаваться и не могло (из-за отсутствия товара на складе). R / H – это количество дней, которое вы можете себе позволить держать деньги в запасах этой позиции – дальше вы начинаете делать это себе в убыток (заработок от продажи позиции R не покроет затрат на заморозку средств H в течение такого длительного периода). По-хорошему в H надо ещё включить переменные затраты на хранение (только переменные и только на хранение – не путать с затратами на склад), но обычно они значительно меньше затрат на замороженные средства для компаний со своим складом (совсем своим или арендуемым целиком), поэтому я ими пренебрёг в своих расчётах. При необходимости их включение не составит большого труда. В данном же случае, умножая, полученное количество дней на среднедневную продажу по позиции мы получаем максимальный остаток, выше которого нам хранить на складе – заведомо не выгодно. Соответственно, если поставщик даёт нам отсрочку платежа, то весь срок этой отсрочки в наши остатки вложены не наши деньги, а его. А, значит, никаких убытков мы от заморозки своих денег в это время не несём и можем дополнительно положить на остатки на этот срок продаж или поделиться этими деньгами с клиентами, дав отсрочку платежа им.
С помощью этого значения М вы сможете очистить входной поток данных от пиковых продаж, которые вам не выгодно обслуживать со склада, а так же оно позволит вам не закладывать на склад заведомо убыточных объёмов продукции. В таком случае рекомендуется вводить регламент для отгрузок, превышающих это значение, по их обслуживанию за счёт спецпоставок от поставщика под заказ клиента. Это позволяет не опустошать при таких запросах склад и не отказывать в этой позиции остальным клиентам до следующей поставки.
 
Нахождение критического минимума, необходимого для осуществления продаж.
Если дефицит – не редкий случай в вашей компании, то временной ряд продаж надо очищать и от заниженных значений, которые были обусловлены недостаточным наличием позиции на остатках. При длительных периодах дефицита – искажение может быть очень значительным и занижать потребность в разы. Для нахождения этого параметра советую использовать такую формулу:
, где:
m – критический минимум остатков, необходимых для осуществления продаж по позиции [Единиц];
Ai – суммарные отгрузки из документов расхода за i-тую дату по позиции [Единиц];
M – критический максимум остатков по позиции, выше которого хранить на складе убыточно [Единиц].
 
В этой формуле отсекаются все продажи, которые были выше вычисленного критического максимума – вы не собираетесь обслуживать их со склада (вам это заведомо не выгодно), а будете под такие заказы осуществлять спец-поставки. А затем, просто, считаются средние продажи в день продаж (когда эта позиция продавалась). Это нужно для того, чтобы по позициям, продающимся не каждый день, не занижать необходимый уровень остатков для осуществления продаж. В случае же, если все факты продаж лежат выше критического максимума, то есть все отгрузки, по сути, были заказными, то в качестве критического минимума берутся минимальные продажи.
Знание этого минимума m позволит вам более точно определять периоды дефицита, а так же быстрее реагировать на увеличение спроса по позиции.
 
Расчёт истории спроса и количества дней присутствия и отсутствия.
После того, как вы получили верхнюю и нижнюю границы для очистки временного ряда продаж, остаётся только применить их обе для расчёта временного ряда спроса по позиции на каждую дату:
, где:
Ci – спрос по позиции за i-тую дату [Единиц];
Ai – суммарные отгрузки из документов расхода за i-тую дату по позиции [Единиц];
M – критический максимум остатков по позиции, выше которого хранить на складе убыточно [Единиц];
Si – остатки по позиции на утро i-той даты без учёта оплаченных резервов [Единиц];
m – критический минимум остатков, необходимых для осуществления продаж по позиции [Единиц].
 
Если оба граничных условия выполняются, то спрос равен, просто, суммарным продажам за эту дату. Если не выполняется хотя бы одно из условий (то есть остатков вместе с приходами на дату было не достаточно для осуществления продаж в этот день или вы осуществляли отгрузку по спец-поставке под заказ клиента), то мы считаем спрос за эту дату – неизвестным (NULL).
 
И совсем просто рассчитываются периоды обеспеченного спроса и дефицита по позиции в прошлом – достаточно посчитать количество дней, когда остатков на утро в сумме с приходами за день было соответственно: достаточно или не достаточно для осуществления продаж (критерием выступает критический минимум):
, где:
L0 – количество дней отсутствия позиции на складе [Дней];
Si – остатки по позиции на утро i-той даты без учёта оплаченных резервов [Единиц];
m – критический минимум остатков, необходимых для осуществления продаж по позиции [Единиц].
, где:
L1 – количество дней присутствия позиции на складе [Дней] ;
Si – остатки по позиции на утро i-той даты без учёта оплаченных резервов [Единиц];
m – критический минимум остатков, необходимых для осуществления продаж по позиции [Единиц].
 
Расчёт точек заказа при заданных уровнях удовлетворения спроса остатками.
Значения Ci сортируются по возрастанию даты, а индексы присваиваются по порядку без пропусков, после чего на основании этого ряда создаётся новый ряд суммированного спроса за I + L дней – 0j}:
, где:
C0jj-тая сумма спроса по позиции за количество дней, необходимое для её производства и поставки [Единиц];
Ci – спрос по позиции за i-тую дату [Единиц];
I – время производства поставщиком позиции до отгрузки [Дней];
L – время доставки от поставщика [Дней].
 
Как бы страшно не выглядели условия суммирования в этих формулах, на практике они означают лишь, что надо сложить I + L подряд идущих значений спроса за день, и сделать это с шагом в день ровно столько раз, сколько значений спроса имеется. Это нужно для того, чтобы в последствии оценивать возможные изменения спроса за интересующий вас период и создавать страховые запасы адекватные именно их вероятностным характеристикам, не проверяя статистических гипотез на независимость значений спроса друг от друга.
 
Теперь мы можем найти необходимый запас по позиции для удовлетворения спроса остатками с ожидаемым уровнем на время подвоза:
, где:
U0 – количество по позиции, необходимое для удовлетворения спроса остатками на необходимом уровне на время производства и подвоза [Единиц];
C0jj-тая сумма спроса по позиции за количество дней, необходимое для её производства и поставки [Единиц];
N – необходимый уровень удовлетворения спроса остатками по позиции [%].
 
Формула расчёта U0 – это, просто, математическая запись определения уровня удовлетворения спроса остатками, а мы ищем минимальное количество, удовлетворяющее этому определению.
 
Точкой же заказа по позиции будет момент, когда одновременно выполнятся два следующих неравенства:
, где:
B – текущие остатки по позиции с транзитами и за вычетом оплаченных резервов [Единиц];
U0 – количество по позиции, необходимое для удовлетворения спроса остатками на необходимом уровне на время производства и подвоза [Единиц];
L1 – количество дней присутствия позиции на складе [Дней];
I – время производства поставщиком позиции до отгрузки [Дней];
L – время доставки от поставщика [Дней];
C0jj-тая сумма спроса по позиции за количество дней, необходимое для её производства и поставки [Единиц];
N – необходимый уровень удовлетворения спроса остатками по позиции [%].
 
Первое неравенство показывает нам, что текущих остатков (вместе с ожидаемыми приходами) не будет достаточно для удовлетворения спроса остатками на заданном уровне (U0 – это минимальное количество по позиции, которого хватило бы). Второе неравенство используется для того, чтобы не начинать поставку (а точка заказа именно инициирует поставку), если у нас закончилась не очень важная позиция, и мы можем даже пожить некоторое время с пустым складом по ней, пока не распродадим побольше позиций этого поставщика и не закажем одну большую общую поставку. Главным критерием выступают время отсутствия товара на складе L0 и уровень удовлетворения спроса остатками N – чем они больше, тем скорее выполнится это неравенство, – то есть, если товар долго отсутствует (большое значение L0) или эта позиция для нас важна (большое значение N), то мы получим точку заказа по этой позиции.
 
Расчёт скорректированного периода между поставками.
Сначала рассчитываем по каждой позиции среднедневной спрос (просто усредняя имеющиеся значения спроса за день по позиции):
, где:
 – средний спрос за день по позиции [Единиц / День];
Ci – спрос по позиции за i-тую дату [Единиц].
 
Максимально возможный период между поставками по складским позициям рассчитывается единым для поставщика (суммирование в формуле происходит по всем складским позициям поставщика), а формула будет такой:
, где:
Q – максимально допустимый период между поставками по складским позициям поставщика [Дней];
 – средний спрос за день по позиции [Единиц / День];
Z – текущая закупочная цена позиции [Рублей / Единицу];
R – средняя маржинальная рентабельность продаж по позиции [%];
Н – альтернативная доходность вложенных в запасы денег [% / День];
Y – средняя отсрочка платежа клиентам компании [Дней];
W – отсрочка платежа у поставщика [Дней];
L – время доставки от поставщика [Дней].
 
То есть мы смотрим, максимальный период времени, на который можем заложить к себе на склад все складские позиции поставщика, по аналогии с расчётом критического максимума остатков по одной позиции, выше которого хранить на складе становится убыточно. Соответственно, если этот срок меньше времени доставки от поставщика L, то берём последнее.
 
Теперь разберёмся с влиянием заказных поставок. Заказной поставкой считается любая поставка, которая содержит заказную позицию или складскую позицию, но в количестве больше найденного по этой позиции критического максимума М. Значения дискретной ступенчатой функции распределения вероятностей осуществления заказной поставки от поставщика определяем как нарастающую сумму количества заказных поставок, произошедших через х дней после предыдущей, делённую на количество всех заказных поставок за период:
По сути, эта функция показывает вероятность наступления случайного события (заказной поставки от поставщика) в течение 1 дня, 2 дней, 3 дней, и так далее – х дней, пока это событие не станет практически достоверным: F(х) = 1.
 
Теперь, чтобы учесть влияния потока заказных поставок, нам надо найти такой скорректированный период между поставками, при котором:
, где:
Т – скорректированный период между поставками [Дней];
E(х) – функция выгоды от пополнения складских позиций вместе с заказными [Рублей / День];
Н – альтернативная доходность вложенных в запасы денег [% / День];
Q – максимально допустимый период между поставками по складским позициям поставщика [Дней];
 – средний спрос за день по позиции [Единиц / День];
Z – текущая закупочная цена позиции [Рублей / Единицу];
D – средняя стоимость доставки от поставщика [Рублей];
F(х) – дискретная ступенчатая функция распределения вероятностей осуществления заказной поставки от поставщика в течении х дней после предыдущей [%].
 
Эта формула показывает, что мы выигрываем от поставки складских позиций вместе с заказными. Первое слагаемое отвечает за изменения затрат на содержание запасов – оно будет равно разнице в днях (Q – T), умноженной на средние продажи по позициям поставщика в закупочных ценах , и на стоимость замороженных денег H. Второе слагаемое даёт нам транспортную составляющую затрат, которая зависит от стоимости доставки D и того, на сколько изменяется вероятность осуществления заказной поставки по отношению к периоду за который мы смотрим эту вероятность Q или T (а значит, и по отношению к количеству поставок за фиксированный период: 1 / Q и 1 / T – соответственно). Оба этих слагаемых зависят от параметра Т, а полученное в итоге значение этого параметра, которое будет максимизировать функцию Е(Т), и будет определять оптимальный объём заказ поставщику, в худшем случае равняясь Q, при котором значение функции будет заведомо равно нулю: E(Q) = 0.
 
Формирование графика предстоящих отгрузок.
Все ожидаемые поставки рекомендуется вносить в информационную систему компании с датами ожидаемой поставки – это позволяет в автоматизированном режиме отслеживать все задержки, недопоставки, пересорты и отличие цен в приходных накладных от цен в заказе. А если мы плюс к этим датам возьмём ещё и даты ожидаемой отгрузки у поставщика из точек заказа по позициям: Gi = I , то сможем понять, в каком объёме нам надо дозаказывать другие позиции, по которым точка заказа ещё не наступила. Поэтому расчёт точек дозаказа по позициям какого-либо поставщика должен производиться только после очередного расчёта точек заказа по всем позициям этого поставщика. В результате мы получаем данные о количестве дней до ожидаемых отгрузок от поставщика: {Gi}. Тогда заказ по позиции будет производиться, только если существует такая ожидаемая отгрузка, что срок производства этой позиции будет равен времени до этой отгрузки:
, где:
Gi  – количество дней до i-той отгрузки, ожидаемой от поставщика по графику предстоящих отгрузок [Дней];
I – время производства поставщиком этой позиции до отгрузки [Дней].
 
То есть, мы будем осуществлять заказ только тех позиций, срок производства которых закончится как раз к моменту очередной отгрузки у поставщика.
 
Если такая G0 существует, то для дальнейших вычислений нам понадобится значение следующей за G0 ожидаемой в ближайшее время поставки:
, где
Gi  – количество дней до i-той отгрузки, ожидаемой от поставщика по графику предстоящих отгрузок [Дней];
Т – скорректированный период между поставками [Дней].
 
Точка G1 нужна нам для определения срока, на который мы будем производить закупку – соответственно по данной формуле она будет равна: либо уже известной дате поставки следующей за ближайшей, либо прогнозируемой дате, когда должно закончиться то, что придёт в ближайшей поставке – а браться из этих дат должна та, которая наступит раньше.
 
Расчёт потребности по позиции поставщика, в случае достижения по ней точки дозаказа.
Расчёт заказа осуществляется только для тех позиций, по которым была достигнута точка дозаказа (для позиций, по которым была достигнута точка заказа, точка дозаказа достигается автоматически). По аналогии с получением ряда 0j} рассчитываем и ряд для суммированного спроса за количество дней до следующей поставки 1j}:
, где:
C1j j-тая сумма спроса по позиции за количество дней до следующей поставки [Единиц];
Gi  – количество дней до i-той отгрузки, ожидаемой от поставщика по графику предстоящих отгрузок [Дней];
L – время доставки от поставщика [Дней];
Ci – спрос по позиции за i-тую дату [Единиц].
 
Количество единиц, необходимых для поддержания нужного уровня удовлетворения спроса остатками до следующей поставки, тоже рассчитывается аналогично предыдущей формуле, но с новыми переменными:
, где:
U1 – количество по позиции, необходимое для удовлетворения спроса остатками на необходимом уровне до следующей поставки;
C1j j-тая сумма спроса по позиции за количество дней до следующей поставки [Единиц];
N – необходимый уровень удовлетворения спроса остатками по позиции [%].
 
Тогда объём заказа по позиции будет равен:
, где:
X – необходимый заказ для удовлетворения спроса остатками на нужном уровне до следующей поставки объём заказа по позиции [Единиц];
K – кратность отгрузок по позиции, которая рассчитывается как наибольший общий делитель по всем отгрузкам клиентам компании или задаётся из кратности отгрузок по позиции у поставщика [Единиц];
U1 – количество по позиции, необходимое для удовлетворения спроса остатками на необходимом уровне до следующей поставки;
B – текущие остатки по позиции с транзитами и за вычетом оплаченных резервов [Единиц];
J – коэффициент округления, который задаёт направление округления [0÷1].
 
В данной формуле первое слагаемое в скобках отвечает за тот объём в рассчитанном заказе по позиции (U1 – B), который уже удовлетворяет условию кратности. Второе же слагаемое позволяет округлить в нужную сторону ту часть заказа, которая не удовлетворяет условию кратности. Коэффициент же округления J напрямую задаёт ту границу, выше которой мы округляем вверх, и соответственно может принимать любое значение от 0 до 1 (при J = 0 мы всегда округляем вверх; при J = 1 – всегда вниз; в случае если J = 0.5, осуществляется стандартное арифметическое округление).
 
Работа с данными.
Все приведённые расчёты рекомендуется в автоматическом режиме делать каждую ночь, а расчётные значения сохранять в плоских таблицах, по которым днём можно было бы строить соответствующие отчёты. Эти таблицы должны содержать для каждой записи расчётных параметров системы – значение параметра и ссылку на ключ из номенклатурной таблицы или справочника поставщиков, а для временных рядов данных – ещё и дату для каждой записи. В отчёт, который будет делать закупщик днём, должны выводиться по каждой позиции в абсолютных величинах и днях среднедневных продаж: значение необходимого заказа Х; свободные остатки B; текущие остатки, резервы и оплаченные резервы; средний спрос ; критические минимум m и максимум M; кратность отгрузок К; количества, определяющие точку заказа и объём дозаказа U0 и U1; срок производства I; закупочная цена Z и необходимый уровень удовлетворения спроса остатками N, – а также для каждого поставщика: период между поставками Т; время доставки L; ожидаемые даты поставок G0 и G1; необходимые и фактические оборачиваемость О и/или прибыльность Р. На основании этого отчёта, сделанного по конкретному поставщику, рекомендуется иметь возможность автоматически создавать документ заказа этому поставщику по этим позициям в этих количествах (Х) – это позволит избежать лишних ошибок при набивании заказа вручную, а так же избавит сотрудников от лишней рутинной работы.
 



Итог.
Для определения той модели закупок, которая будет давать лучшие результаты в каждой конкретной ситуации надо проводить их сравнительное математическое моделирование на ваших данных. И очень хочется надеяться, что авторы научных трудов, посвящённых модели многономенклатурных закупок с фиксированным периодом между поставками, теперь будут вынуждены сравнивать её с моделью, предложенной в данной статье, или хотя бы объяснять, почему они для своего изучения выбрали именно свою модель. Ниже приведена таблица, которая поможет предварительно прикинуть, какая модель лучше подходит в вашем конкретном случае:
МОДЕЛЬ
КРИТЕРИЙ
Фиксированный период
между закупками
Не фиксированный период
Спрос
Предсказуемый
Сильно вариативный
Плечо доставки от поставщика (LT)
Длинное
Короткое
Штраф за отсутствие на остатках
Небольшой (продажи)
Большой (производство)
Стоимость денег
Низкая
Высокая
Складских позиций от поставщика
Много
Мало

Утилита для расчета ABC и XYZ анализа

Шо это?

Это ABC/XYZ анализ для ленивых

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

Требования к операционной системе

Требований к операционной системе практически нет. Программа должна работать под Windows, Linux, Mac, всеми разновидностями UNIX. Для работы программе требуется java версии не ниже 1.6.0. Теоретически должно работать на любой начиная с 1.4 (это та, что стоит в стандартной поставке Windows, если Вы ни разу не обновляли), но поскольку у меня такой древности давно уже нет, я не в состоянии собрать программу под эту платформу. К тому же официально поддержка старой платформы заканчивается летом 2008г. Даже если Вы не собираетесь пользоваться данным софтом, крайне рекомендую поставить свежую версию, берут ее бесплатно здесь. На момент написания этого документа последняя версия была Java Runtime Environment (JRE) 6 Update 4. Если при запуске программы Вы получаете ошибку навроде " (Unsupported major.minor version 49.0)", значит необходимо установить свежую версию Java.

Как установить?

 

  1. Содержимое архива развернуть в любой удобный каталог
  2. Отредактируйте первую строку командного файла ABC.cmd, чтобы она указывала на установленную версию Java. К примеру, если Вы установили Java Runtime Environment (JRE) 6 Update 4, скорее всего строка будет выглядеть как

    SET JAVA_HOME=C:\"Program Files"\Java\jre1.6.0_04

  3. Запустите ABC.cmd, если все правильно, должно появиться нечто вроде этого

    Main window

Как это работает?

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

ART SDATE QTY
333 2007-01-01 0
333 2007-02-01 1.3
333 2007-03-01 1.5

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

Формат данных жестко задан

Первая колонка - артикул изделия. Формат - текстовая строка до 50 символов длиной.

Вторая колонка - дата в формате YYYY-MM-DD

Третья колонка - количество в формате числа с плавающей точкой

Порядок работы

  1. В поле Delimiter выбираем разделитель полей либо из списка, либо задав произвольный. По умолчанию используется символ табуляции. Внимание! Программа запоминает последний установленный разделитель и при следующем запуске будет пытаться использовать именно его.
  2. Нажимаем кнопку Data и выбираем файл с исходными данными. Программа открывает файл и сразу же импортирует данные. В зависимости от объема это может занимать заметное время. Внимание! Программа запоминает имя последнего файла данных и при следующем запуске будет пытаться использовать именно его.
  3. Кнопки ABC и XYZ производят соответствующие расчеты
  4. Для XYZ-анализа можно выбрать, по каким периодам будет делаться анализ.
  5. Кнопка Export to TXT, как нетрудно догадаться, экспортирует результаты всех расчетов в текстовый файл с параметрами, в точности совпадающими с исходным. Имя файла формируется как <имя исходного файла>.out.txt.
  6. Кнопка Open with Excel позволяет сохранить результат в виде файла MS Excel.
  7. Все. Для желающих посмотреть графики распределения сделаны закладки ABC и XYZ (не забудьте нажимать кнопку "Refresh"). Для желающих вгрузить это в Excel на файле отчеста нажать правую кнопку мыши, открыть с помощью Microsoft Excel

Настройки

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

Производительность

Исходные данные тестирования

Были взяты реальные данные о продажах за 12 месяцев по списку ~14.5 тыс. позиций, что составило ~2.7 млн записей. Поскольку ставилась цель провести анализ помесячно, после перехода к месчным продажам получился файл с ~173 тыс. записей. Результат:

Старт и инициализация 25 сек
Импорт данных 22 сек
ABC 1 мин 03 сек
XYZ 43 сек

 

Где брать?

Последняя версия берется здесь.

Удачи вам, вопросы можно (и нужно, наверное) задавать по адресу stanley ( at ) pochtamt.ru или на форумах logist.ru, zakup.ru - ник stanley.