FineFinance.ru - информационный портал
Курсы валют
Курсы валют ЦБ РФ
Дата:00:0000:00
Курс доллара 0.000.00
Курс евро 0.000.00
Курс фунта 0.000.00
Курс бел. рубля 0.000.00
Курс гривны 0.000.00
Курс франка 0.000.00

Планирование закупок в Axapta на примере торговой компании

Несмотря на огромное количество внедрений 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) рассчитываются на менее длительный период, чем брутто-потребности. Их расчёт наиболее точен, но требует больших вычислительных ресурсов, так как в расчёт включаются все планируемые движения товаров и остатки на складах.

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

Прогнозные модели. Прогнозная модель (Forecast model) представляет собой один из сценариев, по которому будут происходить продажи. Например, можно создать оптимистическую, пессимистическую и вероятную модели. Аксапта позволяет использовать неограниченное количество прогнозных моделей, но при расчёте потребностей может быть использована только одна из них. Для создания комбинаций разных сценариев можно использовать подмодели. Тогда в расчёт потребностей будут включены все прогнозы текущей прогнозной модели и всех её подмоделей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также: Методы учета фактора времени в финансовых операциях.

Вернуться к разделу «Финансовый менеджмент»

 

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

Каталог курсов и семинаров

Котировки акций
Анонсы и Обзоры

Наши финансовые партнеры / USA Financial Partner:
1Payday.Loans

   Copyright © 2010-2024 «FineFinance.ru»    При использовании материалов гиперссылка на FineFinance.ru обязательна    Настоящий ресурс может содержать материалы 16+    Обо всех замеченных ошибках при работе сайта просьба сообщать при помощи формы обратной связи