Несмотря на большое количество внедрений Microsoft Axapta в России, модуль «Сводное планирование» внедряется сравнительно редко. По опыту специалистов нашей компании, основная причина отказа от данного модуля кроется не в его недостатках, а в неумении ключевых пользователей им пользоваться. В результате, планирование закупок либо переписывается в системе, либо производится вне её.

В худшем случае закупки не планируются централизованно, а менеджеры по закупкам пополняют запасы на свой страх и риск, исходя из своего личного опыта работы. В то же время именно наличие данного (или аналогичного) модуля отличает систему MRP (ERP) класса от учётной системы.

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

Как правило, в компаниях, не использующих системы MRP класса для планирования закупок, складываются свои, особенные методы расчёта потребностей в материалах и товарах. Более того, во многих из таких компаний планирование закупок автоматизировано, как правило, собственными разработками (нашим специалистам удалось наблюдать довольно широкий спектр программных продуктов для планирования закупок – от простейших формул и макросов в Microsoft Excel до огромных процедур на языке PL/SQL в базе данных Oracle). Терминология и методология таких продуктов обычно формируется эволюционно, в зависимости от знаний и умений пользователей и программистов. В результате, пользователи привыкают к такому «птичьему языку» своих систем и с большой неохотой воспринимают, а то и откровенно саботируют, переход на новую систему. Несмотря на различия реализации планирования закупок в разных системах, большинство систем MRP класса оперируют общими понятиями, определёнными стандартами (методологиями) MRP и MRP II. Поэтому знакомство с модулем мы начнём с определения данных понятий применительно к системе Microsoft Axapta версии 3.0 SP4 FP1.

Основные понятия модуля «Сводное планирование»

Большинство терминов Аксапты соответствует терминам стандарта MRP, но в некоторых случаях термины Аксапты и стандарта существенно различаются, как в английском, так и в русском интерфейсах.

Потребности

Под потребностями (в англоязычном интерфейсе — Requirements) понимаются планируемые расходы по открытым строкам заказов, CRM предложений, материалов для производственных заказов, планируемые расходы по проектам и складским журналам, а также прогнозируемые продажи и минимальный запас на складе, который необходимо поддерживать. Обычно термин употребляется в более узком смысле: брутто- или нетто-потребности (Gross & Net Requirements).

Покрытие

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

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

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

Например, на приведённом ниже рисунке первая строка является покрытием (значение поля «Требуемое количество» положительно), а вторая потребностью (значение поля «Требуемое количество» отрицательно).

По этим причинам в Аксапте термин покрытие применяется крайне редко, вместо него обычно применяется термин потребность. Из-за разницы в знаках к путанице это не приводит.

Графически потребности обычно обозначаются стрелками вниз, а покрытия — стрелками вверх.

Брутто-потребности

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

Пример результата расчёта брутто-потребностей изображён на рисунке.

В данном примере строки со ссылкой «Прогноз продаж» были получены из прогнозов продаж. А строки со ссылкой «Спланированные закупки» являются результатом расчёта покрытия для брутто-потребностей.

Отдельно расчёт брутто-потребностей осуществляется, как правило, для длительных периодов.

Нетто-потребности

Нетто-потребности (Net requirements) рассчитываются, как правило, на менее длительный период, чем брутто-потребности. Их расчёт наиболее точен, но требует больших вычислительных ресурсов, так как в расчёт включаются все планируемые движения товаров и остатки на складах.

В расчёт нетто-потребностей включаются:

• Брутто-потребности, полученные на основе прогнозов продаж и закупок,
• Остатки на складах,
• Открытые строки заказов,
• Открытые строки закупок,
• Неразнесённые складские журналы,
• Открытые производственные заказы,
• CRM предложения.

Любой из вышеперечисленных источников может быть исключён из расчёта нетто-потребностей настройками сводного плана.

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

Прогнозные модели

Прогнозная модель (Forecast model) представляет собой один из сценариев, по которому будут происходить продажи. Например, можно создать оптимистическую, пессимистическую и наиболее вероятную модели. Аксапта позволяет использовать неограниченное количество прогнозных моделей, но при расчёте потребностей может быть использована только одна из них. Для создания комбинаций разных сценариев можно использовать подмодели. Тогда в расчёт потребностей будут включены все прогнозы текущей прогнозной модели и всех её подмоделей. Например, при включении в расчёт потребностей модели «КОМБИ» будут включены также подмодели «1-ОПТ» и «2-ПЕСС»:

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

Прогнозы

Прогноз (Forecast) представляет собой планируемые продажи (Sales forecast) или закупки (Purchase forecast) какого-либо материала или товара по одной из прогнозной модели. Совокупность прогноза продаж и закупок называется прогнозом запасов и используется для получения брутто-потребностей.

Пользователь может использовать возможности автоматического создания множества строк прогнозов по определённым алгоритмам на основании одной строки, введённой пользователем, при изменении количеств товаров в которой система сама пересчитает данные в автоматически созданных строках. Наиболее простой механизм — «Период». В этом случае система автоматически создаст строки прогноза через равные промежутки времени (день, месяц, год), начиная с даты прогноза до даты, указанной в поле «Завершение». Например, создадим прогноз продаж одной номенклатуры по 20 штук 10 числа каждого месяца в течение первого полугодия:

В данном примере система автоматически создала на основе одной вручную введённой строки (верхняя часть формы) 6 строк прогноза (нижняя часть формы), начиная с 10.01.2006 через каждый месяц по 30.06.2006.

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

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

В данном примере программа автоматически создаст на основе строки в прогнозной модели «ОПТ» новую строку прогноза в прогнозной модели «2-ПЕСС» со сдвигом даты прогноза на 5 дней и уменьшив количество в прогнозе на 20%:

Для групповых операций можно нажать кнопку «Выбор» и указать критерии выборки прогнозов, к которым должна быть применена данная операция. Например, в данном случае выбраны все строки прогнозных моделей «ОПТ» и «2-ПЕСС».

Ключи распределения

С ключами распределения (Period allocation keys, в русском переводе слово Период отсутствует) мы сталкиваемся довольно регулярно. Наиболее показателен пример с оценкой прогноза продаж в разрезе кварталов либо месяцев. В большинстве отраслей объёмы продаж не являются постоянными на протяжении всего года. Есть периоды спада и подъёма, максимума и минимума. Чтобы не определять планы на каждый период (квартал, месяц, неделя, день), а потом их править вручную при изменении прогнозов, используется автоматическое распределение суммы (объём продаж, затраты и т.п.), указываемой за больший промежуток времени, по более мелким периодам. Например, распределение планируемых продаж за год по кварталам или месяцам, распределение планируемых затрат за месяц по дням или неделям.

Давайте посмотрим работу ключа распределения на примере. Допустим, продажи некоторой группы товаров летнего ассортимента имеют такое распределение по месяцам:

Месяц	Процент
Январь	2%
Февраль	3%
Март	5%
Апрель	10%
Май	10%
Июнь	15%
Июль	15%
Август	15%
Сентябрь	10%
Октябрь	7%
Ноябрь	5%
Декабрь	3%

В Аксапте данное распределение можно оформить в виде ключа распределения из 12 строк - по одной строке для каждого месяца с указанием сдвига для каждой строки: 0 месяцев для первой строки, 1 месяц для второй и так далее до 11 для двенадцатой строки.

Чтобы указать, что данный ключ применяется именно к календарным месяцам, устанавливаем флаг «Фиксировано». В противном случае, система будет каждый раз сдвигать периоды от даты, указанной в строке прогноза.

В итоге получаем распределение по календарному году в разрезе месяцев:

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

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

Ключи сокращения

Ключи сокращения (Reduction keys) выполняют более «тонкую» настройку прогнозов за счёт учёта влияния на спрос различных внешних или внутренних факторов. Например, в результате воздействия внешних факторов (поздняя весна, правительственный кризис) или внутренних (появление нового аналога товара в ассортименте, скидки на товар-заменитель) в ближайшие месяцы наши продажи данного товара будут ниже планируемых. Для такой цели более удобно использовать ключ сокращения, который скорректирует наши прогнозы с учётом данного фактора. Например, данный ключ сокращения показывает, что в течение всего февраля объём продаж будет меньше на 30% от прогнозированного.

Ключи распределения номенклатуры

Ключ распределения может быть не только по времени, но и номенклатуры (Item allocation keys). Он очень полезен в тех случаях, когда планирование по отдельным позициям требует слишком больших трудозатрат, и требуется запланировать продажи по группам товаров с автоматическим распределением по позициям. В качестве самого простого примера создадим ключ распределения номенклатуры с тремя позициями 50%, 25% и 25% (ключ распределения номенклатуры использован также в Примере 2). При расчёте потребностей с данным ключом распределения номенклатуры система сама распределит количества по конкретным товарным позициям.

Например, запрогнозировав продажи компьютеров в количестве 200 шт., система автоматически разобьёт этот прогноз по отдельным позициям:

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

Прогнозные планы

Прогнозный план (Forecast plan) объединяет прогнозы по выбранной прогнозной модели и созданные на их основе брутто-потребности. Прогнозных планов создаётся, как правило, несколько для разных сценариев.

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

Сводные планы

Сводный план (Master plan) включает в себя запасы в наличии, прогнозный план, планируемые расходы и приходы по открытым строкам заказов и закупок, складских журналов, производственных заказов и CRM предложений (только тех, вероятность которых большей указанной в поле «Вероятность в %») и рассчитанных на их основе покрытий.

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

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

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

Коды покрытия

Коды покрытия (Coverage codes) представляют собой варианты алгоритмов, на основе которых формируются планируемые закупки, производственные заказы или складские переносы.

Код покрытия «Потребность»

Код покрытия «Потребность» (Requirement) является наиболее простым. Он формирует планируемые приходы товаров непосредственно перед их расходами, как показано на рисунке:

Как правило, закупка должна производиться не при нулевых остатках, а при достижении допустимого минимального значения (резервный запас, см. Минимальный запас). Размер закупки зависит от многих других настроек, в частности, минимального размера заказа и кратности заказа.

В результате график остатков на складах приобретает такой вид:

Код покрытия «Период»

Код покрытия «Период» (Period) отличается от кода покрытия «Потребность» тем, что формирует закупку не под каждую потребность, а суммарно под все потребности за некоторый временной период (например, в одном из проектов швейного производства интервал составлял одну декаду — 10 дней), как показано на рисунке:

В результате график остатков на складах приобретает вид ступенек:

Код покрытия «Min/Max»

Код покрытия «Min/Max» (Min./Max.) создаёт закупку в тот момент, когда остатки на складах становятся равны или ниже какого-то фиксированного значения «Min», а при формировании планируемой закупки устанавливает количество товара таким, чтобы остатки на складе достигли какого-то фиксированного значения «Max». В вышеприведённом графике превышение остатков товаров при закупке выше значения «Max» может быть связано с условиями поставки - минимальным размером заказа или кратности заказа.

Существует ещё код покрытия «Вручную», который указывает системе, что покрытие для данного товара автоматически не рассчитывается, а пользователь формирует его вручную.

Группы покрытия

Чтобы параметры покрытия не настраивать для каждого товара в отдельности, используются группы покрытия (Coverage group). Группа покрытия, указанная в форме параметров модуля, используется по умолчанию для номенклатур, для которых не указана группа покрытия и не настроены параметры покрытия, индивидуальные для номенклатуры.

Временные резервы

Резервы (Margins, в версии Axapta 2.5 данный термин был переведён на русский язык как «Маржа») — временные интервалы в днях, которые необходимо учесть при планировании. Например, время, необходимое для транспортировки товара от склада поставщика на склад покупателя. В системе предусмотрены три вида временных резервов: «Резерв заказа у поставщика» (Reorder margin), «Резерв прихода» (Receipt margin) и «Резерв расхода» (Issue margin).

Кроме временных резервов, в системе предусмотрен ещё один временной параметр — «Время доставки» (Lead time), который может быть разным у каждого поставщика, и указывается в коммерческих соглашениях. Можно даже предусмотреть возможность указания разных цен одного и того же поставщика в зависимости от сроков поставки (плата за срочность). В случае, если для пополнения склада вместо закупки используется перемещение с другого склада (такой склад называется в системе основным), используется временной параметр «Время переноса», указывающий количество дней, необходимых для перемещения товара на склад с основного склада.

Мероприятия

Мероприятие (Action, другой русскоязычный термин — Действие) — один из возможных результатов работы сводного планирования. Суть его — рекомендовать пользователю совершить действия по уменьшению складских остатков или сдвигу, уменьшению или увеличению закупки, переноса или производственного заказа с целью наиболее эффективного использования складских площадей и денежных ресурсов. Стоит отметить, что мероприятие — только рекомендация программы, пользователь может проигнорировать рекомендации. В системе предусмотрен целый ряд параметров, определяющих, каким образом система может создавать мероприятия. Например, можно предусмотреть, что система осуществляет сдвиг закупки максимум на 3 дня, может предложить её уменьшить или увеличить, но те закупки, которые планируются на ближайшую неделю, изменять уже нельзя. Кроме того, система сама может обновить даты закупок, если пользователь сделал соответствующие настройки.

Фьючерсы

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

Минимальный запас

Минимальный запас (Minimum) используется в качестве минимального уровня запасов, ниже которого нельзя опускаться при любом коде покрытия. Используя специальные Ключи резервного запаса (Minimum/Maximum keys), можно настроить систему таким образом, что она будет поддерживать минимальные остатки на складах с учётом сезонного спроса:

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

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

Положительные и отрицательные дни

Основная цель положительных (Positive days) и отрицательных дней (Negative days) — сократить количество закупок с целью минимизации транспортных затрат.

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

Для простоты анализа предположим, что ни для Закупки 1, ни для Закупки 2 потребностей нет. В случае, если параметр положительные дни меньше расстояния от Потребности до Закупки 1, а параметр отрицательные дни меньше, чем расстояние от Закупки 2 до Потребности, система предложит удалить Закупку 1 и Закупку 2 и создать Новую закупку, как изображено на рисунке.

В случае, если положительные дни больше или равны расстоянию от Закупки 1 до нашей потребности, система будет пытаться сдвинуть (отсрочить) и при необходимости изменить объём Закупки 1 вместо создания новой закупки. Закупку 2 система предложит удалить.

А в случае, если отрицательные дни больше или равны расстоянию между Закупкой 2 и нашей потребностью, система будет пытаться увеличить и ускорить (сдвинуть на несколько дней) Закупку 2, а Закупку 1 предложит удалить.

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

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

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

Примеры формирования плана закупок

Пример 1. Поставка товаров под заказ (торговля оптом)

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

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

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

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

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

Выбор кода покрытия

Наиболее подходящим в данном случае кодом покрытия является «Потребность». Код «Период» может подойти для мелких и недорогих товаров, являющихся сопутствующими и сравнительно недорогими, доставка которых малыми партиями нерентабельна. Например, для ковриков в компьютерном магазине. Код «Мин/Макс» в данном случае совсем мало применим.

Формирование сводного плана

Делаем настройку сводного плана. Указываем необходимость учёта остатков на складах, открытых строк закупок и открытых строк заказов, CRM предложений:

Пример результата планирования

На рисунке показан вариант результата сводного планирования закупок по двум заказам клиента:

В случае существования закупки на 1 единицу товара на начало месяца и установки параметра положительные дни больше, чем время от закупки до последней потребности, система создаст мероприятие, предлагая увеличить объём закупки и сдвинуть её на более поздний срок перед первой продажей:

Таким образом, вместо трёх закупок в месяц будет одна перед первой потребностью.

В случае, если поставка не может быть выполнена в срок, система генерит фьючерс. Например, в данном случае система сообщает о том, что наш заказ клиента на 17 марта может быть выполнен только на 4 дня позже, а, именно, 21 марта:

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

Пример 2. Поставка товаров на склад (торговля в розницу, торговля со склада)

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

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

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

Выбор кода покрытия

В качестве кода покрытия в данном случае имеет смысл поставить «Период». Длительность периода может быть любой в зависимости от наших продаж и отношений с поставщиком. В качестве примера мы взяли длительность интервала 4 дня, чтобы поставщик привозил товар 1-2 раза в неделю.

Формирование прогнозного плана

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

Формирование сводного плана

Сводный план должен включать в себя остатки на складах, открытые строки закупок (у нас могут быть одновременно открыты 2-3 закупки, которые поставщик должен выполнить в ближайшие 1-2 недели). Никаких CRM предложений нет. Обязательно нужно правильно настроить параметры положительные и отрицательные дни. Положительные дни можно поставить 30 дней (товар длительного хранения), а отрицательные, например, 4 дня. В этом случае при отсутствии одного вида масла система не будет пытаться срочно докупить, а предложить подождать или ускорить закупку. Разумеется, необходимо указать минимальные количества каждого масла для выставления их на витрине магазина, но в нашем примере мы оставим их равными нулю.

При указанных наших данных система автоматически создаст закупку на весь ассортимент масла на ближайшие 4 дня продаж, учитывая при этом необходимость кратного количества в закупке (в ящике 6 бутылок):

Основные проблемы при настройках сводного планирования для розницы — расчёт прогнозов и минимального (резервного) запаса. Готового инструмента для расчёта прогнозов Аксапта не содержит. Наиболее простое решение предлагается на базе другого продукта компании Microsoft — Demand Planner, который полностью интегрируется с Micrisoft Axapta.

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

Пример 3. Поставка запасных частей (сервис)

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

Постановка задачи

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

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

Для примера искусственно создана статистика продаж со склада за три месяца, с декабря 2005 по февраль 2006:

Настройки планирования состоят из двух этапов:

1. Определение минимального (резервного) запаса на основе статистики продаж, времени упреждения и необходимого уровня сервиса (понятие уровень сервиса в данном случае определяет вероятность наличия товара на складе при возникновении запроса у клиента, более подробно данное понятие описано в [2] стр. 78-79).
2. Настройка сводного плана.

Определение минимального (резервного) запаса

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

Система рассчитала средние продажи и среднеквадратическое отклонение:

Теперь можно рассчитать уровень минимального запаса с учётом нашего времени упреждения и требуемого уровня сервиса:

В итоге система определила новый минимум в количестве 4 штук на нашем складе:

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

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

Настройка сводного плана

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

Выводы

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

Кроме того, внедрение модуля Сводное планирование, как и любой системы, работающей по методологии MRP, требует выполнения ряда условий, необходимых для построения правильной системы планирования на предприятии, а также ряда организационных мероприятий (см. [1], стр. 13).

Литература

1. Д.А. Гаврилов. Управление производством на базе стандарта MRP II. Принципы и практика. Питер. 2002.
2. М.Кристофер. Логистика и управление цепочками поставок. Питер. 2004.

Читайте также:
Пример бюджетирования в Аксапте
Анализ ликвидности в Аксапте