TPS, или Lean Production

[GRIG]

Система не может быть позитивной, если люди трепещут. Она может приводить к результатам, но дорогой ценой.

наблюдаю за текущим внедрением LP в СБ РФ, и думаю как раз об этом - что может получиться у Германа Оскоровича в условиях тотальной ненависти и презрения со стороны собственных сотрудников к нему лично и соответственно ко всем его начинаниям? Как совместить ненависть и необходимость не то, чтобы просто исполнить инструкцию, а проникнуться самим Духом такого отношения к своей работе? О чём думает человек? И думает ли? И человек ли?...

[Евгений_Кс]

Сообщение от Михаил_Шустер ...Сложность возникает как следствие борьбы со следствиями, а не с их причинами. По этой причине, сложность изначально закладывается и в конструкцию процессов

Моя формулировка, которой я пользуюсь: Сложное в исполнении управленческое решение есть результат неправильной постановки задачи менеджерами, что есть результат непонимания системы.
Ваша - короче и яснее. Здорово!

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

[Евгений_Кс]

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

Рискну перефразировать Жванецкого: что бы человек ни делал, он упорно ползет на грабли.
Зачем?
1. Мыслительный процесс должен быть групповым.
2. Группа должна включать реальных носителей деталей.
3. Задача модератора, супервайзера, спикера - организовать всплытие деталей из мозгов участников наружу, на общее обозрение.
Разве не об этом Thinking Process Голдратта, например, в изложении Детмера?

[air]

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

А Вы уверены, Евгений, что самостоятельно изменив конструкцию (т.е. превратив конусную гайку в обычную плоскую) Вы за счет этого "упрощения" не снизили надежность крепления?

"Простота хуже воровства" (с) А.Н.Островский

[Евгений_Кс]

А Вы уверены, Евгений, что самостоятельно изменив конструкцию (т.е. превратив конусную гайку в обычную плоскую) Вы за счет этого "упрощения" не снизили надежность крепления?

"Простота хуже воровства" (с) А.Н.Островский

Евгений, Вы не поняли. Конус оставляем, а другую сторону закрываем. Чтобы другой стороной нельзя было в принципе закрутить. Одновременно закрываем доступ к резьбе песка и грязи
И почему "самостоятельно"?

[air]

...Моя формулировка, которой я пользуюсь: Сложное в исполнении управленческое решение есть результат неправильной постановки задачи менеджерами, что есть результат непонимания системы.

Это спорный тезис. Тогда следует предположить, что любой сложный маневр является ошибкой его исполнителя. Но на практике часто встречаются ситуации, когда только за счет сложного маневрирования (управления) можно выйти на желаемый результат.

Пример: для того, чтобы плыть на парусном судне в нужном направлении (а не туда, куда дует ветер) необходимо совершать весьма сложный маневр как парусом, так и рулем этого судна.

[air]

Евгений, Вы не поняли. Конус оставляем, а другую сторону закрываем. Чтобы другой стороной нельзя было в принципе закрутить. Одновременно закрываем доступ к резьбе песка и грязи
И почему "самостоятельно"?

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

Так что Александр Николаевич Островский во многом был прав!

[Евгений_Кс]

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

Так что Александр Николаевич Островский во многом был прав!

1. Ваши комментарии к моему примеру поразительны. Неужели Вы без станков мыслить не можете? Сергей, как я Вас понимаю
2. Не следует манипулировать пословицами. Правильный вариант - "иная простота хуже воровства". Полный вариант - "иная простота хуже воровства, но с простака и взятка гладка".

[air]

1. Ваши комментарии к моему примеру поразительны. Неужели Вы без станков мыслить не можете? Сергей, как я Вас понимаю
2. Не следует манипулировать пословицами. Правильный вариант - "иная простота хуже воровства". Полный вариант - "иная простота хуже воровства, но с простака и взятка гладка".

Не вспоминайте его, пожалуйста, - он, на мой взгляд, давно перешел грань приличий в обращении ко мне, - грань, за которой следует обычное хамство. Если Вы его именуете "простаком", то мне вспоминается дополнение к сказанному выше:
"Но простакам любая слава, что масло к каше" ...

[Михаил_Шустер]

Разрешите поинтересоваться - почему?

Ольга, я об этом раньше "выписался", неохота возвращаться
В двух словах - крайне вредны любые попытки "натянуть предприятие на готовое решение". Во первых это невозможно. Во вторых, априори удачных решений не бывает.
Систему управления нужно зачать, выносить, родить, воспитать... это естественный путь. Все остальное - от лукавага. Включая ERP
Имхо, разумеется

[Михаил_Шустер]

Разве не об этом Thinking Process Голдратта, например, в изложении Детмера?

Жень, да я сторонник ТОС
Дались тебе эти команды... Не так оно все по жизни. Умеет человек вести совещание-вот тебе и команда на час. Умеешь говорить с людьми-вот тебе и групповой мыслительный процесс.
А все остальное-твоя внутренняя кухня.

[Михаил_Шустер]

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

Пример относится к классу "Защита от дурака".
Тупо красим торцы сквозной гайки в красный и зеленый цвет.

[air]

Жень, да я сторонник ТОС
Дались тебе эти команды... Не так оно все по жизни. Умеет человек вести совещание-вот тебе и команда на час. Умеешь говорить с людьми-вот тебе и групповой мыслительный процесс.
А все остальное-твоя внутренняя кухня.

Давайте и я объявлю себя "сторонником ТОС". Но только в рамках ее применимости.

[air]

Пример относится к классу "Защита от дурака".
Тупо красим торцы сквозной гайки в красный и зеленый цвет.

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

[Михаил_Шустер]

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

Да нет же. Рэм Германович пользовался колоссальным уважением и авторитет его был непоколебим. Людьми двигал совсем не страх, а теперь забытое сложное чувство даже не знаю как назвать... гордости, наверное...
В таких условиях, коллектив представлял собой иерархию "расписаний" в виде их носителей. Каждое из этих расписаний было перманентным и самооптимизирующимся, самоищущим и самоустраняющим узкие места. Так был придуман поточный метод строительства, укрупнения конструкций на монтажном дворе и множество разных улучшений. Потому что каждый хотел быть лучшим и это не пустые слова.

Меня удивил один бригадир, Богдан, бригада с западной Украины. Пришел на гидравлику 1 контура всей бригадой, хотя никто его не звал и нарядов на это не закрывал. На вопрос "зачем?" ответствовал: мало ли, вдруг чего потечет, подтянуть надо будет, а некому.

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

[Евгений_Кс]

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

Вы что, сговорились с Михаилом?
Меня уже подбрасывает в кресле.
Извести меня хотите?
При чем тут гайки и станки?!!!
Это иллюстрация того, что устранение причины возни с чем-то (решением и контролем того, какой стороной прикручивать, красить-не красить (!) ) устраняет саму возню и отвлечение ресурсов на нее!!!!

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

[Михаил_Шустер]

Давайте и я объявлю себя "сторонником ТОС". Но только в рамках ее применимости.

Только так
С драматическими перипетиями расписаний я знаком только по форуму и в эту сторону ТОС никогда не лез. Ее вполне хватает на верхнем уровне

[Михаил_Шустер]

устранение причины возни ... устраняет саму возню

А я как сказал?
Главное-знать, что устранять.
Вопрос "как" - открыт для творчества.

[air]

...Это иллюстрация того, что устранение причины возни с чем-то (решением и контролем того, какой стороной прикручивать, красить-не красить (!) ) устраняет саму возню и отвлечение ресурсов на нее!!!!

А сколько будет стоить "устранение причины"?

[Евгений_Кс]

А сколько будет стоить "устранение причины"?

Укушу в ноябре в Новосибирске... Если раньше не окажусь в Москве!

[Оксана Яковлева]

Укушу в ноябре в Новосибирске... Если раньше не окажусь в Москве!

Лучше бутылкой коньяка "киньте"

[Ark]

Юрий Гладких прислал такую ссылку http://gaperton.livejournal.com/33978.html:
Текущее состояние дискуссии о процессах разработки - специалисты разбились на два лагеря. defined process (CMMI), empiric process (Agile).

defined - ... соблюдение технологии гарантирует качество.

empiric - ... Акцент на итеративность и быструю обратную связь.

Каждые из них по своему прав...

Agile отвергают модели, а сторонники применения моделей ругают agile за качество. А вот третья позиция- и технологично, и быстро: http://2008.secr.ru/ru/@pageid=4548&...ionid=5163.htm :

... "Agile" и "MDA" (Model-Driven Architecture) не часто появляются в одном и том же предложении. Гибкие методы поддерживает идею, что тестирование работающей системы лучше, чем создание ее описаний...Подход Agile MDA основан на идее, что исполняемый код и модели это практически одно и то же...Исполняемая модель, именно потому что она является исполняемой, может быть построена, запущена, протестирована и изменена во время коротких, итерационных циклов

Противоречия "defined vs empiric" осознаны и устранимы на следующем витке развития. Так и в противостоянии технарей и гуманитариев- есть противоречие, есть повод для развития.

Сообщение от Сахават
Потому я за перманентное моделирование во всех возможных деталях...

Смотрим в одну сторону, коллега .

[Михаил_Шустер]

"defined vs empiric"

Мой выбор - экстремальное проектирование

[Andruxa]

Agile отвергают модели, а сторонники применения моделей ругают agile за качество. А вот третья позиция- и технологично, и быстро: http://2008.secr.ru/ru/@pageid=4548&...ionid=5163.htm :

... "Agile" и "MDA" (Model-Driven Architecture) не часто появляются в одном и том же предложении. Гибкие методы поддерживает идею, что тестирование работающей системы лучше, чем создание ее описаний...Подход Agile MDA основан на идее, что исполняемый код и модели это практически одно и то же...Исполняемая модель, именно потому что она является исполняемой, может быть построена, запущена, протестирована и изменена во время коротких, итерационных циклов

Противоречия "defined vs empiric" осознаны и устранимы на следующем витке развития. Так и в противостоянии технарей и гуманитариев- есть противоречие, есть повод для развития.

По-моему, этот тот же Agile - только вид сбоку. Одна из "догм" Agile - это как раз что короткими итерациями создаётся работающее ПО, и ещё что лучшее описание системы - это её исходный код.

Однако это не так Кстати тут нет никакого противоречия, есть только нежелание программистов заниматься моделированием (которое не есть новый виток развития, если присмотреться внимательнее к RUP) и согласованием. Заметьте, RUP и MSF - придуманы крупными компаниями, которые могут позволить себе построение моделей и хорошую работу с требованиями. А Agile в основном практикуют конторки и коллективчики (да, я знаю что XP впервые был применен на Chrysler, и что с того).

Но тут есть другая загвоздка. Как раз в том, сколько должно быть итерационных циклов. Документированные процессы преследуют целью как раз снижение числа итераций, тогда как недокументированные спрогнозировать их количество не могут (при всём желании, даже если ограничивать число, то не факт что будет получен нужный продукт).

Не может быть тут никакого "качественного" витка. Либо потребности зафиксированны на каком-то начальном этапе, либо нет. Модель - это способ общения уже и всё.

[Ark]

...

О разном мы говорим.

...Не может быть тут никакого "качественного" витка. Либо потребности зафиксированны на каком-то начальном этапе, либо нет. Модель - это способ общения уже и всё.

С позиции менеджера- да, модель- не более чем способ общения; а с т.з. разработчика ... - он ими думает .

[Сергей_Жаринов]

Да пойми же ты. ... нормы не обсуждаются ....

Сахават, так именно об этом я постоянно и твержу. Именно в этом главная проблема. Называется НОРМОЧАС. В условиях военной приёмки или госзаказа это проявляется особенно наглядно. На основе норм подсчитывается так называемая "трудоёмкость", потом себестоимость. Потом все эти цифры выкатываются военным или государству. Какая в этом случае задача? Понятно какая - максимально завысить нормы! Если Вы бывали в таких производствах, то должны знать, что все эти нормы обычно высосаны из пальца. Об этом прекрасно знают все исполнители, и даже сами заказчики.

А что делаете Вы? Вы вводите эти цифры в свою навороченную систему, а потом на их основе применяете супер-математические методы оптимизации для расчёта производственных расписаний. Как видно из Вашего сообщения, Вы даже исследуете разнообразные модельные ситуации, расшиваете узкие места и т.п. Так вот, к Вашим моделям у меня лично никаких претензий нет. А "по жизни" всё это, с моей точки зрения, мартышкин труд.

Проблема в том, что если входные данные (нормативы) не соответствуют действительности, то полученные на их основе модельные расчёты - тем более не имеют к реальной жизни никакого отношения!

P.S. А потом некоторые удивляются, почему расписания так неустойчивы и их приходится постоянно пересчитывать.

[Равиль]

Именно в этом главная проблема. Называется НОРМОЧАС. В условиях военной приёмки или госзаказа это проявляется особенно наглядно. На основе норм подсчитывается так называемая "трудоёмкость", потом себестоимость. Потом все эти цифры выкатываются военным или государству. Какая в этом случае задача? Понятно какая - максимально завысить нормы! Если Вы бывали в таких производствах, то должны знать, что все эти нормы обычно высосаны из пальца. Об этом прекрасно знают все исполнители, и даже сами заказчики.

ПОДТВЕРЖДАЮ. С ЭТИМ СТАЛКИВАЛСЯ. ПЫТАЛИСЬ ИЗМЕНИТЬ И ЗАСТАВИТЬ РАБОТАТЬ НА РЕЗУЛЬТАТ, А НЕ ЗА НОРМОЧАС, НО ПРОИГРАЛИ ВДРЫЗГ. ПРАВДА И ЗАВОД ВЕСЬМА НА СЛУХУ ПРОИГРАЛ ПО ПОЛНОЙ. НО НА ЭТОЙ СИСТЕМЕ ВЕСЬ ВПК ВЫСТРОЕН. И ИНСТРУКЦИИ В МИНИСТЕРСТВАХ НА ЭТОМ ЖЕ ДЕРЖАТСЯ. ЭТО СИСТЕМА, КОТОРОЙ ПОКА НИКТО СЕРЬЕЗНО НЕ ЗАНИВАЛСЯ. ОНА, В ТОМ ЧИСЛЕ, НЕ ДАЕТ ВНЕДРЯТЬ ПРОЕКТНЫЙ ПОДХОД К УПРАВЛЕНИЮ!

[Сахават]

Пошел базар-вокзал.
Я уже сказал - адекватность исходных данных совсем другой вопрос.
В частности нормочас ничем не плох и не хорош. Если он адекватен,то все ОК, наоборот - значит, скорее всего надо вытягивать зарплату а среднерыночной. Если не вытягивать через нормочас, то пойдут доплатные наряды. Другого не дано.
Если нормы нормальные, но дела идут плохо, то надо пересмотреть станочную базу и технологии.
Все это можно автоматизировать, но это уже не МЕС, для этого МЕС надо расширить базой знаниями о новом оборудовании, новых технологиях и дать полномочии советника по реструктрузации и инновациям.

[air]

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

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

[Сергей_Жаринов]

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

Сахават, это для Вас другой вопрос. Потому что Вы занимаетесь автоматизацией производства. А для меня - самый главный вопрос. Потому что меня приглашают для повышения доходности бизнеса.

Самое главное препятствие на пути повышения доходности бизнеса, с моей точки зрения, это НОРМОЧАС. Вот и коллеги с форума тоже подтверждают. Если совсем грубо, то логическая цепочка выглядит примерно так:

1. Как ты меня измеряешь, так я и буду себя вести.

2.1. Если ты мне платишь за нормочасы, то я буду стараться максимально завысить нормативы.

3. При этом:

___3.1. Если работы много, то за смену не буду напрягаться, а потом по двойной ставке отработаю в ночь или в выходные.

___3.2. Если работы мало, то наделаю какой-нибудь хрени, чтобы за смену набралось 8 нормочасов.

Сценарий 3.1 ведёт к увеличению производственных циклов (работы откладываются), росту запасов (работы дольше находятся в незавершёнке) и операционных расходов (оплата за переработки и сопутствующие вещи). Сценарий 3.2 ведёт к росту запасов (работы начинаются раньше чем нужно), операционных расходов (оплата ненужных работ) и увеличению производственных циклов (следствие роста незавершёнки). То есть всё то же самое, только в другом порядке.

2.2. Если ты мне платишь по средне- (сдельной, отраслевой, рыночной), то я буду стараться демонстрировать полную занятость в течение всей смены. Дальше см. п.3