Стейкхолдеры. Субъективность восприятия реальности
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
Совершенно точно! Разные стейкходеры могут ставить свои цели, но самым важным является наличие интереса к системе поэтому цели не так важны, как результат согласования разных интересов в обдной модели.Александр Филонов пишет: Раз Вы уж выбрасываете "Цель модели" (не моделирования) по SADT, Purpose модели (по 42010), то Вам придется искать им 'подмену". Собственно над чем Вы и бьетесь. Как назвать? Коренная проблема vs Поставленная проблема.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
С первым пунктом частично согласен - один из стейкхолдеров выявляет нежелательные явления (или формулирует в общем виде то, что ему не нравиться) и инициирует проект модернизации части системы.Александр Филонов пишет: 1) Проблема - рассмотрение системы с точки зрения стейкхолдера, который видит в поведении системы признаки (нежелательные явления), которые противоречат потребностям этого стейкхолдера. PLAN.
2) Нежелательные явления в поведении системы соответствуют использованию в деятельности системы практик, которые не дают того результата, который ожидает данный стейкхолдер. DO.
3) Выявление таких практик (функций) сводиться к построению функциональной модели "как есть" и анализу этой модели. Для тех практик, которые соответствуют нежелательным явлениям выявляются требования стейкхолдеров, которые выполняют эти практики. Учет этих требований позволяет выработать предложения по изменению практик. STUDY.
4) Объединяя требования всех стейкхолдеров разрабатываем модель"как должно быть". Эта модель будет соответствовать устранению нежелательных явлений в системе. ACT.
.
Но в первый пункт необходимо отнести и разработку модели "как есть" так как без этой модели невозможно выявить те функции, которые связаны с этими нежелательными явлениями. В том случае если инициатор проекта сформулировал то, что ему не нравиться необходимо провести анализ этой формулировки в виде более конкретных признаков проблемы. Тут возникает вопрос - а как это сделать? Пока ответить не могу.
Со вторым пунктом согласен как с описанием связи нежелательный явлений с практиками (функциями + дисциплины, методы) Но в качестве практики выявления тех фуункций, которые связаны с нежелательными явлениями предложен анализ связей двух функций - функции стейкхолдера и функции поставщика
С третьим и четвертым пунктами согласен
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Филонов
- Не в сети
- Живу я здесь
- Сообщений: 6616
- Спасибо получено: 714
Александр Запорожцев пишет: В том случае если инициатор проекта сформулировал то, что ему не нравиться необходимо провести анализ этой формулировки в виде более конкретных признаков проблемы. Тут возникает вопрос - а как это сделать? Пока ответить не могу.
Ну ТОС предлагает здесь IOM (Critical Success Factors - три). Под ними - СSF нижнего уровня и тд.
В 6s - это CCR (Critical Сustomer Requirements), которые выясняются у Потребителя продукции (услуг) на первой стадии (Define) .
Проблемная функция - в цикле PDSA. P - Проблема.
Цикл очерчиваем окружностью - Проблематика.
Смотрим, что на выходе должно быть цикла PDSA, что на входе. Проблема в проблеме (в цикле PDSA).
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
Подход ТОС исходит из другой модели - строиться идеальная модель системы - сравнивается с реальностью - НЖЯ - причина НЖЯ - решение (изменения) для системыАлександр Филонов пишет:
Александр Запорожцев пишет: В том случае если инициатор проекта сформулировал то, что ему не нравиться необходимо провести анализ этой формулировки в виде более конкретных признаков проблемы. Тут возникает вопрос - а как это сделать? Пока ответить не могу.
Ну ТОС предлагает здесь IOM (Critical Success Factors - три). Под ними - СSF нижнего уровня и тд.
Я рассматриваю модель, где есть инициатор проекта и он определяет первоначальную формулировку НЖЯ и это задает ту сферу деятельности, которая будет рассматриваться в проекте.
Дальше проект выполняется в стандартной последовательности - требования стейкходеров и затем архитектура системы
Вопрос в том, как первоначальную формулировку НЖЯ развернуть в более конкретную и детальную. Необходимость конкретизации в том, что любой стейкхолдер видит свои НЖЯ и не может видить НЖЯ других стейкхолдеров
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
Этот цикл - цикл постоянных улучшений, а я рассматриваю только один виток этого цикла - проектАлександр Филонов пишет: Смотрим, что на выходе должно быть цикла PDSA, что на входе. Проблема в проблеме (в цикле PDSA).
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Филонов
- Не в сети
- Живу я здесь
- Сообщений: 6616
- Спасибо получено: 714
Александр Запорожцев пишет: Вопрос в том, как первоначальную формулировку НЖЯ развернуть в более конкретную и детальную. Необходимость конкретизации в том, что любой стейкхолдер видит свои НЖЯ и не может видить НЖЯ других стейкхолдеров
Что такое ' развернуть'?
Допустим, у вас есть слово, 'понятие'( ноумен), и ему надо дать определение (другими словами), - 'развернуть'
За каждым 'словом' стоит свой СХ, который как Вы говорите 'не видит' других.
Ну кроме как слово состоит из букв, буквы из звуков, звуки имею свое феноменальное значение. Проблема - это ноумен, которому надо 'дать определение'( выразить другими словами)
'Дать' лучше через 'действие'. Предложение.
Подлежащее, сказуемое, дополнение(обстоятельства), признаки (поведение). Через цикл PDSA. P - подлежащее, D - сказуемое... и тд.
Ну и дальше каждое слово тянет свою "расшифровку".
Т.е. у вас есть 'логическая цепочка', от одного слова к другим. От одной (более общей фунции) - к другим (вспомогательным).
Цикл PDSA - это механизм, "метод разворачивания".
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
Термин "развернуть" - не соответствует сути процесса работы со стейкхолдерами. Правильным будет использовать слово обобщить (объединить) с точкам зрения других стейкхолдеров. Это по результату - должно быть получено обобщенное представление о будущей системе. Но, в тот момент, когда инициатор проекта сформулировал свою точу зрения - сформулировал те нежелательные явления, которые он хотел бы устранить, в этот момент. Можно предположить, что от этой исходной точки выявление других нежелательных явлений может пойти в разных направлениях.Александр Филонов пишет:
Александр Запорожцев пишет: Вопрос в том, как первоначальную формулировку НЖЯ развернуть в более конкретную и детальную. Необходимость конкретизации в том, что любой стейкхолдер видит свои НЖЯ и не может видить НЖЯ других стейкхолдеров
Что такое ' развернуть'?
.
Вот начало проекта - схейхолдер определил нежелательное явление и пусть он соответствует некоторой функции предметной области. Как нужно выявлять остальные функции, которые соответствуют другим нежелательным явлениям. Конечно, схема упрощенная, но часто схема понятнее, чем слова))
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Филонов
- Не в сети
- Живу я здесь
- Сообщений: 6616
- Спасибо получено: 714
Александр Запорожцев пишет: Термин "развернуть" - не соответствует сути процесса работы со стейкхолдерами. Правильным будет использовать слово обобщить (объединить) с точкам зрения других стейкхолдеров.
Еще раз.
Когда вы даете определение любому слову (например, стейкхолдер). "Стейкхолдер - это....". Вы разворачиваете или обьединяете?
Это случайный набор слов, или связанный отборных, наиболее точных воедино?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 5556
- Спасибо получено: 591
Понятие существует в нашем мышлении в некоторой форме - просто так мы его представить для обсуждения не можем. Если нам нужно представить понятие во внешней среде, то мы начинаем подбирать слова, которые наиболее точно выражают наше понимание этого термина.Это мы делаем разворачивая понятие в поток слов.Александр Филонов пишет: Когда вы даете определение любому слову (например, стейкхолдер). "Стейкхолдер - это....". Вы разворачиваете или обьединяете?
Это случайный набор слов, или связанный отборных, наиболее точных воедино?
Я же говорю совсем о другом - в начале проекта у команды нет представления о том, что должно получиться. Это делается за счет объединения разных точек зрения но будущую систему. Надеюсь, что здесь все понятно. Мой вопрос о переходе от представлений о системе в начале проекта к представлению, которое сформулируется при окончании проекта Каких стейкхолдеров нужно привлечь к работе в проекте? Общая проблема всех проектов - забывают о важных стейкхолдерах!
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Роман Пантелеев
- Не в сети
- Живу я здесь
- Сообщений: 2397
- Спасибо получено: 238
Александр, перестаньте свои идеи приписывать TOC. TOC не строит никакую идеальную модель системы.Александр Запорожцев пишет: Подход ТОС исходит из другой модели - строиться идеальная модель системы - сравнивается с реальностью -
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Главная
- Форум
- Форум LeanZone.ru
- Общий
- Стейкхолдеры. Субъективность восприятия реальности