Цитата:
Сообщение от air
Ну ведь можете, если захотите...Всё доступно даже Мне
Мой респект и уважуха с +333 :)
Вид для печати
Цитата:
Сообщение от air
Ну ведь можете, если захотите...Всё доступно даже Мне
Мой респект и уважуха с +333 :)
Евгений, у меня здесь нет оппонентов, потому что я излагаю известные научные факты, а не свои соображения, которые кто-то мог бы оспаривать. :)Цитата:
Сообщение от Евгений_Кс
Обсуждение есть, а оппонента нет.Цитата:
Сообщение от air
"заклинание в духе ТОС" - научный факт.
Орригинально. :)
Как бы Вы, Евгений, назвали человека, который пытается "оппонировать" (т.е. ставить под сомнения в обсуждениях) научно доказанные факты? Я, например, таких людей называю фантазерами. :) Слово "оппонент" в данном случае абсолютно неуместно.Цитата:
Сообщение от Евгений_Кс
PS. Я понимаю, что вероятно далеко не всем нравится то, что я здесь написал. Но я защищаю, пусть даже в меньшинстве, тот рубеж, за который нельзя пускать этот "гербалайф".
http://empty.org.ua/den/!cid_image020.gif
Вот уже и 37-м годом повеяло. Какие факты? Кто доказал? Насколько уместно доказательство?Цитата:
Сообщение от air
Вообще-то все новое - это оппонирование к научнодоказанным фактам :)
Новое как известно проходит три стадии
Этого не может быть (фантазии)
В этом что-то есть
Это знают все!
Собака порылась в том, что такое "уровень"Цитата:
Сообщение от air
Бодания идут на "пограничном" уровне, как бы "на стыке" между ERP и MES. В этой (довольно широкой и аморфной) области сходятся принципиально разные парадигмы: управление людьми и управление машинами.
Назначение ТОС - правильно поставить задачу
Назначение MES - решить поставленную задачу
Конфликты обостряются, когда сторонники ТОС занимаются решением задач, а сторонники МЕС - их постановкой.
Нет, Михаил, сторонники MES никогда не претендовали на постановку задачи. Manufacturing Execution Sytems - это системы исполнительные. Но в своей области нам, все-таки, виднее, нужен ли здесь ТОС или нет. :) Еще раз повторюсь: если производство относится к массовому или крупносериному типу, то никто против ТОС не возражает.Цитата:
Сообщение от Михаил_Шустер
Но для позаказных производств, - Sorry.
Новое, говорите?... :) :) :)Цитата:
Сообщение от john644
No comments.
Да, считают они сами.Цитата:
Сообщение от Евгений_Кс
Тут ожидатся типа - конечно, они это делают по заложенным в них ЧЕЛОВЕКОМ программам. В примитивных случаях это действительно так. Но, это все уходит. Все болше и больше человек дает просто направление, интуитивно (как ему кажется) оцененный как "верное". При больших размерностях чек уже не в состоянии оценить вход, ход и выход собственного алгоритма. Наступает эра чек-комп, когда обратная связь от компа зачастую намного интересенее, чем первоначально заданное "направление".
Потому я за перманентное моделирование во всех возможных деталях. Любая агрегирующая иерархия есть неадекватная фигня.
Ну да. А в TOC сделана попытка привести эти традиционные методы в систему. Не первая и не последняя. В этом ничего плохого нет.Цитата:
Сообщение от Сахават
К сожалению еще не все научились пользоваться компьютерами.
Юрий Гладких прислал такую ссылку http://gaperton.livejournal.com/33978.html:Цитата:
Сообщение от Сахават
Текущее состояние дискуссии о процессах разработки - специалисты разбились на два лагеря. defined process (CMMI), empiric process (Agile).
defined - процедуры контроля качества, взгляд как на доставку артефактов, акцент на повторяемость и воспроизводимость процесса, понимаемого как набор активностей, планирование, соблюдение технологии гарантирует качество.
empiric - соблюдение технологии не может гарантировать повторяемого результата. Акцент на итеративность и быструю обратную связь.
Каждые из них по своему прав. Проблема координации и планирования деятельности больших групп разработки остается открытой
В саамом начале компьютеризации попалась мне книжка под названием "Если нет компьютера". За 30 копеек, 50 листов. Содержала четкое формализованное решение задачи делопроизводства. Без компьютера.
Проштудировамши книжку, я сразу попал в разряд крутых спецов по делопроизводству. Алгоритм был настолько прост, что если бы его еще и автоматизировать (без современных лишних прибамбасов), заниматься делопроизводством было так же просто, как спать.
А попробуйте изучить предмет по доке к Лотусу :)
Если я не умею водить машину, то лучше буду использовать велосипед.Цитата:
Сообщение от air
А если стесняюсь признаться, что не умею водить машину, то буду доказывать, что велосипед проедет там, где машина не сможет, что это полезно для здоровья, что у него радиус поворота меньше, что в пробках проскочу и т.д. И к тому же это быстрее, чем пешком, а скорость машины чересчур большая, не способствует созерцанию.
И, кстати, это правда. Только в серьезные проекты с этими методами все равно, что из Москвы в Сидней на велосипеде. А вот маленькие задачи можно решать вполне эффективно.
Вот Голдратт недавно объявил, что в проектах не должно быть более 300 операций!!! Расчет критической цепи предполагает назначение ресурсов, а значит описание проекта должно быть детальным. В графике строительства 12-этажного дома примерно 3000 операций. Но как их рассчитать вручную? Потому была выдвинута эта "законодательная инициатива". Все это было бы смешно ...
Воспринимайте "оппонентов" с юмором, а то вы сразу за пулемет.
Ладно, ладно. Не перегибай.Цитата:
Сообщение от Сахават
Это ВСЕГДА так.
Просто одни программы - жестко детерминированный алгоритм.
А другие - мягкие эвристики.
:)
Сколько смотрю на этот вопрос, всё больше укрепляюсь здесь смешиваются два вопроса: проект и процесс. Процесс может быть Agile (Empric, problem-driven и так далее), а проект подразумевает срок, бюджет и результат.Цитата:
Сообщение от Михаил_Шустер
И даже если неизвестны заранее все детали, то делаются прототипы, пилоты, и так далее. Есть конечно заказчики, с которыми я работаю, которые прямо говорят что САМИ НЕ ЗНАЮТ ЧТО ХОТЯТ ПОЛУЧИТЬ и ПЛАТЯТ за это (каждый месяц, а не за результат). Но это не проект, это услуга и процесс её предоставления. Только они не в России и зарабатывают они на кризисе. На бонус с последнего месяца работы с ними я неплохо погулял :)
И всё же я здесь держусь твердой позиции.
Если проект - то содержание, план, бюджет. Изменение содержания Заказчиком: оценим и выставим, ждите изменений в сроках. Всё.
Если услуга разработки - то хотите RUP, хотите Agile, хоть сферического коня в вакууме. Любой каприз за ваши деньги.
По-моему, ноги этого holywar растут из того факта, что есть менеджеры проектов, которые не работают с бюджетом (ну, разные бывают матрицы в IT), поэтому тратят умственную энергию на разгадывание задачек и тратят бесценные калории на ковыряние в процессах, вместо того, чтобы посмотреть на всё это со стороны, в том числе и с экономической.
И кстати с размером коллектива это не особо коррелирует. Коллектив в 12 человек (максимум у меня на моих проектах) и коллектив в 1 человек - ничем с точки зрения планирования проекта не отличается.
Так и для обычного цеха машиностроительного предприятия (порядка 100 станков) в среднем в месяц проходит от 3500 до 4000 деталеопераций (линий на диаграмме Гантта), связанных с нескольким десяткам заказов. Я имею ввиду позаказное производство, естественно.Цитата:
Сообщение от Владимир Либерзон
:)
А что есть бюджет???Цитата:
Сообщение от Andruxa
1. Вот есть у меня 100р и я хочу на них поиграть. (Если ставки в игре позволяют втерется с такой суммой.
2. Надо делать определенное дело и тебуется столько то средств при вооот такой версии технологии дела этого.
1 случай бывает только в кино и в детских играх в инвестора.
А во втором случае бюджет вычислим и зависит от версии технологии. А технологию в бюджет заданный обычно фиг загонишь.
Нам еще предстоит оценить вред, нанесенный компьютером человеку
Компьютер открыл ящик Пандоры, обеспечив широким массам доступ к бумаготворчеству. Получился экспоненциально самовоспроизводящийся поток активностей, которые сами себе являются единственной причиной
Насчет 300 операций... а почему нет?
Феномен восстановления страны из послевоенной разрухи НЕ базировался на детализации расписаний. Работала совершенно другая парадигма. Да, сегодня к ней вернуться и невозможно, и страшно. Но кто сказал, что не существует менее радикальной альтернативы?
На строительстве Запорожской АЭС расписание выглядело в виде шахматки на двух листах А1, перед совещанием девочка раскрашивала квадратики карандашем, сверяясь с какими-то бумажками. Во главе стола сидел великий Рэм Германович Хенох и тяжелым взглядом обводил собравшихся. Те-трепетали. Потом в накуренных кандейках, не считаясь со временем, сидели и спорили наши советские люди - и квадратики шахматки окрашивались в зеленый.
Ссылка битая.Цитата:
Сообщение от Михаил_Шустер
Дело не в том что они оба правы - никто не прав.
Просто разные задачи требуют разного подхода. Устоявшиеся вещи - технология и регламент. Новые - попытка, оценка, следующий ход...
Я всегда с тобой соласен, но на счет "просто - гениально" - нет.Цитата:
Сообщение от Михаил_Шустер
Фигня эти слоганы типа "жри овощи и фрукты и будешь 100 лет жить" - ослы их жрут тоннами, но ни один больше 20 лет не прожил.
Простые решения бывет у простых проблем или простое решение слишком дорогое решение.
А кто сказал "просто"?Цитата:
Сообщение от Сахават
Гораздо проще построить сложное расписание, чем заставить 100 крутых мужиков трепетать от одного взгляда Рэм Германовича или вызвать у них чувство настоящей ответственности за все, что они делают.
Может пример мой слишком пафосный, возьму попроще
Если бы я тебя пригласил автоматизировать материально-техническое обеспечение ремонтов и разрисовал процессы "как есть", ты бы, наверное, и придумал какой-нибудь алгоритм запредельной сложности.
Но только делать так не надо. Потому что среди бесконечного множества вариантов процесса, "как есть" - наихудший (с т.з. формальной логики).
Недавно ломали копья, чтоб контролировать обеспеченность товарами каждой работы, имеющейся в плане. При этом план совершенно невыполним и об этом все знают. Нагородили огород, страшное дело.
Правильное решение сводится к тому, чтобы отказаться от контроля.
Вернее, перенести его в другую точку - на склад. По эффективности такое решение лучше, а по трудоемкости проще на порядки.
Сложность возникает как следствие борьбы со следствиями, а не с их причинами.
По этой причине, сложность изначально закладывается и в конструкцию процессов
+5 ! :)Цитата:
Сообщение от Сахават
Эх, я бы даже не смотрел "как есть" ваш... :)Цитата:
Сообщение от Михаил_Шустер
мне бы - почему ремонт? как ремонт? кто ремонт?... и т.д.
Это не так. Во всех случаях время отсчитывается с момента выполнения первой операции. Действительно, правильнее было бы начинать отсчёт с даты запуска заказа в производство. Но участники игры предоставили для сравнения только диаграммы Гантта, а по ним это однозначно установить невозможно. Что касается моего решения, то такие данные у меня, естественно, есть. Результаты не сильно отличаются от приведенных. Уверяю Вас, что если бы это было по-другому, то некоторые из "проигравших" уже дошли бы до Страсбургского суда.Цитата:
Сообщение от Ark
Условие задачи опубликовано. Никто не заставлял "проигравших" решать не ту задачу.Цитата:
Сообщение от Ark
Это не моя эвристика. Я просто применил в данной задаче алгоритм DBR.Цитата:
Сообщение от Ark
Это решение абсолютно в духе ТОС-приложения "Дистрибуция".Цитата:
Сообщение от Михаил_Шустер
Моя формулировка, которой я пользуюсь: Сложное в исполнении управленческое решение есть результат неправильной постановки задачи менеджерами, что есть результат непонимания системы.Цитата:
Сообщение от Михаил_Шустер
Ваша - короче и яснее. Здорово!
А потому что речь идет о Critical Chain, то есть о составлении расписания с учетом ресурсных ограничений. На укрупненном расписании этого не получится.Цитата:
Сообщение от Михаил_Шустер
Вы еще лагеря вспомните и Беломорканал. Вы это в пример ставите?Цитата:
Сообщение от Михаил_Шустер
Давай ДБР на этот случай. Это самое простое изделие там.Цитата:
Сообщение от Сергей_Жаринов
Евгений, путём заклинаний о "нелокализуемости" узких мест в мелкосерийных и единичных производствах Вам тоже ничего не добиться. Ответ очень простой - Вы ищете не там и не так! Обратитесь к специалистам, и Вам всё разъяснят.Цитата:
Сообщение от air
Путём заклинаний о неприменимости подходов Шухарта и Деминга в мелкосерийных и единичных производствах Вам тоже ничего не добиться. Ответ очень простой - Вы не умеете этого делать! Обратитесь к специалистам, и Вас научат.
Путём заклинаний о неустойчивости движения материального потока в мелкосерийных и единичных производствах Вам тоже ничего не добиться. Ответ очень простой - Вы осознанно вводите в заблуждение слушателей!
Евгений, Вы здесь настойчиво напираете на научность своих рассуждений. Однако ни по одному из перечисленных выше пунктов Вы до сих пор не произнесли ничего, кроме заклинаний.
Например, в вопросе об устойчивости первым делом, - с точки зрения научного подхода, - необходимо было бы дать строгое определение понятия "устойчивость движения материального потока". О чём лично я уже давно прошу. Не устойчивости динамической системы (то есть модели движения потока), а реального процесса. Иными словами, что, как, когда и в каком месте конкретного производства нужно измерить, чтобы это зафиксировать. Евгений, я не думаю, что Вы не понимаете разницу между моделью процесса (например, в виде рассчитанного Вами производственного расписания) и самим реальным процессом. Поэтому когда Вы говорите о том, что "что-то" неустойчиво, потому что сильно отличается от составленного Вами расписания, то лично я это воспринимаю как умышленную подмену понятий. Возьмите другую модель (другой способ составления расписаний) и, возможно, ситуация окажется принципиально иной.
Ну и что? А зачем каждую операцию наносить на диаграмму Гантта? Может во всём цехе есть только 2-3 критических ресурса, которые нужно жёстко контролировать? И тогда диаграмма Гантта вообще не нужна!Цитата:
Сообщение от air
Конечно я утрировал :)Цитата:
Сообщение от Сахават
Вот тут еще одна собака порылась
Ты бы задавал вопросы "под модель" или "под стереотип мышления" (по Рубцову, в хорошем смысле) и в результате обязательно бы "срезал углы" из-за физической невозможности погрузиться в детали.
Будь хоть сто пядей во лбу, эти грабли обойти невозможно. Я на них постоянно натыкаюсь, хотя предметную область вроде прошел вдоль и поперек.
Сахават, я реинжиниринг отрицаю как класс :)Цитата:
Сообщение от Сахават
Я привел пример очень позитивной системы. Она эффективно достигала целей без компьютеров в силу ИНОЙ парадигмы управления.Цитата:
Сообщение от Владимир Либерзон
А упомянутый Рэм Германович-недосягаемый образец руководителя, светлая ему память. И люди - они ведь не за страх работали.
Я же ни в коей мере не отрицаю важности хорошего плана. Пример привел чтобы показать возможность снижения уровня детализации расписания за счет создания ДРУГИХ свойств системы
Разрешите поинтересоваться - почему?Цитата:
Сообщение от Михаил_Шустер
Система не может быть позитивной, если люди трепещут. Она может приводить к результатам, но дорогой ценой.Цитата:
Сообщение от Михаил_Шустер
А что касается детализации расписаний, то необходимая детализация определяется поставленными задачами.
Сахават, я честно просмотрел всю Вашу презентацию. Работа проделана огромная. Меня немного смутил результат, представленный на последнем 23-м слайде (цитирую):Цитата:
Сообщение от Сахават
Меры по расшивке узких мест дали результат: заказ выполнен 15 июля. Возможно, меры по распараллеливанию работ на два станка были избыточны, и достаточно было перевести ОЦ №285 на двухсменный график работ. Ответ на этот вопрос может быть получен дополнительной итерацией моделирования производственного расписания.
Дело в том, что в подобных ситуациях мы поступали по-другому. Без всяких "дополнительных итераций" просто подходили к оператору станка и между нами происходил примерно такой диалог:
- Ты сколько таких деталей можешь сделать за смену?
- Строго по нормочасам - 10 штук!
- А 20 можешь?
- Могу, но нарядов мне напишете на 2 смены! А то потом нормативы порежут!
А в любой системе есть, как минимум, две стороны - довольные и нет...Цитата:
Сообщение от Владимир Либерзон
А при чем здесь довольные?Цитата:
Сообщение от Bend
Да пойми же ты. Это только В ЭТОМ случае ОЦ285 был узким местом. Как только мы его расшили, тут же для этого потока узким местом стал совершенно другой ОЦ в 34 цеху, а если кроме клапана делалось бы еще и сам реактор, то узкое место было бы сооовсем другим и т.д.Цитата:
Сообщение от Сергей_Жаринов
Тут смысл был в том, что бы показать - какие полномочия можно дать проге для расшивки узких мест при заданных ограничениях, а не ходить по цехам и интервюровать всех подряд - а что ты можешь в обход технологии делать? Тут подразумевается, что технология и нормы не обсудаются - госприемка все это уже зафиксировал.
Это как раз при простых решениях (кому то все это обходится очень дорого). А при нормальных решениях должен быть сбалансированный кайф для всех сторон.Цитата:
Сообщение от Bend
Не напрягайтесь, я Ваших текстов не читаю.Цитата:
Сообщение от Сергей_Жаринов
Но активно комментируете:)))Цитата:
Сообщение от air
наблюдаю за текущим внедрением LP в СБ РФ, и думаю как раз об этом - что может получиться у Германа Оскоровича в условиях тотальной ненависти и презрения со стороны собственных сотрудников к нему лично и соответственно ко всем его начинаниям? Как совместить ненависть и необходимость не то, чтобы просто исполнить инструкцию, а проникнуться самим Духом такого отношения к своей работе? О чём думает человек? И думает ли? И человек ли?...Цитата:
Сообщение от Владимир Либерзон
Пример. Проще некуда. Я им пользуюсь на моих семинарах.Цитата:
Сообщение от Георгий Лейбович
Обычная гайка - это шестигранная призма с дыркой и резьбой.
Диски автомобильных колес прикручиваются к ступице конусными гайками. Конусная гайка - такая шестигранная призма, у которой одно основание - не плоскость, а конус. Такой же конус - у отверстия диска.
Такая конструкция крепления позволяет центрировать диски колес по оси вращения.
Существует возможность прикрутить колесо, наворачивая гайки конусом наружу. Мой личный автомастер рассказывал, что периодически попадаются нерадивые автолюбители, у которых колеса так прикручены.
То есть нужен дополнительный контроль правильности прикручивания гаек.
Меняем конструкцию конусной гайки: делаем второе основание глухим.
Теперь гайку нельзя закрутить неправильно.
То есть необходимость в дополнительной суете вокруг возможности неправильного закручивания просто пропадает.
Устранена причина, и нежелательные следствия исчезли.
Рискну перефразировать Жванецкого: что бы человек ни делал, он упорно ползет на грабли.Цитата:
Сообщение от Михаил_Шустер
Зачем?
1. Мыслительный процесс должен быть групповым.
2. Группа должна включать реальных носителей деталей.
3. Задача модератора, супервайзера, спикера - организовать всплытие деталей из мозгов участников наружу, на общее обозрение.
Разве не об этом Thinking Process Голдратта, например, в изложении Детмера?
А Вы уверены, Евгений, что самостоятельно изменив конструкцию (т.е. превратив конусную гайку в обычную плоскую) Вы за счет этого "упрощения" не снизили надежность крепления?Цитата:
Сообщение от Евгений_Кс
"Простота хуже воровства" (с) А.Н.Островский :) :) :)
Евгений, Вы не поняли. Конус оставляем, а другую сторону закрываем. Чтобы другой стороной нельзя было в принципе закрутить. Одновременно закрываем доступ к резьбе песка и грязи :)Цитата:
Сообщение от air
И почему "самостоятельно"?
Это спорный тезис. Тогда следует предположить, что любой сложный маневр является ошибкой его исполнителя. Но на практике часто встречаются ситуации, когда только за счет сложного маневрирования (управления) можно выйти на желаемый результат.Цитата:
Сообщение от Георгий Лейбович
Пример: для того, чтобы плыть на парусном судне в нужном направлении (а не туда, куда дует ветер) необходимо совершать весьма сложный маневр как парусом, так и рулем этого судна.
Любое изделие, в частности, упомянутая Вами гайка при изготовлении должна удовлетворять так называемым требованиям технологичности. Т.е. возможности ее просто изготовить (а заготовкой для них является шестигранный пруток, закрепленный в специальный кулачковый патрон на токарно-винторезном станке) без дополнительной смены технологических баз (т.е. без переустанова). Похоже, Евгений, что предложенная Вами доработка каждой гайки выйдет за рамки требований на ее технологичность. Такие конструкции, увы, бракуются на этапе технологической подготовки производства. Эта процедура мне очень хорошо известна, уж поверьте. :)Цитата:
Сообщение от Евгений_Кс
Так что Александр Николаевич Островский во многом был прав! :)
1. Ваши комментарии к моему примеру поразительны. Неужели Вы без станков мыслить не можете? Сергей, как я Вас понимаю :)Цитата:
Сообщение от air
2. Не следует манипулировать пословицами. Правильный вариант - "иная простота хуже воровства". Полный вариант - "иная простота хуже воровства, но с простака и взятка гладка". :)
Не вспоминайте его, пожалуйста, - он, на мой взгляд, давно перешел грань приличий в обращении ко мне, - грань, за которой следует обычное хамство. Если Вы его именуете "простаком", то мне вспоминается дополнение к сказанному выше:Цитата:
Сообщение от Евгений_Кс
"Но простакам любая слава, что масло к каше" ...
Ольга, я об этом раньше "выписался", неохота возвращатьсяЦитата:
Сообщение от Ольга Кряжич
В двух словах - крайне вредны любые попытки "натянуть предприятие на готовое решение". Во первых это невозможно. Во вторых, априори удачных решений не бывает.
Систему управления нужно зачать, выносить, родить, воспитать... это естественный путь. Все остальное - от лукавага. Включая ERP
Имхо, разумеется :)