Георгий Лейбович пишет: Замечу ещё раз, что построив объект «организация», мы воспринимаем/моделируем те его проявления, которые можем воспринять, и которые нас интересуют. Их мы называем свойствами организации и включаем в описание её модели, которая может быть системой или нет в зависимости от того, что нас интересует. Далее будем говорить о системной модели организации, или для простоты, об организации..

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

Александр Запорожцев пишет:

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

В первой фразе утверждается, что рассматривается организация (реальная) и для нее строятся модели. Во второй фразе утверждается, что построение основано на установление связей между элементами модели. - А дальше написано, что элементами модели являются свойства, приписываемые наблюдателем организации, и это является частью процесса моделирования. Ехал Грека через реку, ...
Вопросы:
откуда появляются элементы модели? - из наблюдения (опыта, опросов, книжек)
как можно устанавливать связи между тем, что еще не выявлено? - в данном случае это не требуется. Или Вы о бозоне Хиггса?
почему рассматриваются только логические связи? - другие связи - для других площадок А если серьёзно, то основанные на логике необходимости или логике длстаточности, что соответствует задаче построения рассмотренных моделей. Ничего личного
как связаны элементы организации с элементами модели? - какие? Это не отговорка, подумайте.
Мне было бы понятнее, если бы между первым и вторым утверждением появилось описание того, как строиться модель. Например такая фраза - Для реальной организации определяется список НЖЯ, анализируя причины этих НЖЯ определяется корневая причина их проявления. Не претендую на правильность этого утверждения, но оно позволяет уточнить второе утверждение: элементами модели являются утверждения о явлениях, наблюдаемых в организации, а не элементы самой организации ???. - уже ясно, что сами с собой боретесь?
Например, утверждение "Нарушаются сроки поставки продукции клиентам" позволяет понять, что организация поставляет продукцию клиентам и это относиться к описанию организации. Однако достаточного полного описания организации, чтобы судить о том, как производиться поставка продукции не дано. Утверждения, в которых будут указаны причины того, что сроки поставки нарушаются, возможно дадут дополнительную информацию о системе поставок, но если причина срыва сроков поставок будет в чем то другом, а не в самой системе поставок, то мы не узнаем как работает система поставок. - ничего не понял. Вы хотите произволственный роман?
Резюме: хотелось бы более точного определения того, как строиться модель с использованием логического процесса. -То есть, Вы утверждаете, что сами не в состоянии понять, что пишет Деттмер о построении? И имейте в виду, что все осмысленные НЖЯ - неработающие свойства тех или иных уровней (это моё утверждение).

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

Георгий Лейбович пишет: Вы, конечно, спрашивайте, но сперва старайтесь найти ответ в тексте, так как большинство вопросов я предполагаю, когда пишу (поэтому иногда получается довольно пространно).[/color]

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

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

Пока рядом не появится "деревянная модель мотоцикла" рядом с "Harley-Davidson" - вперед мы не продеремся.

1) "Деревянная модель" - это "модель контекста" у Запорожцева. Элементами у нее являются деревяшки. Запорожцев предлагает называть деревяшки - "утверждениями".

2) У Георгия:

ДТР - это модель. Элементами у нее являются "свойства". Другое название у этих элементов-свойств - "функция".
КПЦ - это модель. Элементами у нее являются "свойства". Другое название у этих элементов-свойств - "функция".

З) Запорожцев не согласен с тем, как называются элементы в моделях ДТР и КПЦ в моделях Георгия. И предлагает переименовать элементы. Называть их не "свойство", а "утверждение".

Тогда, поставив рядом с деревянной моделью настоящий Harley Davidson - он сможет связать "утверждения" (элементы в деревянной модели) с "свойствами" (элементами реальной организации), (назовем ее HD).

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

Александр Запорожцев считает, что "контекст" неизвестен работникам предприятия, и косвенным подтверждением этого является построение ими модели КПЦ, (карты промежуточных целей).

Как бы на его языке это объяснить...? -

КПЦ - это иерархия "холонов".

Внизу - "обеспечивающая система", посередине - "целевая", вверху - "окружающая среда".

Георгий Лейбович пишет: 4. Карта Промежуточных Целей. Графическое представление Цели системы, Ключевых факторов успеха и Необходимых условий, логически связанных в иерархическую структуру, с Целью в верхней части. Каждый элемент структуры связан условием необходимости с нижележащими элементами. То есть, для существования вышележащего элемента (и выше в иерархии) необходим нижележащий элемент (-ты).
Эта карта отражает те системные (и их иерархические составляющие) свойства и их состояния, которые необходимы для того, чтобы организация могла достигнуть цель. Эта карта служит для сравнения того, что есть, с тем, что должно быть, чтобы прийти к цели. Соединяющие стрелки представляют совокупность представлений о том, как системные уровни влияют или, скорее, должны влиять друг на друга.
Таким образом, эта карта представляет собой
1) статическую системную модель организации,
2) представленную (и ограниченную) верхними иерархическими уровнями свойств системы и подсистем,
3) соединённых связями, основанными на логике необходимости,
4) где необходимо, добавлены элементы, отражающие влияние окружающей среды,
5) если с течением времени меняется причинность или элементы, то эти изменения должны вноситься в карту. Карта всегда должна быть эталоном сравнения на конкретный момент построения, и это принципиально важно.

Раз уж инструмент упомянут опять по-задаю вопросы по нему.
1. Intermediate objective map - objective==задач?
2. Каждый бокс дерева должен содержать абстрактные или предельно конкретные формулировки Goal, CSF или NC? Предельно конкретные я имею ввиду с числовым значением показателя и указанием периода.
2.1 Если мы используем предельно конкретные формулировки логика достаточности будет работать, но не будет работать логика необходимости, так как высшего уровня можно достичь с помощью других значений показателя.
2.2 Если мы используем абстрактные формулировки - с логикой будет все хорошо, но плохо с возможностью отслеживать выполнение задач (целей).
3. Если мы используем инструмент (там для чего он был придуман) для описания реализации каких то изменений как последовательности взаимозависимых задач, то все хорошо с логикой и с отслеживанием выполнения.

Александр Филонов пишет: КПЦ - это иерархия "холонов".

Внизу - "обеспечивающая система", посередине - "целевая", вверху - "окружающая среда".

Это должна быть иерархия холонов, но инструмент не позволяет ее описывать. Каждый objective может быть либо Done, либо ещё нет. Чтобы прочекать выполнение задачи-цели - необходимо иметь ее численное определение. Как только мы ее численно зафиксируем - мы попадаем в конфликт «следовать цели» или «реагировать на меняющиеся обстоятельства». Поэтому инструмент работает только с задачами, вариант исполнения которых является свободным (встретив препятствия, меняем поведение). Дерево же целей убивает свободу и в итоге само является хрупким.

Роман, спасибр за конкретные формулировки вопросов. Отвечу более подробно позже, но пока Вам на подумать:
1. Именно цели - свойства подсистем, обеспечивающие работающие свойства системы, необходимые для достижения её цели.
2. Я написал, что должен содержать "каждый бокс". Полистайте литературу.
Это не составление плана, не путайте жанры.
3. Вы знаете какую-то скрытую цель КПЦ кроме той, что я привёл? Роман, чтобы отследить невыполнение плана не нужно огород городить с ЛП. Взяли план и проверили выполнение. Задача ЛП найти почему не выполняется. А не выполняется потому, что в силу каких-то причин не работают предусмотренным образом функции (можно и по Филонову).
В разное время метрики, отражающие работу функций, будут принимать разные значения, но важно, выполняют ли они целевую функцию - обеспечение свойств-функцмй более высоеого уровня.
Проблема Вашего восприятия в нежелании принять дедуктивный путь построения ДТР по цепочке свойств. Если Вы ищете неработающее свойство, то какие, к чёрту, показатели в "боксах", если их надо сперва найти или, хотя бы, связать через НЖЯ?
Роман, Вы можете разобраться, только надо снять блокировку. Может, более подробно и не понадобится?
Надеюсь, что уже ответил и на ошибочный последний пост?

Александр, с Романом мы разговариваем на разных диалектах, но одного языка С Вами - труднее. У Вас одна из основных проблем - здесь: Я привык сначала моделировать то, что наблюдается в реальности в виде физических объектов и только после этого анализировать как поведет себя такая система - какие у нее будут свойства. Вы, когда моделируете, УЖЕ включаете предполагаемые и отбираемые свойства объекта в модель.

Георгий Лейбович пишет: Александр, с Романом мы разговариваем на разных диалектах, но одного языка С Вами - труднее. У Вас одна из основных проблем - здесь: Я привык сначала моделировать то, что наблюдается в реальности в виде физических объектов и только после этого анализировать как поведет себя такая система - какие у нее будут свойства. Вы, когда моделируете, УЖЕ включаете предполагаемые и отбираемые свойства объекта в модель.

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

Ещё небольшой шаг - как мне кажется, мостик к продолжению (которого пока нет).
Что такое Нежелательное явление, если не брать в расчёт мелкую чепуху? Это неработающее свойство/функция на некотором уровне. Почему не можем взять и исправить? В силу системности этого свойства. Оно обусловлено свойствами нижних уровней. И дальше возможны два варианта: 1) "сломано" нижележащее свойство или 2) ниже - всё в порядке, но по какой-то причине неверна структура связей. Например, как часто говорят, проблема в старых решениях [создавших структуру], ставших со временем тормозом. Мы бы и рады запустить изменение, а 1) или 2) - не дают. Улучшим за счёт ухудшения другого свойства. И только добравшись до НЖЯ из 2) мы получаем шанс на надёжное улучшение.
Ещё есть вариант, что просто нашли "испорченное" свойство, которое можно просто взять и исправить (отрегулировать), не трогая остальное. Это, конечно, предпочтительный вариант, но менее интересный для пытливого ума

Георгий Лейбович пишет: Что такое Нежелательное явление, если не брать в расчёт мелкую чепуху? Это неработающее свойство/функция на некотором уровне. Почему не можем взять и исправить? В силу системности этого свойства. Оно обусловлено свойствами нижних уровней.

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