СТАТЬИ >> ЭКОНОМИКА ПРЕДПРИЯТИЯ

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

Михаил Андреев. Email: ma@amand.ru

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

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

Источник: Компания АМАНД

СТАТЬИ >> ЭКОНОМИКА ПРЕДПРИЯТИЯ

О затратах переменных и постоянных

Чем переменные затраты отличаются от затрат постоянных? Ответ, казалось бы, очевиден. В жизни, увы, не все так просто и однозначно. Деление затрат на переменные и постоянные, абсолютно понятное на «книжном» уровне, на практике может вызывать определенные затруднения.

Сергей Шебек, Клуб борцов с затратами

Классификация затрат по характеру поведения в зависимости от объемов деятельности (или, говоря сухим академическим языком, «в зависимости от уровня деловой активности»), предполагает наличие затрат переменных, постоянных и смешанных. При всей внешней понятности данной классификации, ее практическое применение имеет определенные особенности. Часть из этих особенностей мы и рассмотрим.

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

Допустим, некий обыватель (стремительно подтягивающийся к уровню «среднего класса») приобрел газонокосилку для дачного участка. При этом он рассуждает так: «Через четыре года я заменю ее на новую. Хотя бы потому, что это сделают соседи». А может рассуждать и так: «Двигатель там стоит одноцилиндровый, с маленьким внутренним объемом, с примитивной системой смазки, поэтому будет хорошим результатом, если газонокосилка отработает 100 мото-часов». Оба варианта вполне обоснованы и логичны. Но только в первом случае амортизация газонокосилки является функцией времени, поскольку наш герой предполагает использовать ее в течение четырех лет, т.е. ориентируется на определенную продолжительность периода эксплуатации. А во втором случае - функцией уровня деловой (или «дачной») активности, поскольку за основу берется наработка оборудования. При том, что и в первом, и во втором случае, природа возникающих затрат одна и та же! Просто, мы меняем наш субъективый взгляд на эту природу. Реальная «жизнь» газонокосилки слабо зависит от наших оценок этой «жизни» и определяется, скорее, качеством самой газонокосилки, нашей умелостью и аккуратностью, а вовсе не способами начисления амортизации.

Еще пример.

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

Теперь представим, что анализ ведется экономистом, сидящим в «заводоуправлении». Экономист выписал все статьи затрат и рассуждает примерно так:

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

Затраты на содержание складских помещений и складского оборудования тоже никакой склонности к переменным не обнаруживают.

Поэтому получается, что хоть 250 тонн материальных ценностей пройдет через склад в течение месяца, хоть 280 тонн – затраты останутся неизменными. Вот когда объем деятельности склада перевалит за 300 тонн в месяц, тогда, возможно, появятся дополнительные затраты еще на одного грузчика».

И попробуйте сказать, что рассуждения эти – необоснованны!

Теперь посмотрим на «затратный механизм» глазами заведующего складом. Он ничего не знает о теории поведения затрат и признаках классификации. Словосочетание «статьи затрат» вызывает у него только одну ассоциацию – со «статьями УК». Но зато он прекрасно знает, что каждый привоз материальных ценностей на склад, разгрузка каждой машины сопровождается потерями: хоть один мешок с цементом, но порвется, хоть один бидон с краской, но обязательно прольется, хоть один ящик с метизами, но разобъется, хоть один поддон с кирпичом, но перевернется. Так что каждая поступившая на склад машина одновременно «привозит» с собой потерь и ущерба, в среднем, на 1000 руб. Так что если за месяц работники склада примут 30 машин, то можно сразу же (к гадалке не ходи) 30 тыс. руб. списать на потери».

Есть в этих рассуждениях логика? Конечно!

Величина тех или иных затрат зависит от какого-то фактора (или группы факторов). Этот фактор называют драйвером затрат. Так вот, на субъективный взгляд экономиста драйвером «складских» затрат является время (или продолжительность периода). А на субъективный взгляд заведующего складом драйвером затрат является количество разгруженных машин. При этом, как оказалось, оба субъективных взгляда вполне обоснованы и могут вполне мирно уживаться.

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

Идем дальше. Вот рассказ одного из наших респондентов.

Елена Панченко, ЗАО «ЭР-Телеком Холдинг», Директор по экономике и финансам:

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

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

Еще пример. Наша компания, в том числе, оказывает услуги вещания по сети кабельного телевидения. Мы, в свою очередь, покупаем услуги по ретрансляции (точнее, права на ретрансляцию) у собственников различных телевизионных каналов. Схема формирования стоимости услуг по ретрансляции может быть разной и зависит от договоренности с собственником каждого конкретного канала: в одном случае это может быть фиксированная сумма, в другом случае стоимость может зависеть от количества обслуживаемых нами абонентов. А бывает и так, что в данном периоде у нас одна схема формирования стоимости услуг владельца телеканала, а в следующем периоде – другая. При этом, заметьте, что технические, потребительские и прочие характеристики, порядок потребления приобретаемой нами услуги по ретрансляции в обоих случаях являются одинаковыми. Но в одном случае наши затраты будут условно-постоянными, в другом случае - переменными…»

Собственно, идея данного рассказа понятна и без пояснений. Так что остается только сделать вывод.

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

Далее. Выше мы уже упоминали понятие «драйвер затрат» - фактор, определяющий величину затрат. Что может быть таким фактором, и легко ли его выделить? Конечно, в большинстве случаев такой фактор достаточно очевиден – количество производимых продуктов. Оно может измеряться в штуках, декалитрах, погонных метрах и прочих натуральных показателях.

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

Весьма показательным, в этом смысле, является пример с авиаперевозками. Вот лишь некоторые из статей затрат, возникающие в практике деятельности авиакомпаний, и которые можно отнести к переменным:

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

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

· Сборы аэропорта за взлет-посадку – зависят от количества взлетов и посадок, т.е. от количества выполненных рейсов. (Показатель уровня деловой активности – количество выполненных авиарейсов.)

· Сборы аэропорта за обслуживание пассажиров - зависят от количества перевозимых пассажиров. (Показатель уровня деловой активности – количество перевозимых пассажиров.)

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

· Амортизация воздушного судна (в частности, основного компонента воздушного судна – планера) - зависит как от налета часов, так и от количества взлетов-посадок. (Показатели уровня деловой активности – налет часов и количество выполненных авиарейсов.)

· Сборы за аэронавигационное обслуживание воздушных судов на воздушных трассах - зависят от «пробега», т.е. от общей протяженности маршрутов, по которым выполнялись рейсы. (Показатель уровня деловой активности – «пройденное» воздушными судами расстояние.)

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

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

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

Резюме:

Деление затрат на переменные и постоянные, абсолютно понятное на «книжном» уровне, на практике может вызывать определенные затруднения.

Вот лишь некоторые из них.

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

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

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


СТАТЬИ >> ЭКОНОМИКА ПРЕДПРИЯТИЯ

О затратах прямых и не очень

Сергей Шебек, Клуб борцов с затратами

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

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

«Прямые затраты – это те затраты, которые можно непосредственно (т.е. прямо!!) отнести на одельные виды продукции (работ, услуг)».

Мы же предлагаем более «либеральный», более широкий взгляд на этот вопрос и говорим, что в основе деления затрат на прямые и косвенные лежит возможность их отнесения не только на отдельные видов продуктов, но и на любые объекты учета (управления) вообще. А определение «прямых затрат», в нашей трактовке, звучит так:

«Прямые затраты – это затраты, возникновение которых непосредственно связано с каким-либо объектом учета (использованием, созданием, деятельностью объекта учета)».

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

- Структурные единицы компании (или как их еще называют «места возникновения затрат») – дивизионы, дирекции, отделы, цехи и т.д.;

- Процессы, реализуемые внутри компании – процессы снабжения, обслуживания клиентов, ремонта основных средств и т.д.;

- Объекты основных средств и объекты капитальных вложений;

- Реализуемые компанией проекты (хотя их можно считать частным случаем процессов);

- Клиенты и партнеры;

- Каналы сбыта и регионы, в которых компания присутствует

- И т.д.

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

Так в чем же преимущества такой более широкой и «либеральной» трактовки?

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

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

Классический пример. Существует группа оборудования, на которой производится несколько видов продуктов. Конечно, затраты на содержание и эксплуатацию данного оборудования сложно отнести прямым образом на отдельный вид продуктов. Но и не надо бросаться в другую крайность. Если нельзя «прямо», то не надо намерено увеличивать их «косвенность». К сожалению, в жизни так и происходит. Не удается учесть на уровне конкретного продукта и эти затраты попадают в категорию «Общепроизводственные затраты». Начисляются на уровень «цеха в целом». А потом «с высоты цеха в целом» распределяются на отдельные виды продукции (как правило, пропорционально заработной плате).

Но дело не только в том, что традиционный подход провоцирует нас на некорректный расчет себестоимости. Гораздо хуже другое. Повышение эффективности бизнеса, при применении данного подхода, становится недостижимой мечтой. Тот же пример с оборудованием. Допустим, на соседнем участке работает аналогичное оборудование и в таком же количестве. При этом затраты на его обслуживание и ремонт в два раза ниже, чем на нашем участке. Мы задаем вопрос: «А почему?» Так вот, при традиционном отношении к прямым затратам нам даже в голову не придет, что затраты на ремонт оборудования могут быть прямо отнесены на отдельные группы оборудования на разных участках! И мы добросовестно эти затраты отнесем на «цех в целом». Поэтому мы не только не сможем найти ответ на вопрос «А почему там затраты выше, а там ниже?» У нас данный вопрос попросту и не возникнет…

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

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

Представим мастера, начальника участка, в условиях «плохого» учета, когда «принцип относительности» не используется. Он несет персональную ответственность за выполнение производственного плана, соблюдение норм использования основных материалов и «неприкосновенность» фонда оплаты труда. Т.е. за прямые затраты в их традиционном понимании. Все прочие затраты волнуют его мало, поскольку они «косвенные», начисляются на уровень «цеха в целом». Стало быть, и отвечать за них будет не он (мастер), а начальник цеха.

К мастеру обращается один из подчиненных: «Кузьмич! Что-то у меня на станке повышенный расход масла (эмульсии, электроэнергии, инструмента и т.д.), надо бы вызвать слесаря (электрика, наладчика и т.д.)!» А зачем мастеру таки нужны эти проблемы? Если масло – «косвенное» по отношению к нему, и отвечает за это масло (за затраты на масло) начальник цеха. И что этот мастер должен ответить подчиненному? А примерно так: «Хоботов, не морочь голову руководству! Иди в кладовую и возьми там ведро масла!»

А теперь та же ситуация в условиях «хорошего» учета, когда реализован «принцип относительности» затрат. В этом случае полученное масло будет прямо отнесено на мастера (точнее, вверенный ему участок). Поэтому и его ответ подчиненному будет другим: «Хоботов, заканчивай там, я тебе дам сейчас другую работу и пойду вызывать слесарей!»

Надеюсь, мы были достаточно убедительными в представлении преимуществ «принципа относительности». Впрочем, предложенный подход было бы нескромно и несправедливо называть «чисто нашим». Такая же точка зрения, в частности, встречается и у немецких специалистов. В том числе, Riebel и Horvath вводят понятие «относительно прямые затраты», подразумевая, что говорить о прямых затратах можно, только уточняя, по отношению к чему они являются прямыми. Но если немцы пришли к данным взглядам уже после Второй мировой войны, то отечественные специалисты эти вопросы подымали гораздо ранее. Думаем, что Вам будет интересно ознакомиться со следующей выдержкой из книги «Основы правильной калькуляции» (С. Г. Тер-Акопьянц, Москва, «Труд и книга», 1925 г.):

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

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

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

Резюме:

Традиционно прямыми называют затраты, которые непосредственно (т.е. прямо!!) связаны с производством и сбытом отдельных продуктов.

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


Прыг: 01 02 03 04 05 06 07 08 09