При внедрении MRP-систем на промышленных предприятиях в лексиконе автоматизаторов рано или поздно появляется термин «заявочная кампания», «заявка». Зачастую с большой неохотой приступают специалисты к автоматизации «заявки», объясняя это тем, что процесс «не ложится» в MRP-систему. «Не ложится» означает, что процесс стандартными средствами системы не реализуется, а значит — вместо простой настройки стандартных модулей системы надо писать собственные программные решения и интегрировать их со стандартной функциональностью. Сопровождение такого решения, так или иначе, будет зависеть от программистов, с полным «букетом» минусов, от которых как раз и старались уйти при внедрении MRP-системы.
Ключевые пользователи службы материально-технического обеспечения и руководство компании обычно единодушны в своем мнении: «Раз уж мы купили такую дорогущую систему, она должна уметь делать все, что нам требуется» — и, негодуя, обвиняют ИТ-службу в неумении внедрять серьезные системы. И далеко не каждый ИТ-специалист сможет объяснить, что эти сложности объективны и обусловлены ограничениями бизнес-моделей, реализованных в MRP-системах. Почему же простые с виду процессы вызывают большие проблемы при их автоматизации с помощью таких «продвинутых» систем?
Этапы типичной заявочной кампании
Типичная заявочная кампания состоит из следующих этапов:
Заявление первичных потребностей от подразделений. Целью этого этапа является получение информации о потребностях от непосредственных получателей. Это что-то вроде плана-максимума, при этом каждое подразделение-получатель заявляет материалы только от своего имени и оперирует только количествами материалов без цен.
Экспертный анализ потребностей специалистами по номенклатуре. На промышленных предприятиях, как правило, есть эксперты, которые отвечают за использование определенных групп материалов. Например, отдел главного механика отвечает за металлопрокат, трубы и метизы, а отдел главного энергетика — за лампы, кабели и электродвигатели. Должности этих экспертов могут называться по-разному — главные специалисты, функциональные специалисты, специалисты по номенклатуре, эксперты по номенклатуре и так далее. Именно они формируют для предприятия правила работы с определенной номенклатурой материалов и оборудования. В идеале — они же ведут номенклатурный справочник материалов. Как правило, эти специалисты работают в соответствующих функциональных подразделениях, однако на некоторых предприятиях они работают в структуре службы МТО.
В рамках заявочной кампании специалисты по номенклатуре проводят экспертный анализ потребностей с точки зрения обоснованности заявленной номенклатуры и количества материалов («интересно, зачем нам на январь 100 тонн гвоздей?»).
В зону ответственности специалистов по номенклатуре также входит контроль потребностей на соответствие унифицированной номенклатуре, некоему стандарту, принятому на предприятии («вместо отверток длиной 20 см и 25 см будем использовать отвертки длиной только 25 см»), а также выявление и устранение дубликатов номенклатурного справочника. Например, заявленные позиции «Лампа 220 В», «ЛАМПА 220 В», «лампа 220», «лампа накаливания 220 В» с точки зрения справочника — это разные номенклатуры, и задача ответственного — определить эталонную запись, а остальные запретить или даже удалить из справочника.
Установление для подразделений лимитов на списание материалов. С точки зрения потребителя, материалов на складе должно быть столько, чтобы «на всю оставшуюся жизнь хватило». Но с экономической точки зрения выгодно закупать и хранить ровно столько материалов, сколько может фактически потребить предприятие для обеспечения производства при запланированной себестоимости. Поэтому необходимо как-то ограничивать заявляемые потребности. В качестве таких ограничителей используются суммовые лимиты списания материалов в производство.
Лимиты рассчитываются для каждого подразделения компании на основе данных производственной программы на год, плановых объемов выпуска и себестоимости для каждого вида продукции. Так появляется лимит списания материалов в затраты, который планируется и контролируется плановой службой. Но для того чтобы сравнить заявленные потребности и установленные лимиты, потребности должны быть оценены в суммовом (ценовом) выражении, для чего и нужен следующий этап — расценка.
Предварительная расценка потребностей. На этапе экспертного анализа потребностей специалисты авторитетно подтвердили только то, что «данная номенклатура действительно нужна заявителю именно в таком количестве». Но с экономической точки зрения оценка не производилась, а значит, экономисты-плановики могут просто не разрешить выдать все заявленные материалы в производство из-за превышения лимита списания материалов в затраты.
Единственным подразделением, которое может условно расценить материалы, является служба МТО (материально-технического обеспечения). На практике для материалов, которые уже закупались, принимаются цены последней закупки, умноженные на некий дефлятор (коэффициент изменения цен). Для новых материалов, которые ранее не закупались, проводится, как правило, экспресс-оценка через первого попавшегося поставщика в Интернете. В результате для каждого материала, фигурирующего в заявке-потребности, появляется условная цена списания этого материала в производство, и все потребности становятся пригодными для сравнения с лимитами.
На этапе расценки специалисты службы МТО также выявляют устаревшие позиции номенклатуры, которые больше не производятся, не могут быть закуплены и отсутствуют на складах. Например, модели вычислительной техники и контрольно-измерительных приборов зачастую меняются несколько раз в год с небольшим изменением эксплуатационных характеристик. Обо всех изменениях в номенклатурном справочнике служба МТО сообщает специалистам по номенклатуре и подразделениям-заявителям, чтобы откорректировать потребность на следующем этапе.
Корректировка потребностей с учетом цен и замены номенклатуры. Самый напряженный этап заявочной кампании — это процесс «вписывания в лимиты», так как подразделения вынуждены сокращать заявленные позиции, чтобы итоговая сумма затрат была в рамках лимита. Все устаревшие позиции на этапе корректировки должны быть заменены на аналоги или вообще удалены из заявки.
Потребности после корректировки снова попадают к специалистам по номенклатуре для утверждения — по сути, это итерация второго этапа, только после уточнения номенклатуры материалов и количества позиций.
Выбор поставщика и уточненная расценка. На этапе выбора поставщика происходит уточненная расценка материалов, исходя из понятных объемов поставки и предметных переговоров с поставщиками. На некоторых предприятиях этот этап проводится уже за рамками заявочной кампании, при контрактации.
После детальной расценки заявленных материалов происходит окончательная корректировка заявок-потребностей с обязательным утверждением у специалистов по номенклатуре.
Расчет плана закупок. На финальном этапе заявочной кампании происходит расчет плана закупок. Алгоритм расчета в целом аналогичен стандартному расчету, заложенному в MRP. Далее рассчитанный план закупок передается исполнителям службы снабжения.
Из описания видно, что расценка приводит в итоге к корректировке потребностей. То есть получается, что некая позиция нужна, исходя не из объективной необходимости, а в зависимости от ее цены. Именно это и противоречит концепции MRP/MRPII, заложенной в современных системах управления ресурсами.
Для большинства российских компаний принципы MRP обычно удается в чистом виде применить только в отношении нормируемых материалов для основного производства. А закупку всего остального приходится либо организовывать вручную, либо придумывать другие способы автоматизации.
Подходы к автоматизации заявочных кампаний
По большому счету, подходов всего четыре:
> Отказ от заявочных кампаний в пользу стандартной функциональности MRP-системы.
> Модификация стандартной функциональности MRP-системы.
> Создание новой функциональности с помощью встроенных средств разработки MRP-системы.
> Разработка специализированного внешнего ПО и интеграция его с MRP-системой.
Первый вариант пока является скорее гипотетическим. Примеры практической реализации полной смены методики планирования встречаются крайне редко. Как правило, такой подход удается реализовать для нормируемых материалов, требующихся в основном производстве, поскольку их закупка не зависит от цены, или небольшой группы материалов (химикаты, лампочки, ручки, бумага), потребление которых рассчитывается статистически.
Модификация стандартной функциональности — весьма популярный подход. Наиболее удачные примеры его реализации основаны на использовании функциональности стандартных заявок на выдачу ТМЦ со склада, к которой добавлены собственные таблицы цен и условий.
Основным преимуществом такого подхода является возможность применения стандартной функциональности для расчета плана закупок. Также важным плюсом является сравнительно небольшой объем собственных разработок.
Основным недостатком этого подхода можно считать то, что интерфейс стандартных заявок обычно плохо приспособлен для работы с большим количеством номенклатурных номеров в режиме правок, поскольку в нем слабо развиты средства навигации, поиска, массовых замен. Поэтому для удобства работы приходится разрабатывать еще и свои пользовательские интерфейсы. К тому же стандартные заявки-потребности на выдачу ТМЦ предназначены в системе для точного планирования получения ТМЦ со склада (до конкретной даты и времени), а в заявочной кампании они используются для экспертного предположения о получении ТМЦ, причем с точностью до месяца.
Когда же возникает необходимость автоматизировать непосредственную выдачу со склада поступивших ТМЦ, объект, предназначенный для этого в системе, уже оказывается использованным для других целей. Приходится опять программировать, например, добавлять специальные признаки для отделения заявок, используемых в заявочной кампании, и так далее.
Варианты автоматизации заявочной кампании, связанные с разработкой, по сути, идентичны и отличаются в основном инструментарием и средой программирования. Ниже мы подробно рассмотрим один из таких вариантов на примере реализации собственной функциональности в системе SAP/R3.
Реализация собственной функциональности в системе SAP R/3
Ключевым преимуществом такого подхода является возможность проектирования системы практически без ограничений, которые в той или иной степени характерны для стандартных интерфейсов. При этом трудоемкость таких работ относительно невелика: 3–4 квалифицированных разработчика при наличии качественной проектной документации справляются с работой за 2–3 месяца, включая тестирование и сдачу-приемку. Разработка новой функциональности позволяет учесть большинство требований пользователей в части интерфейсов и сервисных функций, облегчающих работу с системой.
Основным минусом такого подхода (мы упомянули о нем еще в самом начале) является необходимость сопровождения собственных разработок. Кстати, при грамотной реализации новой функциональности риск появления несовместимостей при переходе системы на новую версию будет даже меньше, чем в случае, когда дорабатывалась стандартная функциональность. Ведь собственная функциональность существует сама по себе и интегрирована в «стандарт» всего в нескольких местах. Поэтому даже при существенных изменениях стандартной функциональности в новой версии адаптировать собственные разработки придется только в связующих «мостиках» — местах интеграции.
На рисунке приведена принципиальная схема решения для заявочной кампании в системе SAP R/3. Функционально оно состоит из нескольких связанных подсистем и использует стандартные справочники основных записей материалов (ОЗМ), мест возникновения затрат (МВЗ), статей структурного плана проектов (СПП-элементов) и прочих объектов затрат.
Подсистема «Потребности» предназначена для сбора первичных заявок-потребностей на получение ТМЦ от структурных подразделений компании, анализа и утверждения этих потребностей специалистами по номенклатуре и проверки на соответствие лимитам списания ТМЦ. Подсистема поддерживает раздельное планирование по видам потребностей и объектам назначения (проектам, объектам затрат).
Подсистема «Лимиты» служит для реализации лимитной политики списания ТМЦ по структурным подразделениям и объектам затрат. Ее пользователями являются сотрудники планово-экономической службы. Интерфейс подсистемы реализован в соответствии с принципом «экранный интерфейс = контрольная форма». Это означает, что интерфейс ввода соответствует форме печатного отчета, по которому служба контролирует эти лимиты.
Подсистема «Расценка» предназначена для ведения плановых цен списания материалов в производство и позволяет на основе «базовых» (ориентировочных) цен и ряда коэффициентов (дефляторы, плановые коэффициенты транспортно-заготовительных расходов и другие), используемых службой МТО, рассчитывать плановые цены списания для каждого периода планирования.
Подсистема «Расчет плана закупок» позволяет рассчитывать план закупок на основе потребностей, прогнозных остатков и складских запасов материалов с учетом стандартных календарей планирования и информации из ракурсов основной записи материала. Подсистема напоминает стандартную функциональность планирования потребностей в материалах, но позволяет более гибко учитывать в расчетах различные особенности доставки и комплектации (например, графики навигации для северного завоза, разнесение по разным периодам поставки опасных веществ, которые нельзя перевозить совместно, и прочее).
Подсистема «Настройка» позволяет гибко настраивать функциональность, в том числе задавать формулы расчета плана закупок, методы распределения по периодам расчетного количества номенклатуры, ценовые коэффициенты и порядок их использования, настройку периодов, этапы работы с потребностью и так далее.
Важно, что стандартный MRP-расчет потребности в материалах (например для основного производства) может работать одновременно с дополнительной функциональностью. Для каждого материала в основной записи указывается способ планирования (стандартный или собственный). Это позволяет переходить на стандартный MRP-расчет постепенно, группами или даже отдельными материалами.
Отдельно необходимо отметить важную специфическую проблему, связанную с лицензионной политикой производителей MRP-систем. При полной автоматизации заявочной кампаний для крупного предприятия количество конечных заявителей достигает нескольких тысяч. Если для каждого пользователя покупать лицензию, это выливается в серьезные финансовые затраты. Так как вендоры официально не признают проблематики заявочных кампаний, то пока они не готовы рассматривать льготные условия лицензирования.
Для преодоления этого ограничения приходится придумывать обходные пути. Например, на рисунке в подсистеме «Потребности» желтым цветом выделен веб-интерфейс «тонкий клиент». Это отдельная система, реализованная в среде ASP .NET. Система выполняет две важные функции. Первая функция — предоставление пользователям для работы веб-интерфейса, что уменьшает требования к пользовательским местам и избавляет от необходимости установки клиентских приложений на сотни компьютеров. Вторая функция — обеспечение работы в MRP-системе через стандартные интерфейсы удаленного вызова под видом нескольких технических пользователей, обрабатывая при этом запросы от сотен фактических пользователей.
Конечно, несколько сложно для технической реализации, зато полностью законно с точки зрения лицензионной политики, удобно для пользователей и экономично для заказчика.
Заявочные кампании
Системы класса ERP сегодня весьма популярны во всем мире. Это объясняется комплексным подходом к решению управленческих задач, богатой функциональностью, стандартной реализацией современных эффективных моделей бизнес-процессов и возможностью гибкой настройки.
Тем не менее, при всей функциональной полноте ERP-систем в базовых моделях отсутствует специфический для России бизнес-процесс планирования потребностей в материалах, так называемые «заявочные кампании».
Заявочные кампании появились в СССР в условиях плановой экономики. Предприятия заявляли потребности в материалах и оборудовании, как минимум, на год вперед, а стратегически важные и удаленные предприятия — даже на два года. Все потребности рассчитывались и утверждались в рамках различных финансовых фондов и лимитов. Финансовый план и план закупок защищался в соответствующих ведомствах.
При переходе к рыночной экономике руководству большинства промышленных гигантов было не до новаторских решений в области снабжения. Да и исполнители, работавшие на предприятиях, привыкли к принятым методикам, поэтому заявочные кампании долгое время оставались практически неизменными. Появление новых руководителей и молодых специалистов МТО постепенно двигает процесс снабжения в сторону мировой практики, но до сих пор для многих промышленных предприятий и холдингов заявочная кампания остается по сути неизменным и привычным процессом.
Целью заявочной кампании является формирование на основе потребностей предприятия соответствующего плана закупок, сбалансированного по номенклатуре, финансовым средствам и периодам поставки.
Суть процесса состоит в том, что данные о потребностях в ТМЦ (товарно-материальных ценностях), выраженные в форме заявок структурных подразделений — потребителей, обрабатываются несколько раз в год в ходе официальной централизованной процедуры. При этом важным критерием оценки потребностей является цена, то есть характеристика, логически возникающая в процессе материально-технического обеспечения на более позднем этапе — при контрактации. Такое противоречие не укладывается в алгоритмы MRP/MRPII, которые основаны только на количественных, а не суммовых (ценовых) критериях.
Дополнительные условия успешной автоматизации заявочной кампании
Самая замечательная с функциональной точки зрения система может оказаться бесполезной при несоблюдении трех важных условий:
- Наличие единого номенклатурного справочника для всех участников процесса.
Приведем для примера наиболее часто встречающиеся нарушения этого условия:
- использование отдельных справочников в каждом подразделении;
- ведение единого справочника, но с большим количеством дубликатов. В этом случае каждое подразделение один и тот же материал заявляет под разными номенклатурными номерами;
- рассылка справочника в качестве сервисной информации в виде электронных таблиц или текстового файла. В этом случае возникает много ошибок (случайных и специальных) из-за влияния человеческого фактора, выверка и исправление которых обычно ложится на службу МТО.
- Четкое разграничение задач и полномочий участников процесса.
Типичные ошибки:
- попытка переложить ответственность за какой-либо процесс с человека на компьютер. На практике это приводит либо к вовлечению ИТ-специалистов в бизнес-процесс, либо к бесконтрольному течению процесса;
- наличие больше одного ответственного за процесс. В этом случае каждый, кто считает процесс «своим», пытается изменить его «под себя». ИТ-специалистам при этом приходится согласовывать каждое изменение со всеми пользователями процесса;
- попытка пользователей чрезмерно контролировать ход процесса, что в итоге оборачивается отсутствием контроля как такового. Например, пользователь требует обеспечить полный контроль за каждой позицией, включаемой в расчет сводной потребности. Получив такие полномочия, он скоро осознает огромный объем работы и перекладывает ее на другого сотрудника, который, не отвечая за процесс, выполняет ее механически, сводя на нет изначальную идею контроля.
- Наличие централизованного управления процессом.
Как правило, ответственными за проведение заявочных кампаний назначаются сотрудники службы МТО. При этом реальными полномочиями по управлению процессом их обычно наделить забывают. Забавно и при этом грустно наблюдать, как сотрудники МТО многократно напоминают, что сроки заявочной кампании срываются, и упрашивают коллег из подразделений-заявителей откорректировать потребность.
При всей очевидности этих условий их несоблюдение часто затрудняет успешную автоматизацию заявочных кампаний.
Напоследок хочется заметить, что автоматизированный процесс заявочной кампании постепенно приближает пользователей к пониманию «правильной» организации процесса. Поработав два-три года, пользователи начинают оптимизировать методику своей работы. Причем предложения по оптимизации напоминают попытки изобрести велосипед и доработать процедуру до стандартной, уже существующей в системе MRP-функциональности.
Напрашивается вывод, что истинной целью автоматизации заявочной кампании является обеспечение контролируемого заявочно-закупочного документооборота при постепенном переходе на стандартные MRP-алгоритмы. Думается, что когда-нибудь на российских предприятиях привычные заявочные кампании станут анахронизмом. И однажды, в не очень далеком будущем, какой-нибудь матерый седой консультант по логистике попробует вспомнить и объяснить молодому коллеге, почему же раньше в России нельзя было решать вопросы снабжения с помощью давно известных простых и логичных методов.
ERP, MRP, MRPII…
С точки зрения автоматизации заявочных кампаний системы управления ERP/MRP/MRPII идентичны. В данной статье все они объединены термином «MRP-система».
Под MRP-системой (MRP — Material Requirements Planning) понимается автоматизированная система управления, в которой реализовано планирование и обеспечение предприятия материальными ресурсами методом MRP. Сам метод вместе с названием появился около 40 лет назад в связи с развитием использования вычислительной техники для нужд бизнеса.
Несмотря на устоявшееся выражение «в соответствии со стандартом MRP», это все-таки не стандарт, а просто один из методов расчета потребностей в заготовке материалов, суть которого заключается том, что расчет заготовки материальных ресурсов производится на основе объемов и сроков производственных потребностей и прогноза складских запасов.
А вот MRPII (Manufacturing Resource Planning) является стандартом, который поддерживается Американским обществом по управлению производством и запасами — American Production and Inventory Control Society (APICS). С точки зрения методики, кроме потребностей и запасов, метод MRPII учитывает в расчетах ограничения мощностей производства, в отличие от метода MRP, который предполагает, что производственные мощности не ограничены.
Термин «ERP» (Enterprise Resource Planning) был введен в оборот более 10 лет назад компанией Gartner Group для определения системы MRPII, интегрированной с системой финансового планирования (FRP). К настоящему времени определение фактически устарело.
Под термином ERP теперь понимают систему, в которой, как минимум, реализована связка управления финансовыми (financial), материальными (material), производственными (manufacturing) и трудовыми (human), то есть основными ресурсами предприятия. Максимальная «комплектация» включает все известные системы управления различными ресурсами и аспектами деятельности (вплоть до ведения конструкторских разработок) — по желанию и возможностям производителя. Из-за отсутствия четкого определения периодически возникают споры, можно ли причислить ту или иную систему к классу ERP.
Время от времени появляются попытки введения новых терминов для описания различной «комплектации ERP» (например, ERM, EWRP). В иностранной литературе эти термины встречаются, но в России практически не прижились.
В современных системах ERP/MRP/MRPII отсутствует стандартное решение для автоматизации значительного по длительности и вовлечению людских ресурсов процесса заявочных кампаний и итеративных расценок товарно-материальных ценностей.
http://www.cio-world.ru
