Александр Карбаинов писал(а):

Юрий Рыбалка писал(а):

Если я правильно помню, экземпляр класса - это наследник класса, так?

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

Или так. Класс определяется неопределённым артиклем, а экземпляр - определённым

Переопределение свойств - это полиморфизм, да?

Я не знаю, можно ли доверять в вопросе ООП Википедии , но она говорит, что

Класс — это тип, описывающий устройство объектов. Понятие «класс» подразумевает некоторое поведение и способ представления. Понятие «объект» подразумевает нечто, что обладает определённым поведением и способом представления. Говорят, что объект — это экземпляр класса. Класс можно сравнить с чертежом, согласно которому создаются объекты. Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области.

Так все же, Lean - это класс или экземпляр класса относительно TPS?

И все же - разве экземпляр класса не наследует все свойства и методы класса? (ну, пока без полиморфизма лучше...)

Юрий Рыбалка писал(а):

Так все же, Lean - это класс или экземпляр класса относительно TPS?

И все же - разве экземпляр класса не наследует все свойства и методы класса? (ну, пока без полиморфизма лучше...)

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

Теперь Lean и TPS.
Вспоминайте историю. О каком наследовании экземпляром характеристик класса может идти речь, если TPS появилась ДО Lean?
И что такое lean в нашей истории? Это адаптация того, что американские специалисты увидели в TPS, под особенности американской производственной культуры. Происходило так: скатались 200 000 американских консультантов на Toyota, записали все, что можно, приехали домой и в своем американском leanzone.com стали совещаться:
5s у нас работать будет? Будет. Хреново, но будет
JIT? Будет
Быстрая переналадка? Будет
Дзидока? Ой, уберите эти китайские иероглифы. Придумаем что-нибудь свое...
5 почему? О, точно, будет.
Так, а как насчет пожизненного найма? Э, это точно работать не будет... Вычеркивайте
И еще кружки качества вычеркните - я по вечерам дома хочу сидеть, барбекю жарить, а не с этими тупыми рабочими о причинах проблем спорить
Ну а как же уважение к людям? Это надо оставить. Этому профсоюзы рады будут. Но объяснять, как у нас это сделать, не будем, кому надо - тот пусть и придумывает...

Вот так lean и получился. Слепок с TPS, увиденной глазами американских консультантов по управлению. И сам порядок появления lean и TPS не соответствует ООП, в ООП вы в любом случае сначала должны описать классы, а потом уже конкретные объекты этих классов. Есть исключение, но это уже специфика программирования...

Валерий Казарин писал(а):

Юрий, не стоит добавлять сюда ООП. Это не точное сравнение...

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

...Вот так lean и получился. Слепок с TPS, увиденной глазами американских консультантов по управлению.

Как раз тут мы анализировали, сравнивали подходы к поиску причин неудач. А чуть ниже я привел пример про повара и рецепт.

Так с учетом вышесказанного, Вы какой подход приветствовали бы?

Юрий Рыбалка писал(а):

Так с учетом вышесказанного, Вы какой подход приветствовали бы?

Я бы (как ушлый бывший консультант) выкрутился и придумал третий подход. 8)

На самом деле, приходится адаптировать подход к особенностям конкретного предприятия.

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

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

Насколько я помню, даже в "Гемба кайдзен" Масааки Имаи приводятся примеры разной реализации концепции кайдзен на японских предприятиях...

В общем, логика такая: надо знать методы и подходы TPS на том уровне, который позволяет адаптировать их под нужны конкретного предприятия. Где этот уровень проходит - я не знаю. 5 лет консалтинга и 5 крупных проектов (плюс несколько мелких) на предприятиях, которые радикально отличаются друг от друга), все еще не дают мне полной уверенности, что я увидел весь возможный спектр возможных подходов.

Валерий Казарин писал(а):

И что такое lean в нашей истории? Это адаптация того, что американские специалисты увидели в TPS, под особенности американской производственной культуры. Происходило так: скатались 200 000 американских консультантов на Toyota, записали все, что можно, приехали домой и стали совещаться:
5s у нас работать будет? Будет. Хреново, но будет
JIT? Будет
Быстрая переналадка? Будет
Дзидока? Ой, уберите эти китайские иероглифы. Придумаем что-нибудь свое...
5 почему? О, точно, будет.
Так, а как насчет пожизненного найма? Э, это точно работать не будет... Вычеркивайте
И еще кружки качества вычеркните - я по вечерам дома хочу сидеть, барбекю жарить, а не с этими тупыми рабочими о причинах проблем спорить
Ну а как же уважение к людям? Это надо оставить. Этому профсоюзы рады будут. Но объяснять, как у нас это сделать, не будем, кому надо - тот пусть и придумывает...

Вот так lean и получился.

Коллеги, продолжаю читать эту ветку форума, чтобы как говорится "дождаться финала и подведения итогов", уж очень интересно - куда могут завести долгие и упорные размышления на тему различий Lean и TPS?

Мне понравилось, как Валерий сумел здесь объяснить: Как появился Lean глазами "американских консультантов". Просто и убедительно!

Если дополнить историю и представить: А что было дальше? Могу предположить, что уже руководители американских предприятий, - тех, у кого не получилось (следуя описанным принципам) сходу взять Lean и за короткий срок получить желаемые результаты. Они смогли посетить заводы Toyota (и в Японии, и в США) и сделать свои выводы: что в описании Lean не совсем так! Но об этом в книгах не пишут.

Вячеслав Марков писал(а):

Они смогли посетить заводы Toyota (и в Японии, и в США) и сделать свои выводы: что в описании Lean не совсем так! Но об этом в книгах не пишут.

Ну не знаю, уже столько писано-переписано, что какой-нибудь дом или Lean сарай можно было уже построить.

Например, возьмите докторскую Стива Спира. Там есть "Пять правил", которые стоило бы обсудить.

Валерий Казарин писал(а):

Стремление выяснять до мельчайших подробностей детали отдельных действий/методов/инструментов мне не кажется очень эффективным. Точное копирование возможно только в условиях точного совпадения стартовых условий.
Я предпочитаю корректировать концепции отдельных методов или инструментов под ситуацию.

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

Речь о слепом копировании точно не шла ни в коем случае. Но одна из рабочих гипотез была в том, что среди инструментов ТПС есть некие "ключевые", отказ от которых делает неработоспособными другие, которые базируются на эффекте от применения этих "ключевых". Ну, это как связанные работы в стройке, например: нельзя красить потолок, предварительно его не выровняв шпатлевкой, а если и покрасишь - то результату точно не обрадуешься. А вот если потолок по проекту будет не крашеный, а подвесной, тогда и шпатлевка не нужна. Финишные полы не стоит делать, пока не закончен потолок, чтобы напольное покрытие не испортить. И так далее.

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

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

Вячеслав Марков писал(а):

А что было дальше? Могу предположить, что уже руководители американских предприятий, - тех, у кого не получилось (следуя описанным принципам) сходу взять Lean и за короткий срок получить желаемые результаты. Они смогли посетить заводы Toyota (и в Японии, и в США) и сделать свои выводы: что в описании Lean не совсем так! Но об этом в книгах не пишут.

Кто пишет книги? Руководители предприятий? Нет. Консультанты, эксперты, преподаватели, бывшие практики с японских предприятий, ...

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

Хотя используется эта практика широко.

Александр Филонов писал(а):

Например, возьмите докторскую Стива Спира. Там есть "Пять правил", которые стоило бы обсудить.

Александр, и Вы смогли это все прочитать? около 500 стр. на англ?