1. Кроме как «почитать Майкла Пинедо» какие-то еще замечания по существу будут? Можно упомянуть еще про Factory Physics, Forrester, Bruker, и др. не говоря уж о Первозванском и Канторовиче. Кстати, только первые из 2х рассматривают задачу Planning, которая на минуточку, принципиально отличается от задачи Scheduling. И упор у них, как и у Pinedo, к сожалению в основном на scheduling. В статье упор — именно на Planning! Но без глубокой математики конечно…
2. MRP-ii — не система. И не алгоритм(ы)- для тех, кто понимает. ERP — класс (разных!) систем. Статья не про это, прочитайте еще раз.
3. Разузлование (в MRP) действительно крайне простая штука. Хотя не видел (русских) экономистов, которые это знают. Разузлование в сетевых APS алгоритмах — сложнее. И совсем уж не такое простое про программировании (если есть цель, чтобы работало быстро). Но — не квантовая механика конечно.
4. Самое сложное — применение всего это в реальности: может, но не всегда и не везде. 80 или даже 90% сложности планирования реального производства — это не математика. Ни разу. В т.ч. об этом — в следующих статьях.
5. "… полной неадекватности теории таких систем реальности" — это в РФ, с редкими исключениями. На западе — ИТ-системы управления (включая, но далеко не ограничиваясь ERP) поддерживающие методы (включая, но далеко не ограничиваясь MRP-ii) — просто must. Без всяких волшебных математических или цифровых чудес, которые только «в это стране» рассматриваются как волшебные палочки.
Комменты по существу — приветствуются.
Питеркин Сергей
Это единственный вариант. Или — жесткое позаказное планирование и производство (ПСИ формируется как «дерево» ЗНП-субЗНП). Но это как раз случай, описанный в статье -костыльная схема и «прощай планирование». Мы, заканчивая работать с SL в конце нулевых, ходили по этому варианту — он тупиковый. Если правильно запрограммировать вариант 2 — работать будет… Сейчас в своей системе (SCMo/СПМ) мы делаем именно так. Работает…
В этом направлении (как собирать затраты на ГП по ЗНП) работали РПЗ, не помню, что у них получилось. По «моим» заказчикам (до 2008г) «по честному» actual-costing и оч.неплохо был сделан на Готеке/Полипаке.
Питеркин Сергей.
P.S. Может пора уже upgrade до SCMo? ;) Если есть о чем поговорить — пишите sergey.piterkin@rightstep.ru или оставьте координаты.
Ответ.
1. ЗНП, тем более в классической западной ERP — это инструмент исполнения и сбора затрат — прямых производственных. И, да, все это может падать на субсчета 20ки — но нашим бухгалтерам об этом лучше не говорить — крыша поедет. Т.к. это не их «честная, точная ПОСМЕРТНАЯ с\с»
2. Возвращаюсь к вопросу… Если нет жесткой связки субЗНП-субЗНП-ЗНП (на готовую), то единственный вариант сбора (для РСБУ) — это вычислить по транзакциям (matl tran и jobtran) списания на ЗНП, прихода по ЗНП, списания (в след.ЗНП) прихода на СГД (например) и списания на ЗНП на готовую. И — сделать партионный учет на складах…
Т.е. тупо вычислять, на какую партию (ЗНП) что списано, что и в какую партию оприходовали (здесь- вычисляем с/с 1шт. в партии если надо...), далее — каком кол-ве из этой партии (и по какой цене) пошло на след.партию (ЗНП) и так далее, до списания на ГП.
Т.е. делаете «трассировку партии» и по ней вычисляете, сколько и чего «упало» на ГП.
3. Если не заморачиваетесь РСБУ а по-честному хотите видеть прямую производственную с/с, и на п/фи на ГП — используйте стандартный механизм (западной ERP). Либо actual cost либо standart costing (фактическая или нормативная).
Повторюсь: если «с компьютером у него <кладовщика>прибавляется (заметно) в работе»… выкиньте систему, которая стоит на компьютере (а заодно и компьютер) на помойку.
Что «получить»или «отпустить» — кладовщику «говорят» через системы менеджер по закупкам МТС или диспетчер/плановик/мастер/распред производства. И это задание он может получить как распечатку или сразу задание на планшет/смартфон. Кладовщику (в случае «отпустить») остается только собрать это физически и щелкнуть сканером по ШК ТМЦ. И это гораздо быстрее, чем записать это на клочке бумаги, а потом продублировать это в своей тетрадочке и еще и картотеке…
Добрый день!
Спасибо за комментарий. По существу.
1. В статье НЕ рассказывается о проблемах внедрения ERP — но, о проблемах использования НЕдовнедренной/неправильно внедренной ERP. Т.е. «внедрили», а что и как — непонятно :))
По комментариям.
1) Брак не есть проблема внедрения и даже использования ERP (или, скажем ближе к смыслу — системы планирования, управления производства (или, что правильнее. ИМХО — СПМ — Система Планирования и Мониторинга производства). % брака вводится экспертно вначале (цифры всегда есть!), далее — довольно быстро собирается по статистике (если планирование/учет внедрены корректно!). Далее — «зажимаются гайки» в процессах комплектации и списания в производство с регистрацией готовой и брака, (через ИТ систему), с одновременной отменой наказания за брак (!, только если не сообщил!) И все устаканивается! ЕСЛИ руководство на это идет…
2) по входимости и количеству (не считая обычно завышенных норм материалов) ошибки редки, т.к. в реальном производстве оч.быстро выявляются, не важно, ИТ-системы есть или нет,
3) трудовое нормирование. Норм с ошибками — давно не видел. Они — просто кривые! потому, что:
а) зарплатные,
б) институт нормирования давно утерян, никто не знает, как и зачем (за 10 последних лет видел пару заводов, где все-же нормируют)
в) даже если как-то и пытаются, нормируют технологи и/или нормировщики ОТиЗ. И они понятия не имеют (не обучали, никто не сказал, зачем?...) что нормировать надо не только собственно операции, но и кучу временных параметров, определяемых моделью производства/планирования,
4) если процессы нормально спроектированы (Lean) система внедрена правильно — НЕ ДОЛЖНО быть лишнего персонала (тем более — специального), для выполнения УЧЕТНЫХ операций. Т.е. операций, необходимых для адекватного отображения в ИТ-системе реальной жизни. И процессы и ИТ-средства сейчас достаточно продвинуты, даде на уровне рабочего и мастера, не говоря уж о кладовщиках… Сравните: трудозатраты на продажи и учет в магазине типа «гастроном» Vs. трудозатраты на продажи и учет в «супермаркете». И время, которое вы тратите, как покупатель.
Да, иногда трудочасов (в сумме) на ввод информации действительно требуется больше. Но только в случае, если на заводе не адекватный учет. Но даже в этом случае, будет принципиальное сокращение трудозатрат на «администрирование» производства и закупок. Т.е. сокращение (и значительное) трудозатрат ПДО, ПДБ и пр.
2. MRP-ii — не система. И не алгоритм(ы)- для тех, кто понимает. ERP — класс (разных!) систем. Статья не про это, прочитайте еще раз.
3. Разузлование (в MRP) действительно крайне простая штука. Хотя не видел (русских) экономистов, которые это знают. Разузлование в сетевых APS алгоритмах — сложнее. И совсем уж не такое простое про программировании (если есть цель, чтобы работало быстро). Но — не квантовая механика конечно.
4. Самое сложное — применение всего это в реальности: может, но не всегда и не везде. 80 или даже 90% сложности планирования реального производства — это не математика. Ни разу. В т.ч. об этом — в следующих статьях.
5. "… полной неадекватности теории таких систем реальности" — это в РФ, с редкими исключениями. На западе — ИТ-системы управления (включая, но далеко не ограничиваясь ERP) поддерживающие методы (включая, но далеко не ограничиваясь MRP-ii) — просто must. Без всяких волшебных математических или цифровых чудес, которые только «в это стране» рассматриваются как волшебные палочки.
Комменты по существу — приветствуются.
Питеркин Сергей
В этом направлении (как собирать затраты на ГП по ЗНП) работали РПЗ, не помню, что у них получилось. По «моим» заказчикам (до 2008г) «по честному» actual-costing и оч.неплохо был сделан на Готеке/Полипаке.
Питеркин Сергей.
P.S. Может пора уже upgrade до SCMo? ;) Если есть о чем поговорить — пишите sergey.piterkin@rightstep.ru или оставьте координаты.
1. ЗНП, тем более в классической западной ERP — это инструмент исполнения и сбора затрат — прямых производственных. И, да, все это может падать на субсчета 20ки — но нашим бухгалтерам об этом лучше не говорить — крыша поедет. Т.к. это не их «честная, точная ПОСМЕРТНАЯ с\с»
2. Возвращаюсь к вопросу… Если нет жесткой связки субЗНП-субЗНП-ЗНП (на готовую), то единственный вариант сбора (для РСБУ) — это вычислить по транзакциям (matl tran и jobtran) списания на ЗНП, прихода по ЗНП, списания (в след.ЗНП) прихода на СГД (например) и списания на ЗНП на готовую. И — сделать партионный учет на складах…
Т.е. тупо вычислять, на какую партию (ЗНП) что списано, что и в какую партию оприходовали (здесь- вычисляем с/с 1шт. в партии если надо...), далее — каком кол-ве из этой партии (и по какой цене) пошло на след.партию (ЗНП) и так далее, до списания на ГП.
Т.е. делаете «трассировку партии» и по ней вычисляете, сколько и чего «упало» на ГП.
3. Если не заморачиваетесь РСБУ а по-честному хотите видеть прямую производственную с/с, и на п/фи на ГП — используйте стандартный механизм (западной ERP). Либо actual cost либо standart costing (фактическая или нормативная).
habr.com/ru/post/470429
habr.com/ru/post/470429
habr.com/ru/post/470429
Что «получить»или «отпустить» — кладовщику «говорят» через системы менеджер по закупкам МТС или диспетчер/плановик/мастер/распред производства. И это задание он может получить как распечатку или сразу задание на планшет/смартфон. Кладовщику (в случае «отпустить») остается только собрать это физически и щелкнуть сканером по ШК ТМЦ. И это гораздо быстрее, чем записать это на клочке бумаги, а потом продублировать это в своей тетрадочке и еще и картотеке…
Спасибо за комментарий. По существу.
1. В статье НЕ рассказывается о проблемах внедрения ERP — но, о проблемах использования НЕдовнедренной/неправильно внедренной ERP. Т.е. «внедрили», а что и как — непонятно :))
По комментариям.
1) Брак не есть проблема внедрения и даже использования ERP (или, скажем ближе к смыслу — системы планирования, управления производства (или, что правильнее. ИМХО — СПМ — Система Планирования и Мониторинга производства). % брака вводится экспертно вначале (цифры всегда есть!), далее — довольно быстро собирается по статистике (если планирование/учет внедрены корректно!). Далее — «зажимаются гайки» в процессах комплектации и списания в производство с регистрацией готовой и брака, (через ИТ систему), с одновременной отменой наказания за брак (!, только если не сообщил!) И все устаканивается! ЕСЛИ руководство на это идет…
2) по входимости и количеству (не считая обычно завышенных норм материалов) ошибки редки, т.к. в реальном производстве оч.быстро выявляются, не важно, ИТ-системы есть или нет,
3) трудовое нормирование. Норм с ошибками — давно не видел. Они — просто кривые! потому, что:
а) зарплатные,
б) институт нормирования давно утерян, никто не знает, как и зачем (за 10 последних лет видел пару заводов, где все-же нормируют)
в) даже если как-то и пытаются, нормируют технологи и/или нормировщики ОТиЗ. И они понятия не имеют (не обучали, никто не сказал, зачем?...) что нормировать надо не только собственно операции, но и кучу временных параметров, определяемых моделью производства/планирования,
4) если процессы нормально спроектированы (Lean) система внедрена правильно — НЕ ДОЛЖНО быть лишнего персонала (тем более — специального), для выполнения УЧЕТНЫХ операций. Т.е. операций, необходимых для адекватного отображения в ИТ-системе реальной жизни. И процессы и ИТ-средства сейчас достаточно продвинуты, даде на уровне рабочего и мастера, не говоря уж о кладовщиках… Сравните: трудозатраты на продажи и учет в магазине типа «гастроном» Vs. трудозатраты на продажи и учет в «супермаркете». И время, которое вы тратите, как покупатель.
Да, иногда трудочасов (в сумме) на ввод информации действительно требуется больше. Но только в случае, если на заводе не адекватный учет. Но даже в этом случае, будет принципиальное сокращение трудозатрат на «администрирование» производства и закупок. Т.е. сокращение (и значительное) трудозатрат ПДО, ПДБ и пр.
Питеркин Сергей