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

Роман Пантелеев пишет: Но чтобы брать реальную организацию и ее моделировать - у меня нет понимания какими формулами наполнять модель. Может одна переменная растет быстрее или растет с провалами относительно другой?

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

Тогда СД не позволяет "посчитать", а лишь "оценить". То же самое позволяет дерево ТОС...

Роман Пантелеев пишет: Коэффициент на основе статистики прошлого месяца?

Для начала пойдет, затем можно посмотреть, что измениться если этот коэффициент изменить. Будет интересно и наглядно!

Т.е. если у меня нет статистики - я не могу двигаться в СД дальше...

Роман Пантелеев пишет: Тогда СД не позволяет "посчитать", а лишь "оценить". То же самое позволяет дерево ТОС...

при использовании СД вы будете оценивать "ПОВЕДЕНИЕ" - изменение во времени важных показателей. А что вы оцениваете в ТОС? Насколько убедительной получилась диаграмма причин и следствий и согласны ли с ней работники предприятия. Но никаких данных о поведении основных показателей.

Роман Пантелеев пишет: Т.е. если у меня нет статистики - я не могу двигаться в СД дальше...

Делите объем выпуска на объем партий обработки, требующих переналадки = число перекладинок. Время переналадки известно - определяете показатель. Все это детально рассмотрено в учебника по БП

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

Роман Пантелеев пишет: Т.е. если у меня нет статистики - я не могу двигаться в СД дальше...

Делите объем выпуска на объем партий обработки, требующих переналадки = число перекладинок. Время переналадки известно - определяете показатель. Все это детально рассмотрено в учебника по БП

Переналадка от 1 до 4 часов (распределение не линейно, смещено в сторону 1). Количество переналадок не известно пока она не потребуется по факту. Объем партии обработки колеблется в зависимости от потребности. По статистике количество переналадок от 1 до 4 в сутки.

Роман Пантелеев пишет: Переналадка от 1 до 4 часов (распределение не линейно, смещено в сторону 1). Количество переналадок не известно пока она не потребуется по факту. Объем партии обработки колеблется в зависимости от потребности. По статистике количество переналадок от 1 до 4 в сутки.

Ну вот, все данные у вас есть. Опредметите диапазон изменения параметра и посмотрите как ведет себя система при разных значения.

Георгий Лейбович пишет: А вот теперь вопрос (неоднократно мной задававшийся): как разобраться, что есть что, по одним только UDE's, не строя ДТР? Как обоснованно связать UDE's с причиной/проблемой, лежащей на несколько (иногда - много) уровней ниже без построения причинно-следственных связей сверху вниз, к корням (дедуктивный анализ), то есть, ДТР? А если UDE's низкого уровня, и причины/проблемы - рядом, то откуда известно, что они, эти UDE's, являются НУ для цели и КФУ? Я честного (без угадывания) способа не знаю. А Вы, коллеги?

Из материалов TOC SS:

Консолидированная Туча не всегда является Корневой Тучей. Консолидированная Туча в обобщенном виде отражает и объясняет существование трех выбранных для анализа НЖЯ. Для более полного анализа системы необходимо проанализировать все выявленные НЖЯ.

Корневая проблема объясняет логическую причину существования всех «разрывов»/НЖЯ. Корневую проблему можно представить как Корневую Тучу (Core Cloud) – диаграмму конфликта между двумя главными направлениями управления.

Нахождение Корневой Тучи:
1. Сделайте список всех НЖЯ вашей системы
2. Вернитесь к Консолидированной Туче и проверьте, вызывает ли Консолидированная Туча существование всех остальных НЖЯ.
3. Если нет, вам необходимо определить, какие НЖЯ не отражены Консолидированной Тучей
• Проверьте, что эти НЖЯ действительно находятся в рамках области для анализа.
• Если это так, продолжайте процесс консолидации Консолидированной Тучи с индивидуальными Тучами тех НЖЯ,
которые не попадают под уже консолидированную тучу.
• Продолжайте процесс до тех пор, пока все НЖЯ не будут отражены в получившейся новой Консолидированной Туче. Это и будет Корневая Туча.

В "Основах..." у Одеда и Елены написано, что метод 3UDE не доказан математически, но на практике получил признание и показал неплохие результаты. Насколько я понимаю этот метод в 90-х "вытянули" из Голдратта. По материалам TOC SS так же строится CRT, в котором отражается Core Cloud, все UDE и они соединяются, дерево проверяется. Так производится проверка Core Cloud. По опыту это давало очень сфокусированное дерево по сравнению с моими собственными попытками строить CRT по UDE.

Лично я когда строил EC по IOM и писал конфликтующие Need'ы, неожиданно автоматически сконсолидировал их все в мозгу и "увидел" корневой конфликт.

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

Роман Пантелеев пишет: Переналадка от 1 до 4 часов (распределение не линейно, смещено в сторону 1). Количество переналадок не известно пока она не потребуется по факту. Объем партии обработки колеблется в зависимости от потребности. По статистике количество переналадок от 1 до 4 в сутки.

Ну вот, все данные у вас есть. Опредметите диапазон изменения параметра и посмотрите как ведет себя система при разных значения.

Меня это не интересует - меня интересует взаимодействие с рынком. А до рынка от этого момента еще моделировать и моделировать... Причем заметьте как менялась формула в зависимости от поступавших данных. И каждый новый слушатель, увидев формулу, может сказать "неее там все не так, там вот так" (потому что он лично огребает каждый день результаты этих переналадок).

Роман Пантелеев пишет: [
Меня это не интересует - меня интересует взаимодействие с рынком.

Зачем же рассуждать о переналадках? В книге Шервуда есть глава - как строить диаграммы. Начинать с наиболее интересного и понятного элемента, а затем ответить на два вопроса - что движет этим элементом, а затем что движет этот элемент. У вас появиться две связи - нужно определить положительные они или отрицательные. Затем двигаться дальше - последовательно определяя элементы. Но необходимо всегда иметь ввиду цель разработки модели и чем конкретнее вы ее определить, тем она будет компактнее и полезнее. Мне кажется, что вы пытаетесь описать все предприятие - это принципиальная ошибка.