Александр, само собой. Кто иного утверждает? Я лишь говорю что чтобы изучать реальность нужен предметный опыт у консультанта или эксперта из области. Вы как консультант не можете предложить 10 лет пожить в компании и наработать личный опыт - Вы должны его взять у кого то. Проверить факты Вы должны и можете, но первоначально информация берётся от людей. Если у человека нет опыта он будет рассказывать Вам только stories.

PS До viable vision Голдратт запрещал создавать типовые решения. Потом пришёл предметный опыт и осознание что на уровне стейкхолдера можно и нужно сразу строить систему правильно. И да есть ньюансы, но я не буду сейчас в них погружаться

Вспомнил про довольно старую, но интересную статью Деттмера о ТР. Её можно найти по ссылке deming.ru/Praktika/GL/PrimLogProc/PrimLogProc.htm
Там косвенно затрагиваются и некоторые обсуждаемые вопросы.

Георгий Лейбович пишет: Вспомнил про довольно старую, но интересную статью Деттмера о ТР

Это единственная статья (из тех, что я прочел), в которой обсуждаются вопросы анализа системы при использовании ТР.
Хотел бы обратить внимание Романа на то, что в статье автор делает акцент на проблеме получения знаний, на основе которых можно строить логические деревья. Деттмер пишет "Наилучшим источником знания для анализа методом ТР являются люди, тесно связанные с работой или проблемой".
Вторым аспектом, я бы выделил следующие слова "Первое, что нужно, это разобраться с ожиданиями клиента относительно того, что должно быть достигнуто". Без стейкхолдеров - никуда!. Группа аналитиков, которая пригласила Деттмер в проект, сильно ошиблась в сроках проведения анализа (наверно тоже считала свой опыт достаточным).
Но по этой статье у меня есть два существенных замечания:
1. ДТР из 150 элементов - это запредельная цифра. Прежде всего потому, что в 20 раз превышает способность человека удерживать в сознании информацию об объектах. В SADT эта проблема решена тем, что на одной диаграмме не должно быть больше 6 функций. Полная SADT модель образуется из необходимого числа таких диаграмм. Это позволяет создавать модели, в которых можно описать более 1000 функций. При построении ДТР невозможно использовать напрямую рекомендации SADT, но это очень сильно ограничивает применение ТР.
2. Сбор информации о системе и фиксирование результатов такого анализа никак в ТР не регламентируется, а это существенный недостаток данного подхода. Специалисты уже дано поняли, что без фиксации результатов анализа системы в наглядной форме понятной аналитику и эксперту добиться общего понимания системы невозможно - каждый будет говорить о своем. Наглядная модель позволяет свести эти разные видения к одному образу.
Мне кажется, что эти две проблемы ТР требуют своего решения.

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

Георгий, кроме окон Johari ничего нового для себя не увидел. Меня с первого обучения в Таллине этому Елена с Одедом учили. Как видите я безуспешно пытался донести тоже самое до Александра. А вот про стратегию в статье интересно, но конкретики нет. 6 человек собрались и по быстрому настратегировали. Я все же не пойму - пример IOM обучающий или Деттмер предлагает уйти от стратегических показателей и оставить только направления?

Роман Пантелеев пишет: А протокол проверки информации есть - CLR называется.

Критерии проверки правильности логических построений используется только для проверки правильности ДТР, но эти критерии никак не могут помочь на этапе сбора данных о системе.

Александр, зачем Вы сбор информации отделяете от построения CRT?! Построение CRT и есть сбор информации о системе! Оторвитесь уже от пуповины системной динамики. CRT - это сбор и анализ системы, это НЕ МОДЕЛИРОВАНИЕ. Где тут иконка бьющейся головы о стену???

PS Ладно моделирование, но такого же сорта как посчитать количество остатков на складе.

Роман Пантелеев пишет: CRT - это сбор и анализ системы, это НЕ МОДЕЛИРОВАНИЕ.
PS Ладно моделирование, но такого же сорта как посчитать количество остатков на складе.

Любая диаграмма, отражающая свойства системы является МОДЕЛЬЮ системы. Основное назначение модели - отвечать на вопросы, относительно системы. ДТР разрабатывается для того, чтобы ответить на основной вопрос - "Какова основная причина нежелательных явлений в системе, которые мешают ей достичь лучших результатов деятельности." Так как вопрос касается причин, то такая модель строиться в виде причинно-следственных связей между явлениями, происходящими в реальности. Построение любой модели системы основывается на информации о системе. Наилучшим источником информации о системе являются эксперты. Но для подготовки к разговору с экспертом аналитик должен предварительно собрать достаточно информации о системе. Это поможет аналитику лучше понять систему и быстрее получить от эксперта важную информацию. Существует несколько способов получение предварительной информации: чтение нормативной документации о системе, наблюдение за выполнением операций, анкетирование, использование собственных знаний.
Основными элементами модели ДТР является утверждения и причинно-следственные связи между утверждениями. В утверждении формулируется некоторое знание об объектах системы (факты), а причинно-следственные связи представляют другой вид знаний о системе - взаимодействие между объектами системы.
Таким образом, ДТР является одной из разновидностей моделей систем. Общая проблема моделирования - получение достоверной информации о системе и отражение этой информации в виде модели.

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

Роман, я не собираюсь Вас в ни в чем переубеждать. Вашу точку зрения по моим рассуждениям, я услышал. Если у Вас нет идей по поводу моделирования системы перед тем как применять ТР, то на нет и суда нет.