Стейкхолдеры. Субъективность восприятия реальности


3 мес. 3 нед. назад #53984 от Александр Запорожцев
Александр Филонов пишет:

Раз Вы уж выбрасываете "Цель модели" (не моделирования) по SADT, Purpose модели (по 42010), то Вам придется искать им 'подмену". Собственно над чем Вы и бьетесь. Как назвать? Коренная проблема vs Поставленная проблема.

Совершенно точно! Разные стейкходеры могут ставить свои цели, но самым важным является наличие интереса к системе поэтому цели не так важны, как результат согласования разных интересов в обдной модели.

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


3 мес. 3 нед. назад #53985 от Александр Запорожцев
Александр Филонов пишет:

1) Проблема - рассмотрение системы с точки зрения стейкхолдера, который видит в поведении системы признаки (нежелательные явления), которые противоречат потребностям этого стейкхолдера. PLAN.
2) Нежелательные явления в поведении системы соответствуют использованию в деятельности системы практик, которые не дают того результата, который ожидает данный стейкхолдер. DO.
3) Выявление таких практик (функций) сводиться к построению функциональной модели "как есть" и анализу этой модели. Для тех практик, которые соответствуют нежелательным явлениям выявляются требования стейкхолдеров, которые выполняют эти практики. Учет этих требований позволяет выработать предложения по изменению практик. STUDY.
4) Объединяя требования всех стейкхолдеров разрабатываем модель"как должно быть". Эта модель будет соответствовать устранению нежелательных явлений в системе. ACT.
.

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

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


3 мес. 3 нед. назад #53986 от Александр Филонов
Александр Запорожцев пишет:

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


Ну ТОС предлагает здесь IOM (Critical Success Factors - три). Под ними - СSF нижнего уровня и тд.

В 6s - это CCR (Critical Сustomer Requirements), которые выясняются у Потребителя продукции (услуг) на первой стадии (Define) .

Проблемная функция - в цикле PDSA. P - Проблема.:lol:

Цикл очерчиваем окружностью - Проблематика.

Смотрим, что на выходе должно быть цикла PDSA, что на входе. Проблема в проблеме (в цикле PDSA).

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


3 мес. 3 нед. назад - 3 мес. 3 нед. назад #53987 от Александр Запорожцев
Александр Филонов пишет:

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

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


Ну ТОС предлагает здесь IOM (Critical Success Factors - три). Под ними - СSF нижнего уровня и тд.

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

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


3 мес. 3 нед. назад #53988 от Александр Запорожцев
Александр Филонов пишет:

Смотрим, что на выходе должно быть цикла PDSA, что на входе. Проблема в проблеме (в цикле PDSA).

Этот цикл - цикл постоянных улучшений, а я рассматриваю только один виток этого цикла - проект

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


3 мес. 3 нед. назад - 3 мес. 3 нед. назад #53989 от Александр Филонов
Александр Запорожцев пишет:

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


Что такое ' развернуть'?

Допустим, у вас есть слово, 'понятие'( ноумен), и ему надо дать определение (другими словами), - 'развернуть'

За каждым 'словом' стоит свой СХ, который как Вы говорите 'не видит' других. :)

Ну кроме как слово состоит из букв, буквы из звуков, звуки имею свое феноменальное значение. Проблема - это ноумен, которому надо 'дать определение'( выразить другими словами)

'Дать' лучше через 'действие'. Предложение.
Подлежащее, сказуемое, дополнение(обстоятельства), признаки (поведение). Через цикл PDSA. P - подлежащее, D - сказуемое... и тд.

Ну и дальше каждое слово тянет свою "расшифровку".

Т.е. у вас есть 'логическая цепочка', от одного слова к другим. От одной (более общей фунции) - к другим (вспомогательным).

Цикл PDSA - это механизм, "метод разворачивания".

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


3 мес. 3 нед. назад - 3 мес. 3 нед. назад #53990 от Александр Запорожцев
Александр Филонов пишет:

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

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


Что такое ' развернуть'?
.

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

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

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


3 мес. 3 нед. назад - 3 мес. 3 нед. назад #53991 от Александр Филонов
Александр Запорожцев пишет:

Термин "развернуть" - не соответствует сути процесса работы со стейкхолдерами. Правильным будет использовать слово обобщить (объединить) с точкам зрения других стейкхолдеров.


Еще раз.

Когда вы даете определение любому слову (например, стейкхолдер). "Стейкхолдер - это....". Вы разворачиваете или обьединяете? :)

Это случайный набор слов, или связанный отборных, наиболее точных воедино?

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


3 мес. 3 нед. назад #53992 от Александр Запорожцев
Александр Филонов пишет:

Когда вы даете определение любому слову (например, стейкхолдер). "Стейкхолдер - это....". Вы разворачиваете или обьединяете? :)
Это случайный набор слов, или связанный отборных, наиболее точных воедино?

Понятие существует в нашем мышлении в некоторой форме - просто так мы его представить для обсуждения не можем. Если нам нужно представить понятие во внешней среде, то мы начинаем подбирать слова, которые наиболее точно выражают наше понимание этого термина.Это мы делаем разворачивая понятие в поток слов.
Я же говорю совсем о другом - в начале проекта у команды нет представления о том, что должно получиться. Это делается за счет объединения разных точек зрения но будущую систему. Надеюсь, что здесь все понятно. Мой вопрос о переходе от представлений о системе в начале проекта к представлению, которое сформулируется при окончании проекта Каких стейкхолдеров нужно привлечь к работе в проекте? Общая проблема всех проектов - забывают о важных стейкхолдерах!

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


3 мес. 3 нед. назад #53993 от Роман Пантелеев
Александр Запорожцев пишет:

Подход ТОС исходит из другой модели - строиться идеальная модель системы - сравнивается с реальностью -

Александр, перестаньте свои идеи приписывать TOC. TOC не строит никакую идеальную модель системы.

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

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