TPS, или Lean Production

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

Потому я за перманентное моделирование во всех возможных деталях. Любая агрегирующая иерархия есть неадекватная фигня.

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

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

empiric - соблюдение технологии не может гарантировать повторяемого результата. Акцент на итеративность и быструю обратную связь.

Каждые из них по своему прав. Проблема координации и планирования деятельности больших групп разработки остается открытой

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

В саамом начале компьютеризации попалась мне книжка под названием "Если нет компьютера". За 30 копеек, 50 листов. Содержала четкое формализованное решение задачи делопроизводства. Без компьютера.
Проштудировамши книжку, я сразу попал в разряд крутых спецов по делопроизводству. Алгоритм был настолько прост, что если бы его еще и автоматизировать (без современных лишних прибамбасов), заниматься делопроизводством было так же просто, как спать.
А попробуйте изучить предмет по доке к Лотусу

[Владимир Либерзон]

Т.е. я возражаю против упомянутого выше словосочетания: "ВМЕСТО ... ЛУЧШЕ..." применительно к позаказным производствам - это ошибочное утверждение, которое может ввести многих читателей этих сообщений в очень серьезное заблуждение.

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

Вот Голдратт недавно объявил, что в проектах не должно быть более 300 операций!!! Расчет критической цепи предполагает назначение ресурсов, а значит описание проекта должно быть детальным. В графике строительства 12-этажного дома примерно 3000 операций. Но как их рассчитать вручную? Потому была выдвинута эта "законодательная инициатива". Все это было бы смешно ...

Воспринимайте "оппонентов" с юмором, а то вы сразу за пулемет.

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

Да, считают они сами.
Тут ожидатся типа - конечно, они это делают по заложенным в них ЧЕЛОВЕКОМ программам. В примитивных случаях это действительно так. Но, это все уходит.

Ладно, ладно. Не перегибай.
Это ВСЕГДА так.
Просто одни программы - жестко детерминированный алгоритм.
А другие - мягкие эвристики.

[Andruxa]

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

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

empiric - соблюдение технологии не может гарантировать повторяемого результата. Акцент на итеративность и быструю обратную связь.

Каждые из них по своему прав. Проблема координации и планирования деятельности больших групп разработки остается открытой

Сколько смотрю на этот вопрос, всё больше укрепляюсь здесь смешиваются два вопроса: проект и процесс. Процесс может быть Agile (Empric, problem-driven и так далее), а проект подразумевает срок, бюджет и результат.

И даже если неизвестны заранее все детали, то делаются прототипы, пилоты, и так далее. Есть конечно заказчики, с которыми я работаю, которые прямо говорят что САМИ НЕ ЗНАЮТ ЧТО ХОТЯТ ПОЛУЧИТЬ и ПЛАТЯТ за это (каждый месяц, а не за результат). Но это не проект, это услуга и процесс её предоставления. Только они не в России и зарабатывают они на кризисе. На бонус с последнего месяца работы с ними я неплохо погулял

И всё же я здесь держусь твердой позиции.
Если проект - то содержание, план, бюджет. Изменение содержания Заказчиком: оценим и выставим, ждите изменений в сроках. Всё.
Если услуга разработки - то хотите RUP, хотите Agile, хоть сферического коня в вакууме. Любой каприз за ваши деньги.

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

И кстати с размером коллектива это не особо коррелирует. Коллектив в 12 человек (максимум у меня на моих проектах) и коллектив в 1 человек - ничем с точки зрения планирования проекта не отличается.

[air]

Вот Голдратт недавно объявил, что в проектах не должно быть более 300 операций!!! Расчет критической цепи предполагает назначение ресурсов, а значит описание проекта должно быть детальным. В графике строительства 12-этажного дома примерно 3000 операций. Но как их рассчитать вручную? Потому была выдвинута эта "законодательная инициатива". Все это было бы смешно ...

Так и для обычного цеха машиностроительного предприятия (порядка 100 станков) в среднем в месяц проходит от 3500 до 4000 деталеопераций (линий на диаграмме Гантта), связанных с нескольким десяткам заказов. Я имею ввиду позаказное производство, естественно.

[Сахават]

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

А что есть бюджет???

1. Вот есть у меня 100р и я хочу на них поиграть. (Если ставки в игре позволяют втерется с такой суммой.
2. Надо делать определенное дело и тебуется столько то средств при вооот такой версии технологии дела этого.

1 случай бывает только в кино и в детских играх в инвестора.
А во втором случае бюджет вычислим и зависит от версии технологии. А технологию в бюджет заданный обычно фиг загонишь.

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

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

Насчет 300 операций... а почему нет?
Феномен восстановления страны из послевоенной разрухи НЕ базировался на детализации расписаний. Работала совершенно другая парадигма. Да, сегодня к ней вернуться и невозможно, и страшно. Но кто сказал, что не существует менее радикальной альтернативы?

На строительстве Запорожской АЭС расписание выглядело в виде шахматки на двух листах А1, перед совещанием девочка раскрашивала квадратики карандашем, сверяясь с какими-то бумажками. Во главе стола сидел великий Рэм Германович Хенох и тяжелым взглядом обводил собравшихся. Те-трепетали. Потом в накуренных кандейках, не считаясь со временем, сидели и спорили наши советские люди - и квадратики шахматки окрашивались в зеленый.

[Сахават]

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

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

empiric - соблюдение технологии не может гарантировать повторяемого результата. Акцент на итеративность и быструю обратную связь.

Каждые из них по своему прав. Проблема координации и планирования деятельности больших групп разработки остается открытой

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

[Сахават]

Нам еще предстоит оценить вред, нанесенный компьютером человеку

Я всегда с тобой соласен, но на счет "просто - гениально" - нет.
Фигня эти слоганы типа "жри овощи и фрукты и будешь 100 лет жить" - ослы их жрут тоннами, но ни один больше 20 лет не прожил.
Простые решения бывет у простых проблем или простое решение слишком дорогое решение.

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

но на счет "просто - гениально" - нет.

А кто сказал "просто"?
Гораздо проще построить сложное расписание, чем заставить 100 крутых мужиков трепетать от одного взгляда Рэм Германовича или вызвать у них чувство настоящей ответственности за все, что они делают.

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

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

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

[air]

...Фигня эти слоганы типа "жри овощи и фрукты и будешь 100 лет жить" - ослы их жрут тоннами, но ни один больше 20 лет не прожил...

+5 !

[Сахават]

Если бы я тебя пригласил автоматизировать материально-техническое обеспечение ремонтов и разрисовал процессы "как есть", ты бы, наверное, и придумал какой-нибудь алгоритм запредельной сложности.
Но только делать так не надо. Потому что среди бесконечного множества вариантов процесса, "как есть" - наихудший (с т.з. формальной логики).

Эх, я бы даже не смотрел "как есть" ваш...
мне бы - почему ремонт? как ремонт? кто ремонт?... и т.д.

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

... В "плохом" расписании время прохождения заказа считается от момента его поступления в систему (т.е. сколько он выполняется с т.з. заказчика), а в "хорошем"- от момента запуска в производство (время выполнения с т.з производителя). ...

Это не так. Во всех случаях время отсчитывается с момента выполнения первой операции. Действительно, правильнее было бы начинать отсчёт с даты запуска заказа в производство. Но участники игры предоставили для сравнения только диаграммы Гантта, а по ним это однозначно установить невозможно. Что касается моего решения, то такие данные у меня, естественно, есть. Результаты не сильно отличаются от приведенных. Уверяю Вас, что если бы это было по-другому, то некоторые из "проигравших" уже дошли бы до Страсбургского суда.

... Сергей и ФЕБ разные задачи решают, и прямолинейное сравнение неправомерно. ...

Условие задачи опубликовано. Никто не заставлял "проигравших" решать не ту задачу.

... А в общем, предложенная Сергеем эвристика не лишена изящества.

Это не моя эвристика. Я просто применил в данной задаче алгоритм DBR.

[Георгий Лейбович]

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

Это решение абсолютно в духе ТОС-приложения "Дистрибуция".

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

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

[Владимир Либерзон]

Насчет 300 операций... а почему нет?

А потому что речь идет о Critical Chain, то есть о составлении расписания с учетом ресурсных ограничений. На укрупненном расписании этого не получится.

Феномен восстановления страны из послевоенной разрухи НЕ базировался на детализации расписаний. Работала совершенно другая парадигма. Да, сегодня к ней вернуться и невозможно, и страшно. Но кто сказал, что не существует менее радикальной альтернативы?

На строительстве Запорожской АЭС расписание выглядело в виде шахматки на двух листах А1, перед совещанием девочка раскрашивала квадратики карандашем, сверяясь с какими-то бумажками. Во главе стола сидел великий Рэм Германович Хенох и тяжелым взглядом обводил собравшихся. Те-трепетали. Потом в накуренных кандейках, не считаясь со временем, сидели и спорили наши советские люди - и квадратики шахматки окрашивались в зеленый.

Вы еще лагеря вспомните и Беломорканал. Вы это в пример ставите?

[Сахават]

...

Давай ДБР на этот случай. Это самое простое изделие там.

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

... "Можно ли систему, динамика которой не является устойчивой, путем заклинаний в духе ТОС превратить в устойчивую?" ...

Евгений, путём заклинаний о "нелокализуемости" узких мест в мелкосерийных и единичных производствах Вам тоже ничего не добиться. Ответ очень простой - Вы ищете не там и не так! Обратитесь к специалистам, и Вам всё разъяснят.

Путём заклинаний о неприменимости подходов Шухарта и Деминга в мелкосерийных и единичных производствах Вам тоже ничего не добиться. Ответ очень простой - Вы не умеете этого делать! Обратитесь к специалистам, и Вас научат.

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

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

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

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

... для обычного цеха машиностроительного предприятия (порядка 100 станков) в среднем в месяц проходит от 3500 до 4000 деталеопераций (линий на диаграмме Гантта), связанных с нескольким десяткам заказов. ...

Ну и что? А зачем каждую операцию наносить на диаграмму Гантта? Может во всём цехе есть только 2-3 критических ресурса, которые нужно жёстко контролировать? И тогда диаграмма Гантта вообще не нужна!

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

мне бы - почему ремонт? как ремонт? кто ремонт?... и т.д.

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

Эх, я бы даже не смотрел "как есть" ваш...

Сахават, я реинжиниринг отрицаю как класс

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

Вы еще лагеря вспомните и Беломорканал. Вы это в пример ставите?

Я привел пример очень позитивной системы. Она эффективно достигала целей без компьютеров в силу ИНОЙ парадигмы управления.
А упомянутый Рэм Германович-недосягаемый образец руководителя, светлая ему память. И люди - они ведь не за страх работали.
Я же ни в коей мере не отрицаю важности хорошего плана. Пример привел чтобы показать возможность снижения уровня детализации расписания за счет создания ДРУГИХ свойств системы

[Ольга Кряжич]

...... я реинжиниринг отрицаю как класс

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

[Владимир Либерзон]

Я привел пример очень позитивной системы.

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

А что касается детализации расписаний, то необходимая детализация определяется поставленными задачами.

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

Давай ДБР на этот случай. Это самое простое изделие там.

Сахават, я честно просмотрел всю Вашу презентацию. Работа проделана огромная. Меня немного смутил результат, представленный на последнем 23-м слайде (цитирую):

Меры по расшивке узких мест дали результат: заказ выполнен 15 июля. Возможно, меры по распараллеливанию работ на два станка были избыточны, и достаточно было перевести ОЦ №285 на двухсменный график работ. Ответ на этот вопрос может быть получен дополнительной итерацией моделирования производственного расписания.

Дело в том, что в подобных ситуациях мы поступали по-другому. Без всяких "дополнительных итераций" просто подходили к оператору станка и между нами происходил примерно такой диалог:
- Ты сколько таких деталей можешь сделать за смену?
- Строго по нормочасам - 10 штук!
- А 20 можешь?
- Могу, но нарядов мне напишете на 2 смены! А то потом нормативы порежут!

[Bend]

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

А в любой системе есть, как минимум, две стороны - довольные и нет...

[Владимир Либерзон]

А в любой системе есть, как минимум, две стороны - довольные и нет...

А при чем здесь довольные?

[Сахават]

....

Да пойми же ты. Это только В ЭТОМ случае ОЦ285 был узким местом. Как только мы его расшили, тут же для этого потока узким местом стал совершенно другой ОЦ в 34 цеху, а если кроме клапана делалось бы еще и сам реактор, то узкое место было бы сооовсем другим и т.д.
Тут смысл был в том, что бы показать - какие полномочия можно дать проге для расшивки узких мест при заданных ограничениях, а не ходить по цехам и интервюровать всех подряд - а что ты можешь в обход технологии делать? Тут подразумевается, что технология и нормы не обсудаются - госприемка все это уже зафиксировал.

[Сахават]

А в любой системе есть, как минимум, две стороны - довольные и нет...

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

[air]

...

Не напрягайтесь, я Ваших текстов не читаю.

[Руслан Шарипов]

Не напрягайтесь, я Ваших текстов не читаю.

Но активно комментируете))