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.


Итого:

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