Роман Пантелеев пишет:
Александр Вы не правы - дерево нельзя на 180 градусов перевертывать. Туча поворачивается на 90 градусов. И там логика нормально работает, так как даже проверка тучи формулируется как: Для того чтобы А мы должны иметь В. Для того чтобы В мы должны делать D. Т.е. именно цель является причиной для важной потребности В. Именно В является причиной для того чтобы делать D.

И вишенка на торте - именно цель А вызывает проблему. Не будь такой цели - все CRT разрушится. Так мы и получаем что часто именно не верная цель вызывает кучу остальных проблем (пример "выпустить ХХХ млн.шт."). Работая с тучей топы часто меняют формулировку цели. А если цель правильная - тогда уже и возникают неверные исходные посылки, которые держат существование конфликта.

PS хотя любая не правильная цель является следствием неверных исходных посылок у системы, ставящей цель.

90, 180… Это уже как голову наклонить. 180 - брал за основу рисунки 8, 9, 10... IOM Деттмера-Георгия Лейбовича здесь .

Во всем остальном - наши позиции совпадают.

Роман Пантелеев пишет: По идее вся мысль укладывается в 4 блока:
"КиПД не гарантируют устранения причин несоответствия" и причина этого: "КиПД разрабатывается экспертно" И "Экспертные методы без проверки дают низкую вероятность нахождения правильных причин" И "Отсутствует практика проверки..."

У меня получилась такая диаграмма

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

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

Все понял, со всем согласен. Спасибо.

Роман Пантелеев пишет: ...
Александр Вы не правы - дерево нельзя на 180 градусов перевертывать. Туча поворачивается на 90 градусов. И там логика нормально работает, так как даже проверка тучи формулируется как: Для того чтобы А мы должны иметь В. Для того чтобы В мы должны делать D. Т.е. именно цель является причиной для важной потребности В. Именно В является причиной для того чтобы делать D.

И вишенка на торте - именно цель А вызывает проблему. Не будь такой цели - все CRT разрушится. Так мы и получаем что часто именно не верная цель вызывает кучу остальных проблем (пример "выпустить ХХХ млн.шт."). Работая с тучей топы часто меняют формулировку цели. А если цель правильная - тогда уже и возникают неверные исходные посылки, которые держат существование конфликта.

PS хотя любая не правильная цель является следствием неверных исходных посылок у системы, ставящей цель.

Роман, что здесь понимается под А, какая Цель? Хочу на всякий случай уточнить, прежде чем...

Роман Пантелеев пишет: И это просто cause & effects. Причинно-следственные связи. Это не CRT. Нет конфликта в корне.

Если поставлена цель провести анализ функций системы с использованием нежелательных явлений,, то нет необходимость выявлять причинно-следственные связи между ними.
С другой стороны, посстртоение пичинно-следственной диаграммы, связывающей НЖЯ позволяет установить логические связи между НЖЯ, восстановить пропущенные связи

(пока жду ответ от Романа)
Александр, мне кажется, что Вам полезно было бы перед и для построения причинных деревьев, претендующих на "не-получилось" (боюсь их назвать ДТР), строить сперва вариант "получилось" (типа IOM) то, что нужно, и строить по указанным Вами правилам, если это не IOM; то есть, что нужно, чтобы получилось, и что выходит, когда не получается. Тогда, во-первых, легче понять Вам самому и разобрать вместе ошибки, если они есть, и во-вторых, Вам будет некуда деваться. Хотя, конечно, с последним я излишне оптимистичен, но всё-таки.

Роман, или срочно исправляйте свой опус об отношениях A-B-D (цели и условий), или этим займусь я. Подсказки: 1) Цель не может поменяться в результате вращений картинки и стать причиной, она может стать причиной поиска, то есть действия, не входящего в деревья, 2) постановка Цели приводит к появлению НУ в планах, но НУ ведут к реализации, достижению Цели, что отражается в деревьях. Перепутать эти два разнонаправленных процесса - грубая ошибка логики, но, к сожалению, с ней довольно часто приходится встречаться. Это фатальная логическая ошибка! Я Вам твержу об этом не первый год, и вот опять... Либо надо отбросить термин "логика" и говорить о манипуляциях с "деревьями" как об эмпирическом инструменте, аналогичном правилам большого пальца, которые часто срабатывают. И тогда - никаких претензий, кроме как от пострадавших.

Александр Запорожцев пишет: ...
Если поставлена цель провести анализ функций системы с использованием нежелательных явлений,, то нет необходимость выявлять причинно-следственные связи между ними. ...

Что за абракадабра?

Георгий Лейбович пишет: Александр, мне кажется, что Вам полезно было бы перед и для построения причинных деревьев, претендующих на "не-получилось" (боюсь их назвать ДТР), строить сперва вариант "получилось" (типа IOM) то, что нужно

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

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

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

Если какая то 'функция' не выполняется, то это 'ограничение'. Не так ли?

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

То ли не проверяется соответствие входа требованиям, то ли требования 'кривые', то ли действия 'кривые', то ли действия худо бедно нормальные, да устраняя одни недостатки (несоответствия) вызывают другие и тд.

Какая функция не выполняется? Какой 'СХ' ответственнен за выполнение этой 'функции'? Это Вы хотите?

Называйте функцию, которая не выполняется и СХ.

Go ahead.

Александр Филонов пишет:
Если какая то 'функция' не выполняется, то это 'ограничение'. Не так ли? Некорректное утверждение - если в функциональной модели выявлена определенная функция, то это означает, что выполнение этой функции или регламентом или реальной практикой. Для исключения таких утверждений примем, что модель прошла процесс согласования с экспертами - это стандартная процедура SADT технологии. По поводу ограничения - этого термина в системной инженерии нет

Вы не знаете, что у вас не выполняется в процессе 'который нужно модернизировать'. Зато мы знаем, что выполняется

То ли не проверяется соответствие входа требованиям, то ли требования 'кривые', то ли действия 'кривые', то ли действия худо бедно нормальные, да устраняя одни недостатки (несоответствия) вызывают другие и тд. Мы рассматриваем те требования, которые появляются только в процессе модернизации системы

Какая функция не выполняется? В модели "как есть" все функции выполняются в соответствии с регламентом выполнения функции

Какой 'СХ' ответственнен за выполнение этой 'функции'? Это Вы хотите? Каждую функцию выполняет персонал и правильное выполнение функции образует понятие стейкхолдер - роль в деятельности. Например, оператор - ели функция описывает производство изделия на станке, менеджер, если это управленческая функция.

Называйте функцию, которая не выполняется и СХ. Каждую функцию выполняет свой стейкхолдер

Go ahead.