9-й вид потерь - управление вариантами
- Рыжов Дмитрий
- Автор темы
- Не в сети
- Захожу иногда
- Сообщений: 280
- Спасибо получено: 37
Игорь, приветствую! А можно подробности в "студию"! Очень интересна конкретная реализация. Вы пока единственный, кто это практически реализовывал.Игорь Киселев пишет: Привет из Новочеркасска! У нас такая система работает в штамповочного цехе. Есть промежуточный склад. Размер производимой партии вычисляется.
Идея возникла ещё на закате СССР.
И да, это унификация, и да, это Бережливое проектирование (дизайн).
Нужны подробности- обращайтесь )
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Рыжов Дмитрий
- Автор темы
- Не в сети
- Захожу иногда
- Сообщений: 280
- Спасибо получено: 37
Роман, давайте определимся. Снимать излишний ассортимент можно только изделия. Я уже говорил, это не всегда возможно.Роман Пантелеев пишет: Излишний ассортимент вполне может быть потерей. Однако решать проблему Вы предлагаете введя новую проблему: излишний НЗП... Причина ошибки в том, что Вы не снимать (унифицировать) излишний ассортимент собираетесь, а его сохранять - зачем?
Что бы унифицировать излишний ассортимент (детали), нужны затраты на проектирование и изготовление оснастки, инструмент, затраты конструктоско-технолгической службы, затраты на испытания, нужно достаточно много времени. Если вы сами не проектируете изделие (это делает сторонняя организация), то 2 года проекта превратятся в 3 года, если вам надо проводить испытания у заказчика
- 4-5 лет. Вы решите проблему, но это уже будет не актуально. Часть изделий будет снята, появятся новые.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Рыжов Дмитрий
- Автор темы
- Не в сети
- Захожу иногда
- Сообщений: 280
- Спасибо получено: 37
Как-то в мою логику не укладывается. Скорее, излишний ассортимент - корневая проблема, много переналадок, снижение мощностей - НЖЯ. Если еще левее двинуться,Роман Пантелеев пишет: Да потому что для Вас не излишний ассортимент проблема, а снижение мощностей из-за него - Вы решаете следствие, оставив причину.
то тогда не унифицированные детали/ отсутствие УЖЦ изделия / отсутствие искусственного снижения ассортимента деталей (или другого инструмента?) - корневая проблема.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Рыжов Дмитрий
- Автор темы
- Не в сети
- Захожу иногда
- Сообщений: 280
- Спасибо получено: 37
Роман, проблема в том, что при большой и изменяющейся каждый месяц номенклатуре и большом парке оборудования узкое место будет перемещаться по всему цеху. Цели снижения переналадок нет.Роман Пантелеев пишет: Позиция ТОС тут непреклонна: снижение переналадок нужно _только_ на ограничении и возможно изредка на РОМ (когда они приближаются к исчерпанию мощности и других способов получить мощность - нет). В остальных местах это скажется негативно на потоке. Решайте корневую причину чтобы выросла прибыль, а не снизились переналадки.
И да ТОС будет заготавливать на пол года вперёд. Если через полгода ограничением будут мощности (высокий сезон) и мы потеряем часть спроса. Что выпускать будет решено исходя из максимальной экономии будущего (в высокий сезон) ограничения и минимального расходования текущего. Как видите никаких снижений переналадок в цели нет.
Есть цель - искусственное снижение номенклатуры.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Рыжов Дмитрий
- Автор темы
- Не в сети
- Захожу иногда
- Сообщений: 280
- Спасибо получено: 37
Да, теперь понял идею.Сергей Питеркин пишет: 1. З/ч управляются совершенно отдельно - та-же ТПЗ или прогноз (на "плановое изделие" = ремонтное)
Спасибо, посмотрю.Сергей Питеркин пишет: 2. Плановое изделие не = новочеркасская система (хотя Родов близко к этому подошел...), см. planning item в MRP-ii концепции любая продвинутая западная книга или моя "ТВВ для России").
Да, запасом придется управлять. Я предполагал - КАНБАН. Прогнозирование это конечно супер, но мне трудно оценить, на сколько это сложно реализовать программно.Сергей Питеркин пишет: 3. Я правильно понял (как я думаю ...) Ваш запас Дмитрий неудобно администрировать - муда неизбежна. В виде излишков или дефицитов. Т.к. вариантивность изделий очевидно зависит от спроса - лучше "генерить запас" под прогноз спроса (на плановое изделие). После отладки системы (процедур) и при соотв. ИТ-поддержке бОльшая часть данного запаса должна стать виртуальной (осробенно, если допустимо вариьировать временем выполнения заказов), как в продвинутой классике assemble-to-order.
А вообще - цель какая?
Цель - искусственное снижение номенклатуры, т.е. снижение месячной номенклатуры деталей. И как следствие, повышение управляемости, снижение вариабельности процессов, облегчение ручного оперативного планирования. Плюс концентрация оптимизаторов на оставшейся номенклатуре. Дополнительные бонусы - повышение производительности (путем дополнительных мероприятий) на выбранной номенклатуре и снижение количества переналадок.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Рыжов Дмитрий пишет: Но также замечу, что и применение ТОС существенно осложниться: "плавающие" узкие места, которые то появляются, то исчезают.
Нет, ТОС к этому готов. Решение "Упрощенный ББК" (S-DBR) прекрасно справляется с такой ситуацией.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Рыжов Дмитрий
- Автор темы
- Не в сети
- Захожу иногда
- Сообщений: 280
- Спасибо получено: 37
Что-то похожее нашел у С.Е. Жаринова www.lipro.ru/Load/3-%D0%98%D0%BD%D0%BD%D0%BE%D0%B2%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4%D1%8B_(%D0%9A%D0%AD%D0%9C%D0%97).pdfВальчук Виктор Васильевич пишет: Нет, ТОС к этому готов. Решение "Упрощенный ББК" (S-DBR) прекрасно справляется с такой ситуацией.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Сергей Питеркин
- Не в сети
- Expert
- Сообщений: 571
- Спасибо получено: 218
если спрос будет прыгать - количество карточек КАНБАН придется постоянно пересчитывать (аксиома - канбан, если вариабельность не более 30% (т.е. +-15 от медианы)). Так что прогнозировать придется. И это не сложно, и ИТ поддержка - тоже не сложна (если только прогноз). Но сделать с ИТ классическую и продвинутую АТО - одна из сложнейших, но оч. интересных задач!
И, я не думаю, что стоит замыкаться на DBR или sDBR , сейчас уже гораздо больше и методов и техник и ПО, работающих с ограниченными мощностями ресурсов. ТОС в производстве здесь - далеко не впереди, особенно для сложных производств...
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Роман Пантелеев
- Не в сети
- Живу я здесь
- Сообщений: 2397
- Спасибо получено: 238
Рыжов Дмитрий пишет:
Роман, проблема в том, что при большой и изменяющейся каждый месяц номенклатуре и большом парке оборудования узкое место будет перемещаться по всему цеху. Цели снижения переналадок нет.Роман Пантелеев пишет: Позиция ТОС тут непреклонна: снижение переналадок нужно _только_ на ограничении и возможно изредка на РОМ (когда они приближаются к исчерпанию мощности и других способов получить мощность - нет). В остальных местах это скажется негативно на потоке. Решайте корневую причину чтобы выросла прибыль, а не снизились переналадки.
И да ТОС будет заготавливать на пол года вперёд. Если через полгода ограничением будут мощности (высокий сезон) и мы потеряем часть спроса. Что выпускать будет решено исходя из максимальной экономии будущего (в высокий сезон) ограничения и минимального расходования текущего. Как видите никаких снижений переналадок в цели нет.
Есть цель - искусственное снижение номенклатуры.
Зачем Вам снижать номенклатуру? Я услышал - для увеличения мощностей за счет снижения переналадок.
PS Проектировщики не всегда нужны - инженерно-технический персонал в полях может творить чудеса унификации.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Роман Пантелеев
- Не в сети
- Живу я здесь
- Сообщений: 2397
- Спасибо получено: 238
Сергей Питеркин пишет: Дмитрий,
если спрос будет прыгать - количество карточек КАНБАН придется постоянно пересчитывать (аксиома - канбан, если вариабельность не более 30% (т.е. +-15 от медианы)). Так что прогнозировать придется. И это не сложно, и ИТ поддержка - тоже не сложна (если только прогноз). Но сделать с ИТ классическую и продвинутую АТО - одна из сложнейших, но оч. интересных задач!
И, я не думаю, что стоит замыкаться на DBR или sDBR , сейчас уже гораздо больше и методов и техник и ПО, работающих с ограниченными мощностями ресурсов. ТОС в производстве здесь - далеко не впереди, особенно для сложных производств...
Например?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Главная
- Форум
- Форум LeanZone.ru
- Общий
- 9-й вид потерь - управление вариантами