Дмитрий Касьянов пишет: Теперь я расскажу, как я представляю себе ТРМ

Вычеркиваю все, что написал. Грешным делом думал, вы из этих... мальчиков-поговорить. А у вас дельная программа под логичные цели. Дальше можно что-то говорить уже по делу
Я, правда, и до этого выступления решил признать, что погорячился. Каждый должен заниматься своим делом - вот вы своим и занимаетесь. А кому положено - займутся маркетингом или планированием. Только так

Дмитрий Касьянов пишет: ...меньше поломок – меньше время простоя – больше произведенной качественной продукции – выше заработная плата...

Логика декларируется правильная!

Но она не будет работать, если:

(1) Уменьшение количества поломок не ведет к росту проданной продукции. Т.е. нужно посмотреть можно ли реализовать дополнительно выпущенную продукцию (появятся ли деньги для роста зарплаты участникам проекта TPM)?

(2) Увеличение произведенной продукции не ведет к увеличению з/п. Например, з/п ремонтников может вообще не зависеть от объемов произведенной продукции, а определяться объемами ремонта (чем больше ремонтирую, тем больше получаю).

(3) Состояние оборудования и количество произведенной продукции для операторов эксплуатирующих оборудование может находиться в обратной от желаемого состояния зависимости. Например, з/п оператора зависит от выполнения месячного плана (сделка + премия), однако они простаивали 2/3 месяца ввиду отсутствия материалов, и вот материалы появились и у операторов возникает выбор выпустить 1/3 от плана правильно эксплуатируя оборудование и не заработать, или включить "вредные для жизни" оборудования режимы, но выполнить план (заработать денег) ценой гибели оборудования?

Т.е. для привлечения людей в проект по ТРМ по указанной логике нужнопроверить будет ли она работать на самом деле?

Владимир Михейкин пишет:

Дмитрий Касьянов пишет: ...меньше поломок – меньше время простоя – больше произведенной качественной продукции – выше заработная плата...

Логика декларируется правильная!

Но она не будет работать, если:

(1) Уменьшение количества поломок не ведет к росту проданной продукции. Т.е. нужно посмотреть можно ли реализовать дополнительно выпущенную продукцию (появятся ли деньги для роста зарплаты участникам проекта TPM)?

(2) Увеличение произведенной продукции не ведет к увеличению з/п. Например, з/п ремонтников может вообще не зависеть от объемов произведенной продукции, а определяться объемами ремонта (чем больше ремонтирую, тем больше получаю).

(3) Состояние оборудования и количество произведенной продукции для операторов эксплуатирующих оборудование может находиться в обратной от желаемого состояния зависимости. Например, з/п оператора зависит от выполнения месячного плана (сделка + премия), однако они простаивали 2/3 месяца ввиду отсутствия материалов, и вот материалы появились и у операторов возникает выбор выпустить 1/3 от плана правильно эксплуатируя оборудование и не заработать, или включить "вредные для жизни" оборудования режимы, но выполнить план (заработать денег) ценой гибели оборудования?

Т.е. для привлечения людей в проект по ТРМ по указанной логике нужнопроверить будет ли она работать на самом деле?

Владимир, в целом с вами согласен. Отвечаю по пунктам.
1. Всего лишь одна поломка может оставить рабочих без зарплаты, если она будет очень серьезной, даже в том случае если, например, загрузка производства будет на 50%. Конец месяца - поломка, которая устраняется несколько дней - нет произведенной продукции - нет заработной платы.
2. Не знаю от чего зависит ЗП ремонтников, но точно не от объемов ремонта. Завтра узнаю.
3. Здесь проще 2ую смену ввести. Но в целом расчет ведется заранее - чего и сколько производить. Поэтому таких накладок не должно быть. Мы сейчас в основном производим на внутреннее потребление.

Дмитрий, очень интересно было бы посмотреть на ваши контрольные карты процесса.
Сейчас далек от этой темы, но в свое время пришлось немало поломать голову над проблемами линий переработки вторсырья.

Павел, извините за мою дремучесть, но я не знаю, что такое контрольные карты процесса. Конечно, я что-то себе представляю в голове, т.е. как они должны выглядеть, но то, что я себе представляю, того точно нет! Может ссылочку какую дадите, чтобы я с коллегами посмотрел на уже разработанные карты и дал вам более точный ответ? У карт, наверное, разное исполнение бывает.

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

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

Да как-то все по простому. Дата/время, описание события.

Событие описывается отвечая на вопросы Как? Что? Когда? Кто? и т.д. (через призму 6M - "Медиа" (Условия, Среда), Материалы (сырье, расходные, информация и пр), Метод (процесс), Man-power (Люди), Машина (оборудование), Measururements (измерения, инспекция)).

Называем это "Хронология".

Кроме этого, ведется контроль за конкретными параметрами в процессе. Это зависит от специфики и что наиболее критично. При этом можно использовать SPC (контрольные карты), это если данных много и нужна визуальная картинка для быстрой оценки, или статистической обработки (отклонений 2 сигма, 1 cигма, 3 сигма, среднего, медианы, моды и прочего). Формы могут быть самые разные. Взависимости от процесса. Но идентификация естественно необходима, код оборудования, код запчасти, код ошибки и т.п.

Начинаем анализ с обычного Fishbone (Ишикавы) и составляем список вероятных причин.


А что Вы придумали?

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

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

Дмитрий Стукалов пишет: Крайне недостойное поведение! Блокирую на 2 недели.

Учитывая отсутствие на форуме правил, данное действие окончательно убедило меня в наличии определённого... сектанства. Или самодурства. И то и другое достойно сожаления.