Ключевым понятием системной инженерии является успешность создаваемых систем. Можно ли это понятие сопоставить к ключевым понятием обычного системного подхода - Цель. Существует несколько определений того, что есть система и среди них такое - Система есть средство достижения цели. Одним из возможных вариантов интерпретации этого определения может быть следующее - деятель осознает свои потребности и это позволяет сформулировать цель - поставить конкретную задачу создания системы. В системном подходе рассматривается более реальная задача - перед группой людей поставлена задача создания системы. Цели тех, кто поставил задачу, тех, кто эту задачу будет решать, цели тех, на кого повлияете новая система очевидно будут разные. Поэтому в системном подходе 2.0 о цели создания системы ничего не говориться. Результат создания работы команды проекта - новая система будет проверятся не на соответствие заранее установленным целям, а по степени удовлетворенности заинтересованных лиц. В том случае, когда такая удовлетворенность будет достигнута, то считается, что система успешна.
В чем преимущество такого подхода? Основное преимущество в том, что заранее не определяется какой должен быть результат проекта. Это результат определяется в ходе выявления требований стейкхолдеров и эта деятельность .продолжается на протяжении всего проекта.
Резюме - если ориентироваться на Цель, то это лишает нас возможности адаптироваться к изменению нашего понимания того, какой может и должна быть система. Ориентация на успешность системы - заставляет нас в ходе всего проекта задавать вопрос - всели требования заинтересованных лиц учтены.

Александр Запорожцев пишет: Ориентация на успешность системы - заставляет нас в ходе всего проекта задавать вопрос - всели требования заинтересованных лиц учтены.

Цели не достигли, но зато повеселились. Успех!

Мне кажется, это просто от недопонимания, что без цели, (поставленной или не поставленной), - системы не существует. Априори.

Цель - это системообразующий фактор, вокруг которого создается или выделяется СИСТЕМА, "картина мира".

Дикарь не может увидеть системы в физике, математике, машине и т.д.

Чем отличается физика от математики? Целью.

Для художника, яблоко - прежде всего предмет красоты, любования... У него другие цели.
Для Ньютона, то же самое яблоко - это удар по лбу.

Если вы собираете стейкхолдеров построить систему бесцельно, то даже, например, получив в результате бесцельных движений картину, (нарисовав ее группой стейкхолдеров), вы достигли цели в определенной области. Каляки-маляки.



Успех?

Вы для этого собирались на заводе? Стейкхолдеры... Цели то не было. Вот и получили "успех". Всем понравилось.

PS

Александр Филонов пишет: Цель - это системообразующий фактор, вокруг которого создается или выделяется СИСТЕМА, "картина мира".

Да не вопрос - нужна цель - ставьте

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

Мне кажется, что вся идейная суть излагаемых Вами подходов состоит в следующем:
1. При выполнении проекта нужно принимать во внимание требования всех известных стейкхолдеров.
2. Надо учитывать эти требования с самого начала работы.
3. Надо учитывать взаимное влияние этих требований.
Далее разрабатывается конкретная методология реализации этой сути. Отлично, перевели с английского, развили дальше, но зачем при этом менять терминологию и замахиваться на НОВЫЙ системный подход? С точки зрения системного подхода здесь нет ничего нового. Можно объяснить маркетинговым ходом, но нам-то это зачем? Вы не продаёте, мы не покупаем. А вообще-то, одна из работ по теории стейкхолдеров издана в 80-е годы в США. Специально не искал, может быть, есть и более ранние.

Вы могли бы сформулировать, чем же для Вас отличаются СП.n от ... , а от чего? И правильно ли противопоставлять частное приложение общему подходу?

Воспользуюсь случаем и напишу замечание по поводу Вашего текста в другой ветке, кажется, диалог с Романом. Ваши стейкхолдеры могут и не иметь своих моделей результата проекта. Они могут предъявлять требования, исходя из видения моделей других объектов: налоговой системы, окружающей среды, дохода семьи, нагрузки на транспортную систему. Им безразлична модель вашего объекта, да и сам объект - им важны некоторые свойства. Так что, вы не всегда совмещаете разные модели (это усложнение задачи), а просто учитываете необходимые условия, накладываемые на результат проекта.

Георгий Лейбович пишет:

Александр Запорожцев пишет: ......Существует несколько определений того, что есть система и среди них такое - Система есть средство достижения цели.
Не можете ли Вы дать ссылку на источник такого забавного определения термина Система?

Перегудов и Тарасенко .Введение в системный анализ Москва Высшая школа, 1989 г. Мое знакомство с системным подходом началось с этой книги

Георгий Лейбович пишет: Мне казалось, что Вы некоторое количество веток и постов назад согласились с тем, что Система - вид моделей, обладающих некоторыми общими свойствами. В ряде случаев они более полезны, чем другие модели. Команда проекта создаёт модель объекта или объект, который должен удовлетворить стейкхолдеров (СХ)? Судя по тексту - речь идёт об объекте. В Вашем тексте Система - модель будущего объекта, удовлетворяющего СХ, или сам объект?

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

Георгий Лейбович пишет: Что понимается под результатом? Конкретный объект в деталях или набор его свойств? Что понимается под критикуемым термином "Цель": Конкретный объект в деталях или набор его свойств? В чём различие?

Результат - это реальный объект. Цель - это воображаемый результат. Различие в том, что когда мы используем понятие цель, мы прогнозируем будущий результат и стараемся эту цель достигнуть Возникает вопрос - насколько точно мы можем прогнозировать? Очевидно, что реальный объект будет в большей или меньшей степени будет отличаться он нашего прогноза. Поэтому в ходе проекта первоначальный облик создаваемого объекта будет меняться с учетом требований стейкхолдеров.

Георгий Лейбович пишет: То есть, говоря попросту, выполняя проект, мы должны выполнить предъявляемые к нему требования. Новое слово?[/color]

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

Георгий Лейбович пишет: Ваши стейкхолдеры могут и не иметь своих моделей результата проекта. Они могут предъявлять требования, исходя из видения моделей других объектов: налоговой системы, окружающей среды, дохода семьи, нагрузки на транспортную систему. Им безразлична модель вашего объекта, да и сам объект - им важны некоторые свойства. Так что, вы не всегда совмещаете разные модели (это усложнение задачи), а просто учитываете необходимые условия, накладываемые на результат проекта.

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

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

Георгий Лейбович пишет: То есть, говоря попросту, выполняя проект, мы должны выполнить предъявляемые к нему требования. Новое слово?[/color]

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

Вы неудачно разорвали написанное мной. Под термином имелось в виду слово "успешный".