Георгий Лейбович пишет: пока отменил
Нет, зря отменил

Когда Георгий Лейбович появляется "НА САЙТE" я все время жду, возникнет (emerge) что-нибудь или нет.

Нет, не возникло.

Emergency - "unforeseen occurrence requiring immediate attention".

В свете "урезания" и "копать" ( dig , digital, fig, sense..) Романа Пантелеева , человек - прототип реальности, с наиболее "урезанными" и "ограниченными" свойствами (constraints)

"Потяжелела ветка" - это проявление G силы тяжести, гравитационной постоянной, константы, которая в категоризации Meadows находится в нижнем уровне атаки. Смена парадигм - Impedance (Z) - в верхнем.

Вывод:

Константа - усеченная переменная. '



PS Атомная бомба всегда падает в эпицентр взрыва. Аум . (См пп 6 и 7 Meadows )

Дмитрий Стукалов пишет: В самом деле! Давайте фундаментальные основы ТОС в отдельную ветку! Я уже и так опасаюсь, что придет Евгений Ксенчук и обвинит участников обсуждения в том, что они посмели побить рекорд его самой длинной до поры темы о системном мышлении...
Ром, сможешь запустить новое обсуждение?

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

Сергей Жаринов пишет: Ну и вишенка на торте в виде слова "likely". Правда, бывает ещё "highly likely", но хрен редьки не слаще.
P.S. Хорошо ещё, что Вы не настаиваете на загрузке в 70 или 80 процентов.

Я не могу комментировать словарь TOCICO, так как не общался ни с одним из авторов по этой теме. Могу только сказать, что он не противоречит по сути определениям данным Еленой и Одедом, но в словаре мне не хватает конкретики определений Елены и Одеда.
Главный вопрос - зачем нам иметь столько определений: constraint, bottleneck, CCR, non-CCR. Становится это понятно из областей их применения. (пишу собственное понимание).

Constraint - это термин имеющий отношение к системе в целом. Constraint - это то, добавление чего моментально положительно сказывается на результате системы. Точка прямого влияния на результат при добавлении Constraint.
Constraint используется в 5 фокусирующих шагах, а так же для выбора стратегии подчинения (не упускать ни одного клиента, зарабатывать максимум на времени ресурса и т.д.). Constraint может мигрировать из-за сезонности - это вызывает разную стратегию поведения в низкий и высокий сезон. Например в высокий сезон T/CU считается по отношению к ограниченной мощности, а в низкий по отношению к деньгам (или объему склада - в зависимости что является в этот момент ограничением).

Bottleneck - ресурс, работающий 24 часа 7 дней в неделю 365 дней (или минус праздники, общезаводские каникулы) в году. bottleneck всегда является Capacity Constraint, так как идеально сбалансировать спрос с мощностями не возможно - постоянно работающий ресурс не позволяет обслуживать весь спрос, проходящий через него. Понимание бутылочного горлышка (оно же узкое место) было стартовым моментом в создании OPT, а позднее привело к созданию теории ограничений. В то время термин constraint не использовался, использовалось бутылочное горлышко. Но когда случился нефтяной кризис 80-х бутылочные горлышки стали пропадать. Тогда Голдратт стал анализировать ситуацию и ввел термин constraint, который покрывал нехватку заказов (Market Constraint).

CCR - ресурс с ограниченной мощностью, загруженный более 70% времени (величину беру из опыта и определения Одеда и Елены). Поскольку в системе всегда присутствует вариабельность - ресурсы, имеющие недостаточную защитную мощность периодически будут становиться краткосрочным бутылочным горлышком. С определенной величины загрузки эта ситуация становится радикально частой, что не позволяет буферу эффективно защищать реальное бутылочное горлышко, которое в итоге может простоять. Если же бутылочного горлышка - нет, то CCR становится очень похожим по функционалу из-за частых превращений в локальное бутылочное горлышко. Ограниченность защитной мощности заставляет относиться к ресурсу иначе чем к non-CCR ресурсам. Он требует внимания, персонального управления и защиты. В 7-ой инъекции раздела POOGI решений MTO и MTA вводится постоянный контроль за CCR ресурсами. Так как в любой момент такой ресурс может превратиться в ограничение, что должно вызвать корректирующие воздействия, препятствующие перемещению текущего ограничения или появления двух интерактивных ограничений. Как рекомендуют эксперты-практики TOC ограничение при развертывании решений MTO/MTA не рекомендуется загружать более 80%, т.е. фактически мы получаем ситуацию CCR. Bottleneck так же является CCR - по определению. Понятие CCR используется в реализации DBR - для CCR необходимо составлять расписание и защищать его буфером. Анализ неудавшейся попытки управлять проектами через DBR привел к появлению еще одного типа ограничения Time Constraint, а позже к специальному решению для управления проектами - CCPM.

non-CCR - прочие ресурсы не требующие составления расписаний, особого внимания и защиты.

Примерно параллельно с появлением Time Constraint появился еще один тип ограничений Policy Constraint - как реакция на тот факт что анализ реальных систем показывал, что ни CCR, ни рынок не ограничивали напрямую результаты системы. Всегда существовали политики, которые "разбазаривали" то или иное. Ответом на явные проявления этих политик был 2 и 3 шаг в 5 фокусирующих шагах. Однако быстро пришло осознание, что политики не являются ограничением - они были лишь препятствием к максимальному использованию реальных ограничений. В итоге это вызвало появление мощнейшего инструментария Thinking Processes для работы с этими препятствиями. Современный консалтинг по TOC - это работа в области мыслительных процессов или развертывание логистических решений, разработанных и структурированных с помощью мыслительных процессов ТОС.

Роман Пантелеев пишет: Я не могу комментировать словарь TOCICO, так как не общался ни с одним из авторов по этой теме. Могу только сказать, что он не противоречит по сути определениям данным Еленой и Одедом, но в словаре мне не хватает конкретики определений Елены и Одеда. ...

Роман, если две некорректные формулировки не противоречат друг другу, то пользы всё равно нет ни от той ни от другой. Я же даже не про содержание написал в предыдущем посте, а про форму. Приведенное Вами определение не является определением по определению определения (прошу прощения за каламбур). Это просто набор слов, не несущий никакой смысловой нагрузки.

P.S. По сути отпишусь позднее.

По поводу продолжения обсуждения в данной ветке:
1. цель обсуждения не достигнута - нет совместной позиции об отношении использования логических инструментов ТОС и диаграмм системной динамики - в каких случаях нужно использовать инструменты ТОС и когда использовать подход системной динамики
2. дискуссия сводиться к обсуждению частных точек зрения, а чаще всего к обсуждению ошибок в высказываниях
3. за три года многое изменилось (в моем представлении) и вопрос уже стоит шире - как разобраться в существующих системных подходах и определить, когда и какие подходы целесообразно использовать.
Предложение - данную ветку закрыть, а продолжить дискуссию в новой ветке с конкретной целью обсуждения - Использование современных системных подходов в управлении.
Как вариант - ветку не закрывать и оставить ее для тех, кто имеет интерес к продолжению дискуссии.

Сергей Жаринов пишет:

Роман Пантелеев пишет: Я не могу комментировать словарь TOCICO, так как не общался ни с одним из авторов по этой теме. Могу только сказать, что он не противоречит по сути определениям данным Еленой и Одедом, но в словаре мне не хватает конкретики определений Елены и Одеда. ...

Роман, если две некорректные формулировки не противоречат друг другу, то пользы всё равно нет ни от той ни от другой. Я же даже не про содержание написал в предыдущем посте, а про форму. Приведенное Вами определение не является определением по определению определения (прошу прощения за каламбур). Это просто набор слов, не несущий никакой смысловой нагрузки.

P.S. По сути отпишусь позднее.

Сергей, во-первых Георгий просил дать свое понимание терминов, а не махать флажками "определение". Во-вторых смысл всегда внутри источника и приемника - в тексте смысла - нет. Если я описываю взгляд на ТОС, в большинстве своем сформированный на основе парадигмы привитой мне Одедом (первый директор Goldratt School London) и Еленой и последующей моей практикой, с проверкой этого понимания сдачей fundamentals в TOCICO, и никогда не скрываю откуда у меня информация. То Вы почему то постоянно машете флажком "операциональный" и по видимому считаете, что кроме Вашего опыта все остальное неправильно. Заметьте, что я не пытаюсь как то принизить Ваш опыт. Единственное пытаюсь указать, что он не равен классическому TOC, разработанному Голдраттом и развиваемый его соратниками. В рамках своего опыта Вы можете ввести любые определения и успешно ими пользоваться, только несколько странно на основании них опровергать чужие, выработанные многолетней практикой. Также не корректно выдавать свои определения за определения дисциплины, которую Вы не создавали и не развивали. Можно попытаться совместить Ваш опыт с опытом людей создавших и развивавших ТОС и улучшить общие формулировки, но вряд ли стоит это делать в рамках этой ветки - тем более эти люди здесь не присутствуют. Я же пока не возьмусь менять классические формулировки ТОС по своему разумению.

Александр Запорожцев пишет: По поводу продолжения обсуждения в данной ветке:
1. цель обсуждения не достигнута - нет совместной позиции об отношении использования логических инструментов ТОС и диаграмм системной динамики - в каких случаях нужно использовать инструменты ТОС и когда использовать подход системной динамики

Недавно Apple Consulting упоминали, что Goldratt Consulting (Rami Goldratt) сейчас используют не деревья, а петли обратной связи. К сожалению подробностей не удалось выяснить

Роман Пантелеев пишет: Недавно Apple Consulting упоминали, что Goldratt Consulting (Rami Goldratt) сейчас используют не деревья, а петли обратной связи. К сожалению подробностей не удалось выяснить

Это интересно!

Роман Пантелеев пишет: ... Я же пока не возьмусь менять классические формулировки ТОС по своему разумению.

Хорошо, Роман! Вы не готовы ничего менять и будете продолжать пользоваться тем, что называете классическими формулировками. Мне кажется, это отдаёт инерцией (надеюсь, я правильное слово употребляю), но это моё личное мнение. В таком случае не могли бы Вы разъяснить мне смысл хотя бы того "классического" определения CCR, которое привели? Я даже ветку специальную открою сам.

P.S. Мне кажется, у меня неплохой бэкграунд в этих вопросах. Я нахожусь в теме примерно 20 лет, из которых последние 12 занимаюсь разработкой методик и программных средств управления производством на основе принципов ТОС. Так что есть шансы понять Ваши разъяснения.