Недовнедренная ERP в производстве: в реанимацию или в морг? (1я часть)

image

Как превратить условно-работающую ERP в реальный инструмент управления производством и поставками?
1 часть (здесь): проблемы использования для планирования внедренных "учетных" ERP
2 часть (по ссылке): 2я жизнь — постановка Планирования и Мониторинга производства и поставок с внешним планировщиком. Концепция и реализация.


Питеркин Сергей, Меркулов Михаил, «Райтстеп»


За последние годы, количество производственных предприятий, заявляющих о внедренных ERPсистемах, значительно возросло. И составляет уже не десятки, а сотни. Говорим мы прежде всего о дискретном производстве, а под «производственной ERP» подразумеваем любую систему, претендующую на это гордое название. По частоте наших «столкновений», наиболее распространенными «работающими в производстве» ERP являются — BaaN/InforLN, InforERPSyteLine, постоянно-растущая «армия» заводов с 1С, и в небольшом количестве SAPERP и прочая экзотика.


Данная статься будет интересна прежде всего «продвинутым» пользователям ERP, в большей степени с позаказным типом производства («вытягивание» под заказ или на склад, в т.ч. и «вытягивание» под прогноз спроса), тем, кто автоматизировал (возможно – «как есть») процессы учета хода производства, т.е. формирования производственных заданий (далее по тексту – ПЗ. В разных системах: SFC-заказы, Job-Orders, JOBs, Заказы на Производство, Производственные заказы и т.п.) и их отслеживания, но так и не смог уверенно производство (и поставки – МТО (Материально-Техническое Обеспечение)) планировать, как и не смог поставить мониторинг производства, в т.ч. и позаказный. С непрекращающимися попытками все-же запустить планирование, и/или с попытками обеспечить планирование с использованием волшебных алгоритмов и/или систем типа APS, MES.


В силу ограниченности объема статьи мы не будет останавливаться на разборе того, почему «традиционные» ERP плохо внедряются и/или работают И для планирования И для управления производством, а также на разборе того, почему «магия» APS или MESсистем превращается на большинстве наших заводов в шарлатанство. Цель статьи – показать, как определенной категории предприятий, которые узнают себя в написанном ниже, построить замкнутую систему планирования/мониторинга не на обломках, но с использованием того, что есть сейчас.


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


Постановка задачи для типичного позаказного производственного бизнеса


Типичные жалобы, следствия и причины


  1. «Счетные» бизнес-проблемы предприятия.
    • Неуправляемые срывы сроков выполнения заказов, в особенности, в условиях частных изменений заказов (прием новых, изменение существующих) --> потеря оборота.
    • Увеличенные (высокие, относительно прибыли) трудозатраты на администрирование производства, авральные работы --> увеличенные издержки.
    • Неоптимальный (высокий, относительно оборота) объем НзП (Незавершенное производство)
      увеличенные издержки, увеличенные циклы, потеря пропускной способности (недостаточная пропускная способность) производства.
  2. Являются следствием….
    • Невозможности надежного «прогнозирования» (должно быть — расчета плановых/расчетных дат) сроков выполнения заказов клиентов.
    • Отсутствия информации о существующих и будущих (по всему циклу производства) проблемах в выполнении заказа.
    • Неоптимальной загрузки узких мест (обрабатывают не то, не в то время, не в той последовательности).
  3. Являются следствиями следующих (некорневых!) причин.
    • Отсутствие формализованной системы быстрого <позаказного> планирования:
      1) с учетом загрузки узких мест (очередь обработки составляющих заказа);
      2) с учетом приоритетов заказов.
    • Отсутствие прослеживаемости и визуализации состояния заказа(ов) по всей производственной цепочке.

Цель


  1. Надежное определение сроков выполнения заказа – для разовых и срочных заказов. С учетом циклов производства/закупки (по критическим «веткам» состава изделиязаказа) и с учетомсвободных запасов (материалов, ПКИ (покупных комплектующих изделий), НзП) и ожидаемых приходов по ЗП (заказы поставщикам) и ПЗ.
  2. Минимизация средневзвешенных срывов сроков для «долгосрочных заказов»:
    1. через общую балансировку выпуска,
    2. через приоретизированный план производства и исполнение,
    3. через контроль исполнения плана с визуализацией отклонений от сроков.
  3. Максимально-эффективная загрузка узких мест.

Типичная модель планирования типичного завода с недовнедренной «производственной ERP»


Общее описание


  1. В настоящее время для управления производством и поставками используется «производственная ERP».
  2. Управление МТО, Учет хода производства, Управление запасами, в т.ч. производственными – очень часто сделаны на хорошем уровне.
  3. При этом, Планирование реализовано частично, с использованием не предназначенных для этого функций системы и/или — самостоятельных разработок.
    • Планирование выпуска («Верхний» уровень планирования – формирование Основного Производственного Плана). Никак не реализовано, или реализовано в MS-Excel. Без привязки к модели и параметрам реального производства. Без учета существующего состояния производства:
      1) выполняемых или запланированных к запуску ПЗ/ЗП,
      2) запасов ПКИ, материалов и НзП, в разных статусах «закрепления» (распределения) за заказами клиентов,
      3) свободных/ожидаемых запасов готовых изделий, выпускаемых «на склад» (под прогноз спроса или точку перезаказа),
      4) с учетом ресурсной модели (ресурс = специальность), но без необходимой детализации.
    • Планирование производства (Уровень планирования — Синхронизированное Планирование Производства и Поставок).

      1) Планирование производства реализовано через создание производственных заданий (объектов управления исполнением!) по всей структуре изделия заказа и расчета дат запуска-выпуска методом простейшего сетевого планирования (конец работ — цикл производства = начало. = конец входящего компонента — …). Такой подход не обеспечивает необходимой для достижения указанных выше целей информации и имеет массу недостатков (см.ниже), в силу чего для реального планирования и управления производством практически не используется. Производство управляется «вручную», ПЗ используются только для учета!

      2) Поставки (МТО) планируются под сформированные ПЗ. Точность такого плана = точности планирования ПЗ, т.е. – достаточно низкая. Но т.к. «позаказные составы изделия» (или — «цепочка ПЗ») заведомо растянуты и не учитывают существующих запасов, МТО почти всегда удается не допускать дефицитов производства. В отсутствии системы планирования, которая постоянно учитывает внутренние (производство, МТО, запасы) и внешние (заказы, прогнозы) изменения, это достигается, очевидно, завышенными запасами материалов и ПКИ.

Детальный разбор используемой модели планирования


Модель планирования


image


  1. Объекты управления исполнением (Производственные задания ПЗ) используются не по назначению — не для управления исполнением, но для созданияПроизводственного (позаказного) Состава Изделия (ПСИ), а также — для позаказного планирования (попытки планирования). При отсутствии в ИТ-системе функций <сквозного> позаказного планирования и позаказного состава это становится единственным вариантом, позволяющим <хоть как-то> управлять всей цепочкой выполнения заказа клиента (ЗК). Такой подход имеет следующие принципиальные недостатки.
    • ПСИ, созданный с использованием объектов исполнения — фиксированный. Изменения, возникающие, например, в КСИ/ТСИ (Конструкторский/Технологический составы) из-за конструкторско-технологических изменений, могут учитываться только вручную. На практике, при большом объеме объектов управления это означает: <никак>. Как результат — ошибки в планах, решаемые только через трудоемкое и неэффективное ручное управление.
    • ПЗ, по определению, плохо обрабатываются планировщиками 2го уровня производственного планирования (планировщики-синхронизаторы, APSPlanner'ы и даже MRP, в т.ч. <позаказные> — см. ниже). В т.ч. потому, что для планировщика ПЗ — это фиксированные ожидаемые приходы, а не рассчитываемые планировщиком гибкие <элементы> ПСИ(плановые заказы, pln).
    • При планировании ПСИ, смоделированного на основании ПЗ, не учитываются запасы и ожидаемые приходы ДСЕ, которые могут быть использованы для выполнения данного заказа, в соответствии с правилами распределения/разметки запасов/ожидаемых приходов.
  2. Планирование выполняется через алгоритм собственной разработки, в одну итерацию, с разузлованием состава, определением потребных количеств брутто (!) и смещением влево дат начала ПЗ. При этом используется имеющийся ограниченный набор времен пооперационной модели (пооперационный маршрут), для операций которой (модели), как правило, не определены необходимые для планирования времена, типа <время до>, <время после>, <буфер до>, <буфер после>, <время очереди>, <время перемещения> и т.п. Это приводит к большим и трудно управляемым погрешностям рассчитываемых сроков.
  3. Под спланированные ПЗ через стандартный алгоритм планирования рассчитываются потребности в закупаемых материалах и ПКИ, формируются объекты управления — ожидаемые приходы, ЗП.

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


Критическая проблема №1


image


image


В случае наличия запаса в производстве или ожидаемого прихода ДСЕ, которые могут быть использованы для выполнения заказа (что вполне может случится из-за изменений в ПСИ другого заказа, изменений приоритетов/дат заказов и многих других причин), — потребности производства и закупок принципиально меняются — см. пример на рисунках выше. Прежний <жестко-позаказно-идеальный> план может быть изменен только вручную (реально, для сотен и тысяч объектов управления — ПЗ, это крайне затруднительно и не выполняется). Это приводит к перезакупке материалов и ПКИ, а в итоге — к <замораживанию> оборотки, потенциальным неликвидам, и перепроизводству. Если с перезакупкой плохо, но как-то еще можно жить (если нет проблем с обороткой:) — т.к. <пойдет на другие заказы:>, то производство <ненужных> <сейчас> ДСЕ, особенно в узких местах, отнимает драгоценные <рубле-часы> всего оборота завода. Как результат — уменьшение оборота, прибыли (в т.ч. за счет доп.расходов на авралы), срывы сроков заказов. Как итог — потеря/неувеличение доли рынка.


Еще одна проблема использования такого простейшего планирования — фактическое отсутствие реакции на происходящее в производстве/закупках. Неправильное определение или даже потеря приоритетов ЗК в <черном ящике> производства. Даже и прежде всего при определении очередности обработки заказов (частей <изделия>заказа) в УМ (узких местах).


Критическая проблема №2


  1. Допустим, первоначальное планирование (это маловероятно с использованием только 2го уровня планирования, но теоретически возможно) обеспечивает квази-оптимальную (близкую к оптимальной) загрузку узкого места.

image


  1. Однако, отсутствие быстрого и частого перепланирования по всей цепочке выполнения заказа (ресинхронизация) не позволяет учесть такие типичные для реального производства ситуации, как: неустранимый срыв сроков производства/закупки каких-либо комплектующих, изменение приоритетов/дат заказов или их остановка, изменение ТСИ и т.п.
  2. Как показано в примере ниже, неустранимый срыв сроков заказа ХХ ведет к переносу сроков его готовности и отгрузки. При этом, при отсутствии системы ресинхронизации, узкое место потеряет время на обработку ДСЕ этого заказа, которые могли бы и должны быть обработаны позже. При наличии новых или срочных заказов, или заказов с устранимыми срывами срока, УМ не сможет обрабатывать их детали, т.к., скорее всего, никто не покажет данному участку правильную последовательность/приоритеты обработки! Как результат — меньший, чем мог бы быть выпуск (готовых изделий), потеря оборота и прибыли.

image


Критическая проблема №3


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


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

image


  1. Планирование с консолидацией выпускаемых ДСЕ либо по заказу, либо по плану производства. Консолидация по приведенным ниже 2м вариантам планирования приводит к уменьшению пропускной способности производства (выпуску меньшего количества заказов за период).

image


image


image


Основная (корневая)проблема и точка улучшения


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


  1. Согласно <Системной динамике> в приложении к сложным производственно-логистическим системам, все они (системы) испытывают постоянные колебания уровня запасов, и потребных/используемых мощностей, обусловленные прежде всего скоростью реакции. См.: Industrial Dynamics, Jay Forrester, Productivity Press, 1961; Factory Physics: Foundations of Manufacturing Management и производные этих работ. Частота и амплитуда колебаний прямо пропорциональны фундаментальной переменной системы — скорости реакции <на внешние и внутренние изменения>, или — времени отклика.
  2. Сокращение времени отклика (увеличение скорости реакции) увеличивает частоту колебаний запасов/мощности, но снижает их амплитуду. Амплитуда колебаний запасов (общеизвестная графическая иллюстрация колебаний — пилообразная кривая изменения уровня запасов при партионной закупке/партионной обработке) однозначно определяет объем запасов (за период), в т.ч. объем НзП в системе. При этом, согласно закону Литтла (LittleLow) <Теории очередей>, сокращение уровня запасов приводит к сокращению очередей<ПЗ в ожидании обработки>, т.е. — к сокращению циклов выполнения заказов! Подробнее: <Скорость реакции промышленного предприятия>, Питеркин С.В., интернет.
  3. Говоря <русским языком>: чаще планируем, исполняем меньшими (позаказными) партиями — больше можем выполнить заказов в единицу времени.Соотношение, которое приводилJayForrester — <сокращение времени отклика в 2 раза приводит к снижению уровня запасов по всей цепочке в 1,7 раз>. Говоря <русским языком>:
    • просто начинаем (пере) планировать всепроизводственно-логистическую цепочку чаще в 2 раза (вместо <раз в месяц> — <раз в 2 недели>) — увеличиваем выпуск <примерно>в 1,7 раз,
    • просто запускаем минимальные партии ДСЕ в производство — увеличиваем выпуск <примерно>в 1,7 раз,

    • Цифра в 1,7 — расчетная и теоретическая. Значение на практике, естественно, зависит от типа производства-закупок, типа спроса и т.п. Но как минимум, на первые десятки %% улучшения выпуска — рассчитывать можно: Просто изменяя подходы к управлению:
      Однако, глядя правде в глаза, просто изменить подходы к управлению (чаще перепланировать, чаще запускать небольшие партии), в сложном производстве, без адекватной системы планирования — невозможно.

Выводы


  1. Приведенные выше случаи — лишь небольшая часть примеров, которые наглядно показывают практическую неработоспособности представленной модели планирования. Описание всех возможных примеров и проблем при ее использовании — выходит за рамки настоящего документа. В дополнение лишь отмечу, что помимо адекватного планирования, такая система не обеспечивает и сколь-нибудь внятного мониторинга происходящего, в т.ч. позаказного мониторинга. Т.е. не дает лицам, принимающим решения, никакого инструмента по повышению продуктивности ручного управления
  2. Еще одно, крайне важное замечание! Как видно из описанныхвыше проблем, отсутствие алгоритмов <точного>, <детального>, <оптимизационного>, <планирования до станка/человека>, <планирования с учетом мощностей, , — не являются ключевыми причинами низкой эффективности большинства производственно-логистических систем. А их наличие — совсем не <золотой ключик> к ее повышению.
    Если у вас еще остались сомнения, по адекватности существующей системы планирования и/или по возможности приведения ее <в чувство> не меняя принципиальных подходов, ответьте на вопрос:<сможет ли существующая <управленческая> Система и поддерживающая ее информационная, обеспечить хотя бы недельное время отклика?>.

    Описание предлагаемых решений — в следующей части документа.

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 15

    0

    По моему мнению, проблемы с внедрением ERP лежат не только в плоскости организации планирования или методик/алгоритмов планирования. Наиболее существенные проблемы таки
    1) брак при производстве, транспортировке, хранении деталей. Процент брака чудовищный что нередко пытаются скрыть от учёта. О том какую реальную партию запустить в производство чтобы на выходе получить N готовых деталей может более-менее обоснованно сказать опытный начальник цеха/участка
    2) ввиду сложности конструкции изделия и ещё более сложной технологической спецификации изделия, в составе изделий неизбежны ошибки. При этом некоторые ошибки могу попасть в конструкторскую и технологическую документацию, а некоторые появиться при переносе данных в компьютер. То что любая информация имеет некоторую вероятность содержать ошибку это пол беды. Специфика информации о составе изделия имеет своего рода мультипликатор, т.к ошибка, допущенная в плоских данных влечет за собой искажение ровно в одной позиции. В иерархической структуре ошибка в одной позиции влечет искажение для всех входящих в эту позицию деталей и сборочных единиц
    3) трудовые нормативы — как правило не соответствуют реальным затратам времени. Причин может быть несколько. Элементарная ошибка в нормировании, индивидуальная производительность рабочего, фактическое состоянии детали по результату предыдущих операции в пределах допусков (может например увеличится припуск на максимум допуска или же деталь быть закалена на максимум допуска или на минимум допуска. Наличие "платежных" норм.
    4) отсутствие достаточного количества персонала для выполнении учётных операций на самом низовом уровне (рядом с рабочим и деталью).


    По поводу последнего хочется сказать отдельно. Существует заблуждение о том что компьютеризация сильно упрощает и облегчает работу на самом низовом уровне. По моим наблюдениям кладовщики, мастера, распреды решают свои задачи достаточно эффективно используя испытанные временем средства. Иногда это отходит от стандартов предприятия если стандарт разрабатывал далёкий от темы белый воротничок что бывает очень часто. Способности человека справляться с большими объемами информации зачастую недооценивается. А эффект от того что мы предоставим информацию в компьютерном виде переоценивается. Я говорю подчеркну о самом низовом уровне. Также редко кто проводит детальные расчеты. Сколько деталь-опкраций проходит за смену через одного кладовщика, какая интенсивность поступления в зависимости от времени суток. Сколько времени уходит на ввод одной позиции в компьютер. Сколько дополнительно кладовщиков потребуется для ведения компьютерного учёта. Дополнительных? Вы не ошиблись? Мы же ERP купили и вместо сокращения нужно увеличивать штат вспомогательных рабочих ?


    По этому поводу есть интересная притча рассказанная преподавателем эргономики в Политехе в 70-е годы. Не знаю правда или нет. Во всяком случае подобные исследования проводились. Для эксперимента у колхозного пастуха из стада в тысячу голов забрали одну корову. И спросили все ли коровы на месте. Пастух час пересчитал стадо и выявил, что одной коровы не хватает. Оленеводу дали аналогичное задание. Оленевод посмотрел на стадо и сразу ответил, что Быстрой не хватает, однако. Так и с теми же кладовщиками, когда они знают детали что называется влицо, им компьютер только дополнительная работа. Ну а если не знают то никакой компьютер не поможет.

      0
      когда они знают детали что называется влицо
      но тогда же кладовщика не заменишь быстро на другой «винтик».
        0

        В цехе предприятий которые могут позволить приобретение ERP обычно несколько кладовщиков, так же есть несколько ИТР должностей например начальник ПДБ, инженер по комплектации, диспетчер, которые в теме. Я еще раз подчеркну что нет дилеммы либо умный кладовщик либо винтик с компьютером. Умный кладовщик нужен в любом случае. просто с компьютером у него прибавляется (заметно) в работе.

          0
          у вас такой дилеммы нет. в голове менеджмента на конкретном предприятии вполне себе может быть.
            0
            Повторюсь: если «с компьютером у него <кладовщика>прибавляется (заметно) в работе»… выкиньте систему, которая стоит на компьютере (а заодно и компьютер) на помойку.
            Что «получить»или «отпустить» — кладовщику «говорят» через системы менеджер по закупкам МТС или диспетчер/плановик/мастер/распред производства. И это задание он может получить как распечатку или сразу задание на планшет/смартфон. Кладовщику (в случае «отпустить») остается только собрать это физически и щелкнуть сканером по ШК ТМЦ. И это гораздо быстрее, чем записать это на клочке бумаги, а потом продублировать это в своей тетрадочке и еще и картотеке…
            0
            продолжение статьи тут
            habr.com/ru/post/470429
            0
            Добрый день!
            Спасибо за комментарий. По существу.
            1. В статье НЕ рассказывается о проблемах внедрения ERP — но, о проблемах использования НЕдовнедренной/неправильно внедренной ERP. Т.е. «внедрили», а что и как — непонятно :))
            По комментариям.
            1) Брак не есть проблема внедрения и даже использования ERP (или, скажем ближе к смыслу — системы планирования, управления производства (или, что правильнее. ИМХО — СПМ — Система Планирования и Мониторинга производства). % брака вводится экспертно вначале (цифры всегда есть!), далее — довольно быстро собирается по статистике (если планирование/учет внедрены корректно!). Далее — «зажимаются гайки» в процессах комплектации и списания в производство с регистрацией готовой и брака, (через ИТ систему), с одновременной отменой наказания за брак (!, только если не сообщил!) И все устаканивается! ЕСЛИ руководство на это идет…
            2) по входимости и количеству (не считая обычно завышенных норм материалов) ошибки редки, т.к. в реальном производстве оч.быстро выявляются, не важно, ИТ-системы есть или нет,
            3) трудовое нормирование. Норм с ошибками — давно не видел. Они — просто кривые! потому, что:
            а) зарплатные,
            б) институт нормирования давно утерян, никто не знает, как и зачем (за 10 последних лет видел пару заводов, где все-же нормируют)
            в) даже если как-то и пытаются, нормируют технологи и/или нормировщики ОТиЗ. И они понятия не имеют (не обучали, никто не сказал, зачем?...) что нормировать надо не только собственно операции, но и кучу временных параметров, определяемых моделью производства/планирования,
            4) если процессы нормально спроектированы (Lean) система внедрена правильно — НЕ ДОЛЖНО быть лишнего персонала (тем более — специального), для выполнения УЧЕТНЫХ операций. Т.е. операций, необходимых для адекватного отображения в ИТ-системе реальной жизни. И процессы и ИТ-средства сейчас достаточно продвинуты, даде на уровне рабочего и мастера, не говоря уж о кладовщиках… Сравните: трудозатраты на продажи и учет в магазине типа «гастроном» Vs. трудозатраты на продажи и учет в «супермаркете». И время, которое вы тратите, как покупатель.
            Да, иногда трудочасов (в сумме) на ввод информации действительно требуется больше. Но только в случае, если на заводе не адекватный учет. Но даже в этом случае, будет принципиальное сокращение трудозатрат на «администрирование» производства и закупок. Т.е. сокращение (и значительное) трудозатрат ПДО, ПДБ и пр.

            Питеркин Сергей
              0
              продолжение статьи тут
              habr.com/ru/post/470429
              +2
              И?
              Где ответ на вопрос в названии статьи?

              Так то интересно почитать, но заголовок иправьте.
              0
              Спасибо за статью! С первых же строк узнал свой родной завод.
              У нас тоже ЗНП используются не для отслеживания хода производства, а как инструмент учёта.
              В связи с этим вопрос.
              Если бы ЗНП использовались по прямому их назначению — как инструмент исполнения производства, то как тогда относить затраты на готовую продукцию?

              поясню на примере.
              Нужно изготовить партию втулок объёмом 100шт, которые впоследствии будут использованы при сборке нескольких видов готовой продукции (ГП).
              Создаём одно ЗНП на изготовление 100 втулок, выполняем его, списываем материалы на это ЗНП. Бухгалтера у нас не ведут учёт полуфабрикатов по 21-му счёту, а материалы списывают на конкретный вид ГП.
              Вопрос как в таком случае списывать материалы, если у нас одно ЗНП?
                0
                Ответ.
                1. ЗНП, тем более в классической западной ERP — это инструмент исполнения и сбора затрат — прямых производственных. И, да, все это может падать на субсчета 20ки — но нашим бухгалтерам об этом лучше не говорить — крыша поедет. Т.к. это не их «честная, точная ПОСМЕРТНАЯ с\с»
                2. Возвращаюсь к вопросу… Если нет жесткой связки субЗНП-субЗНП-ЗНП (на готовую), то единственный вариант сбора (для РСБУ) — это вычислить по транзакциям (matl tran и jobtran) списания на ЗНП, прихода по ЗНП, списания (в след.ЗНП) прихода на СГД (например) и списания на ЗНП на готовую. И — сделать партионный учет на складах…
                Т.е. тупо вычислять, на какую партию (ЗНП) что списано, что и в какую партию оприходовали (здесь- вычисляем с/с 1шт. в партии если надо...), далее — каком кол-ве из этой партии (и по какой цене) пошло на след.партию (ЗНП) и так далее, до списания на ГП.
                Т.е. делаете «трассировку партии» и по ней вычисляете, сколько и чего «упало» на ГП.
                3. Если не заморачиваетесь РСБУ а по-честному хотите видеть прямую производственную с/с, и на п/фи на ГП — используйте стандартный механизм (западной ERP). Либо actual cost либо standart costing (фактическая или нормативная).
                0
                Мне кажется что вариант №2 когда нужно вычислить по транзакциям (matl tran и jobtran) для нас будет большим источником ошибок.
                Интересно, а как на других заводах? Там тоже вычисляют по транзакциям? и есть ли у нас в России те кто использует actual/standart costing?
                  0
                  Это единственный вариант. Или — жесткое позаказное планирование и производство (ПСИ формируется как «дерево» ЗНП-субЗНП). Но это как раз случай, описанный в статье -костыльная схема и «прощай планирование». Мы, заканчивая работать с SL в конце нулевых, ходили по этому варианту — он тупиковый. Если правильно запрограммировать вариант 2 — работать будет… Сейчас в своей системе (SCMo/СПМ) мы делаем именно так. Работает…
                  В этом направлении (как собирать затраты на ГП по ЗНП) работали РПЗ, не помню, что у них получилось. По «моим» заказчикам (до 2008г) «по честному» actual-costing и оч.неплохо был сделан на Готеке/Полипаке.
                  Питеркин Сергей.
                  P.S. Может пора уже upgrade до SCMo? ;) Если есть о чем поговорить — пишите sergey.piterkin@rightstep.ru или оставьте координаты.

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

                  Самое читаемое