ТОС и системная динамика


6 года 5 мес. назад #46692 от Александр Запорожцев

Александр Филонов пишет: IOM - инструмент коллективной работы. Логический инструмент. Логика начинается с единого понимания. Единых терминов.

Логика начинается у каждого в голове по отдельности. Причем ту коллективное мнение? Я в нескольких местах у Dettmer встречал утверждение, что логические диаграммы сначала разрабатываются автором и только потом они могут обсуждаться. Пока каждый индивидуально не пройдет путь построения диаграммы, обсуждать нечего. Смысл коллективного обсуждения в том, что выяснить другую точку зрения, а не в том, чтобы коллективно что то создать.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46694 от Александр Филонов

Александр Запорожцев пишет: Логика начинается у каждого в голове по отдельности. Причем ту коллективное мнение? .


Перечитайте ещё раз параграф UDE Determination статьи про IOM. Обратите внимание на ремарку (No double meaning intended!).

Обратите внимание как определяется цель в статье, articulated, single, consensus...

Поймите для чего это делается.
(нервничаете - уже хорошо. :) Значит mind барьер где-то близко)

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46702 от Александр Запорожцев

Александр Филонов пишет: Перечитайте ещё раз параграф UDE Determination статьи про IOM.

Читаю Карта Промежуточных Целей (автор Уильям Деттмер (H. William Dettmer), перевод Георгий Лейбович, первоисточник www.goalsys.com)
"Эта большая проблема состояла в том, что большинство людей испытывали сложности с CRT. Начать процесс построения оказалось не так легко, как казалось вначале. Более того, была сложность с воспроизводимостью результатов. Я наблюдал это, работая с сотрудниками одной и той же организации, разрешавшими независимо друг от друга одну и ту же системную проблему. Каждый из них видел проблемы организации по-разному, и хотя было и что-то сходное, во многих случаях они приходили к разным утверждениям относительно СР.
Это является серьёзной проблемой для любого метода, претендующего на логичность и научность. При одинаковой процедуре результаты такого метода должны быть воспроизводимы. Так как CRT существует для формулирования проблемы, если эта часть анализа ошибочна, то и остальная часть анализа, скорее всего, бесполезна. В результате, возникли очевидные вопросы: «Почему CRT столь сложно и почему результаты столь противоречивы?»
А почему сотрудники одной организации должны видеть проблему одинаково? По определению они видят проблемы по разному - они же стейкхолдеры!

Проблема в том, что без эталона того, что должно быть в системе, становится исключительно трудно – и дело субъективного мнения – определить, что в действительности не так в системе.
Эталон? Кто может определить эталон? У кого есть право устанавливать эталон?

Избежать синдром «Покрась свой вагончик» довольно легко. Требуется всего четыре вещи:
• Ясное определение рассматриваемой системы и её граней
• Одна названная согласованная Цель этой системы
• Определение Критических Факторов Успеха, являющихся не чем иным, как минимальным конечным результатом, необходимым для заявления, что Цель достигнута
• Выявление некоторых поддерживающих необходимых условий высокого уровня, которые обычно функциональны по природе.
Все вместе, они вполне представляют измеримый, объективный эталон того, что должно было случиться, если система достигает успеха.
ОК! "Одна названная согласованная Цель этой системы" - такая согласованная цель могла бы указывать на Эталон, но как можно определить согласованную цель, если мы не прошли по пути логических рассуждений и не нашли проблему?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46705 от Александр Филонов

Александр Запорожцев пишет: но как можно определить согласованную цель, если мы не прошли по пути логических рассуждений и не нашли проблему?
[/color]


Все. За парту. :laugh: Сначала - цель .

Без цели нет системы (теории). Деминг.

Опыт (факты) без теории ничему не учит (не учат).

Т.е. - без бенчмарка (теории системы) - лучше не заниматься "логическими упражнениями" по выяснению проблемы в системе.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46706 от Александр Запорожцев

Александр Филонов пишет: Все. За парту.

У любой системы есть назначение - некоторые это назначение называют целью. Назначение нашей системы - выпускать чертежи. Вы считаете, что в IOM для нашей системы это и есть GOAL?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46708 от Александр Филонов

Александр Запорожцев пишет: У любой системы есть назначение - некоторые это назначение называют целью. Назначение нашей системы - выпускать чертежи. Вы считаете, что в IOM для нашей системы это и есть GOAL?


Почему бы и нет? Выпускать чертежи. Критерии QCD (Quality-Cost-Delivery). Delivery means Just-in-Time.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад #46709 от Александр Запорожцев

Александр Филонов пишет: Почему бы и нет? Выпускать чертежи. Критерии QCD (Quality-Cost-Delivery). Delivery means Just-in-Time.

ОК! Тогда CSF - разрабатывать 3D модели, готовить КД, нормоконтроль, согласование технологов?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46711 от Александр Филонов

Александр Запорожцев пишет: ОК! Тогда CSF - разрабатывать 3D модели, готовить КД, нормоконтроль, согласование технологов?


Надо быть "глубоко в предмете".:) Я вам могу ответить только поверхностно.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46719 от Александр Запорожцев
Проведем логический анализ утверждения Dettmer "before you can decide how well you're doing, you must have a clear understanding of what you should be doing" - прежде чем вы сможете решить, насколько хорошо вы делаете, вы должны иметь четкое понимание того, что вы должны делать.
Это описана операция сравнения двух моделей системы "as to" и "to be". Модель системы "as to" - это то, что существует в реальности. Реальная система выполняет свое назначение (цель), но нас не удовлетворяет некоторые показатели, характеризующие степень удовлетворенности стейкхолдеров результатами выполнения назначения системы. Неудовлетворенность стейкхолдеров и инициирует использование LTP. Исходя из этого, логичным представляется рассматривать неудовлетворенность стейкхолдероов и считать ее побудительной причиной начала процесса преобразования и именно в направлении повышения удовлетворенности и формировать предложения по преобразованиям. Скорее всего, неудовлетворенность возникает от сравнения стейкхолдера текущих показателей деятельности с показателями деятельности более успешных организаций. Возможен вариант, когда стейкхолдеры собственное представление о том, какой они хотят видеть свою организацию. Таким образом - Goal и CSF в IOM это результат работы с требованиями стейкхолдеров к системе.
Резюме: модели системы "as to" и "to be" должны строиться с использований методов описания систем и методов работы с требованиями стейкхолдеров.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


6 года 5 мес. назад - 6 года 5 мес. назад #46721 от Александр Филонов

Александр Запорожцев пишет: Проведем логический анализ утверждения Dettmer "before you can decide how well you're doing, you must have a clear understanding of what you should be doing" - прежде чем вы сможете решить, насколько хорошо вы делаете, вы должны иметь четкое понимание того, что вы должны делать
...
Резюме: модели системы "as to" и "to be" должны строиться с использований методов описания систем и методов работы с требованиями стейкхолдеров.


Я думаю, Вы не очень успешно пытаетесь использовать метод Романа Пантелеева "3UDE" - как подогнать ответ под первоначальные условия задачи.:)

Постройте, пожалуйста, "логический" переход (термин "метод" должен присутствовать в переходе):

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


1."before you can decide how well you're doing, you must have a clear understanding of what you should be doing"
2. ...
3. => модели системы "as to" и "to be" должны строиться с использований методов описания систем и методов работы с требованиями стейкхолдеров.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Работает на Kunena форум