Анализ основных стадий планирования товароснабжения розничной торговой сети

      Рис.1. Одна из версий структуры  MRPII.                             

      Простейшие  формы MRP могут работать в среде чистого производства на заказ с достаточно длительным временем выполнения заказа, чтобы планирование потребностей в материалах основывалось строго на полученных заказах, — например, это классическое производство мебели под заказ, время выполнения которого составляет 15-20 недель. Однако во многих случаях приходится принимать заказы, срок выполнения которых меньше, чем время выполнения заказа на материалы, а значит, возникает потребность планировать на основе прогноза продаж. Отсюда понятно, что грамотное прогнозирование и планирование продаж необходимо в большинстве бизнесов. Для плани рования средне- и долгосрочных изменений в производственных мощностях и трудовых ресурсах дополнительно требуется функция планирования ресурсов. А для планирования объемов производства тех или иных групп товаров в среднесрочный период нужен производственный план.

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

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

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

      MRP II — это самая точная и подробная универсальная структура планирования потока товаров из всех когда-либо созданных. Ее пропагандировали большинство экспертов, и она легла в основу «крестового похода MRP», провозглашенного APICS (Американским обществом контроля продукции и запасов) в 1970-1980-х годах. Многие поставщики программного обеспечения стали создавать программные пакеты для внедрения стандартной спецификации MRP II (самые первые программы MRP, как правило, кастомизировались IT - группами на самих предприятиях). Эти программные пакеты MRP II стали разрастаться в размерах и включать в свой состав программы по учету запасов и управлению заказами клиентов — иными словами, речь стала идти не только о планировании, но и о выполнении многих базовых ежедневных трансакций предприятия.

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

    Семейство программ MPR в 1990-е годы разрослось, превратившись в систему планирования ресурсов предприятия (ERP) и включив программные модули, касающиеся таких крупных неоперационных участков бизнеса, как кадровый учет и управление финансами. EPR превратилась в завершенную систему целостного управления бизнесом, а собственно планирование стало лишь небольшой ее частью. Имелись очевидные причины для связывания операций с бухгалтерией — например, программа стала фиксировать выполнение заказа на изготовление и немедленно вносить надбавку к стоимости запасов в бухгалтерскую книгу компании. С началом XXI века поставщики EPR начали добавлять к EPR интернет-модули по CRM (менеджменту взаимоотношений с клиентами) для повышения эффективности взаимодействий с клиентами и работы персонала по продажам, а также по управлению взаимоотношениями с поставщиками (SRM) для улучшения снабжения и работы с поставщиками. Такого рода расширенную систему ERP иногда называют ERPII.

    Итак, MRP не только структурировала мышление о планировании операций, но и легла в основу интегральных систем, которые способны обслуживать большинство трансакций предприятия. Создание MRP/ERP было признанием эффективности простых рациональных концептов, а также итогом целенаправленного продвижения, занявшего несколько десятилетий.

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

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

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

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

2.3. Оперативное управление поставками при помощи компьютерных технологий

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

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

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

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

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

    Управление  событиями совершенно определенно  сдвинуло центр тяжести планирования ближе к выполнению работ. Хорошим примером этому служит то, что случилось в последние годы с АТР -логикой. АТР, классический метод управления планируемыми заказами, естественным образом вырос из сферы MRP и основного производственного плана-графика (MPS). Действительно, основная для АТР калькуляция может выполняться в таблице, фазированной по времени MRP-MPS (32). Однако с появлением в 1990-е годы усовершенствованных информационных систем для слежения за перевозками и запасами, дающих непрерывную визуализацию процессов, стало понятно, что некоторые типы управления планируемыми заказами гораздо лучше осуществляются путем сочетания логистической информации в реальном времени и производственного графика.