#СтатьиШСМ
ПУТИ И ВАРИАНТЫ В ПРОСТРАНСТВЕ ВЫБОРОВ ПРОЕКТА

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

В английском языке для обозначения решения используются два разных слова - decision и solution. Например, руководитель проекта - это decision maker, тот, кто принимает управленческие решения, а руководитель проектного отдела, который ведет работы по подсистеме - это solution architect, тот кто принимает технические, проектные решения. Если уходить от составных терминов "управленческие решения" и "проектные решения" и пытаться сказать проще, то наиболее близким по смыслу будут слова "пути" и "варианты" соответственно.

Какие есть пути достижения цели? Другими словами, какие цепочки действий надо выполнить и какие ресурсы и средства нужны, чтобы их выполнить и прийти туда, куда надо?

Какие есть варианты? Куда мы придем конкретно? Другими словами, какие есть варианты итогового результата? Какая проблема и как конкретно будет решена? Какие варианты организационно-технических решений существуют для данной ситуации?

Первый набор вопросов задается руководителями и ответы на них ищутся в дисциплине проектного управления (P3M, portfolio, program and systems management). Второй набор вопросов задается системным инженерам и ответы на них ищутся в дисциплине системной инженерии (MBSE, model-based systems engineering).

Пути определяет руководитель проекта, а варианты - системный инженер.

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

Начинается все с определения проблемы...

Продолжение в блоге Александр Турханов по MBSE и цифровым двойникам организации: https://sdu2020.blogspot.com/2020/02/blog-post.html

#Левенчукворигинале
КЛОЧКИ СИСТЕМНОГО МЫШЛЕНИЯ: ПРОБЛЕМЫ ВИЗУАЛЬНОГО ПРЕДСТАВЛЕНИЯ ЗНАНИЙ

Анатолий Левенчук:
Жизнь показала, что люди честно не считают отдельные схемы из учебника системного мышления частями одной "большой схемы". Если говоришь "проектная роль", то они тут же вспоминают про предпочтения, но забывают, что роль выполняет практику. Если говоришь "интерес", то тут же вспоминают про предпочтение, но забывают о том, что ролевое описание/view отвечает на вопросы этого интереса ровно для того, чтобы понять, что там происходит с предпочтением, а сам интерес оформляется/framed ролевым методом описания/viewpoint. Все понятия учебника системного мышления применяются совместно, а не клочками. Если ты подумал о чём-то важном (помним, что понятия системного мышления представляют чеклист того, что нужно бы продумать), то подумай и о том важном, что связано с тем, о чём ты уже подумал. Если вспомнил про роль, то вспомни и об интересе, и о предпочтении, но также вспомни и о практике, и о ролевом описании, а также его методе описания! Это не так много: в жизни столько всего мелькает, воет и трясётся в проекте, отвлекая внимание, что фокусирование внимания на вот этих понятных и привычных ходах мысли экономит огромное количество времени.
Почему я сразу не привёл большую схему? Маленькие диаграммы уровня детского сада хороши (и они в учебнике есть), но большие диаграммы бесполезны. Я об этом подробно рассказываю в книжке "Визуальное мышление. Доклад о том, почему им нельзя обольщаться" (https://ridero.ru/books/vizualnoe_myshlenie/, в онлайн-курсе эта книжка есть как дополнительный материал к первой главе учебника). Вот вам несколько диаграмм из учебника системного мышления, которые я просто объединил через общие элементы. Семь альф я там подцветил, чтобы легче было ориентироваться.
Ну что, стало ли понятней?! Стал ли понятней хотя бы тезис, что "все эти диаграммы -- это просто выборки из одной большой схемы"? Будет ли теперь содержание учебника использоваться всё вместе, а не продолжать использоваться "подиаграммно"? Вот не факт, совсем не факт. У меня даже закралась мысль, что если убрать исходные диаграммы из текста, а оставить один текст, то это было бы лучше: текст был сложил в голове некоторое общее понимание, а диаграммы в учебнике только разорвали это общее понимание на клочки.
Большая диаграмма вообще непонятна, даже я смотрю на неё с ужасом, хотя сам сделал. А ведь все объекты и отношения там просто повторяют объекты и отношения из исходных диаграмм, добавил я совсем чуть-чуть -- понятие практики, чтобы показать связь роли и метода. Остальное всё "как было", ничего не добавлял, даже про три основных вида описаний (функциональное, конструктивное и размещений). Если представлять "полную диаграмму понятий системного мышления", то она была бы втрое сложней и окончательно нечитаема. Может, так и нужно было бы сделать, чтобы не разглядывали картинки, а сразу читали текст. Кто много читает, тот в мышлении обычно и выигрывает.
Продолжение: https://ailev.livejournal.com/1505852.html

СИСТЕМНАЯ ИНЖЕНЕРИЯ И СИСТЕМНОЕ МЫШЛЕНИЕ

Системный инженер — это тот, кто отвечает за успешность системы в целом.

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

Те, кто занимаются системной инженерией, называются системными инженерами (systems engineer). Профессия «системного инженера» была признана в 2009 году лучшей профессией в США. В опубликованном CNN Money совместно с PayScale рейтинге работ с самой большой оплатой и карьерным ростом первое место занимает системный инженер.

Преподаватель нашей Школы Александр Турханов написал пост о системном мышлении и системной инженерии:

«Я начну объяснение того, что такое системное мышление, с объяснения, что такое системная инженерия.

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

Есть много разных школ системной инженерии, но в основе любой из них лежит системное мышление. Системное мышление — это ядро, основа любого системного метода.

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

Продолжение: https://system-school.ru/engineering_and_thinking

#НачалаШСМ
ФУНКЦИИ

С одной стороны, человечество рассматривает мир как конструктивные объекты, а с другой — функционально. Функция — это определенное ролевое поведение, имеющее определенное назначение. Функциональные объекты — это роли, но эти роли материальны и имеют extent (продолжительность), когда совмещены с конструктивным объектом. Система именуется через функциональный объект, когда она готова и работает по ее основному назначению. Все системы имеют функцию, назначение и поведение; все системы играют какую-то роль, и это, по сути, представляет собой деятельность, происходящую во времени. Системный подход опирается на деятельностный подход. Мы считаем, что для каждой роли, то есть функции, есть определенное нормативное поведение. Функции берутся из культурного контекста, а знания накапливаются в виде норм поведения для ролей. Из ситуации в ситуацию передаются роли, а не объекты. Мы работаем с системном мышлением исключительно по функциям, по поведению, по назначениям в тот момент, когда система собрана и работает, и работаем в деятельностном подходе — то есть мы всегда понимаем, что система участвует в деятельности, которая имеет определенное назначение.

#BiblioШСМ
Научный руководитель Школы системного менеджмента Анатолий Левенчук (Anatoly Levenchuk) рекомендует

Business Objects: Re-Engineering for Re-Use
Автор: Chris Partridge

Несколько комментариев к книге от Анатолия Левенчука:
"1. Верхнее образование программистов по моей версии (http://ailev.livejournal.com/937201.html) должно включать философскую логику и моделирование данных. Книжка как раз даёт пример того, как стыкуются эти два курса -- хотя там абсолютно неклассическое изложение как философской логики, так и моделирования данных. Зато хорошо показаны разные парадигмы моделирования данных, и как эти парадигмы поддержаны разными парадигмами философской логики и её стыками с метафизикой. Если уж раскапывать это место, то вполне можно начинать с разбора этого текста, как демонстрации сути проблемы....
2. Излагаемый в BORO подход, в отличие от подхода ISO 15926, происходит главным образом из штудий организационного моделирования, а не моделирования систем из железа и бетона. Поэтому в нём много меньше чувствуется системно-инженерного "железного" начала, и моделирование системы в каком-то виде не выходит на первый план...
3. Сообщество ISO 15926 время от времени поднимает вопрос, не использовать ли теорию категорий для онтологической работы. Мне кажется, что книжка BORO даёт какое-то понимание, "в какое место можно воткнуться" с теоркатегорной парадигмой -- ибо именно в книжке BORO подробно рассказывается, как именно используется теоретико-множественная парадигма (описание в терминах классов). Если с этим разобраться, то можно подумать, как именно можно было бы похожим образом использовать иную, теоркатегорную парадигму -- что можно будет сохранить из уже наработанного знания, а что переформулировать заново в терминах новой парадигмы.
4. Книжка BORO интересна, как пример графической онтологической нотации. Онтологии неинтересно выражать как в UML, так и в простейших нотациях типа использованной в Части 7 ISO 15926. Использованная в книжке нотация для выражения онтологического знания довольно богата и наглядна, это интересный пример нотационной работы."

Более подробные комментарии к книге здесь: https://ailev.livejournal.com/938647.html

#FAQШСМ
Можете дать комментарий, почему техно-гиганты, которые фактически определяют "ландшафт" поощряют безумный JavaScript и он стал топовым языком, а не канул в безвестии?

Анатолий Левенчук:
У человека есть две системы мышления (по Канеману): тяжёлое и медленное и быстрое гештальтное интуитивное. Разные языки в разной степени поддерживают эти виды мышления. Языки, которые существенно задействуют только медленное рассудочное мышление (всякие функциональные Хаскели и логические Прологи) очень любимы академическими кругами. Но людям с ними трудно, медленное мышление плохо переходит в интуитивное быстрое, плохо передаётся друг другу в его разных вариантах. А вот с мышлением быстрым всё сильно попроще, оно сильно полегче (хотя и менее мощное) — интуиции вырабатываются быстро. Вот языки, в которых есть шанс простым смертным задействовать своё быстрое мышление, а не только медленное — они получают большое распространение. Они отвечают народным чаяниям, "на вопрос такой отвечай так-то, думать не нужно". А где "думать нужно всегда" — те языки нравятся только учёным и фрикам. У них нет шанса на массовость.

С системным мышлением примерно та же сложность, в нём думать нужно всегда ))) Иначе бы оно было широко распространено."

#Левенчукворигинале

ВИДЕО ДОКЛАДА "СИСТЕМНОЕ МЫШЛЕНИЕ ДЛЯ ИНЖЕНЕРОВ И МЕНЕДЖЕРОВ"

Анатолий Левенчук:
Видео моего часового доклада "Системное мышление для инженеров и менеджеров" на конференции #TeamLeadConf2020, 10 февраля 2020 (https://www.youtube.com/watch?v=AVH5Znnnks8):

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

Слайды доклада: https://yadi.sk/i/diytRS_x-XRtAg

Больше информации: https://ailev.livejournal.com/1506278.html

#НачалаШСМ
СЕРВИСЫ И КОМПЬЮТЕРНЫЕ ПРОГРАММЫ

Еще один сложный объект, с которым мы сталкиваемся, это сервис. Сервис — это поведение или функция системы. Любая система оказывает вовне определенный сервис по определенному каналу, то есть влияет на другие системы, внося в них изменения. Сервисы могут быть как положительными, так и отрицательными; более того, один и тот же сервис может рассматриваться как положительный или отрицательный по отношению к различным системам.
Другой важный случай — это компьютерные программы. Компьютерная программа, как ни странно, это физический объект, то есть 4D-индивид. Чтобы понять это, нужно вспомнить о том, что систему мы рассматриваем исключительно в тот момент, когда она оказывает сервис. На внутренних компонентах компьютера программа представляет собой фрагменты вещества, у которых есть определенные уровни напряжения по отношению друг к другу, а вычисление программы — это вполне физический процесс, имеющий протяженность во времени. Исходный код — это не сама программа, а описание программы, которое можно сравнить с картой территории или чертежом детали. Программа становится программой, когда она работает на компьютере, и в этот момент она материальна.
Чаще всего программа — это только подсистема, в которой работают еще и люди. Проекты по разработке программ — это обычно подпроекты разработки более крупных систем деятельности, в которых программа представляет собой один из материальных объектов наряду с другими. Старайтесь быть аккуратными в определении системы, с которой вы работаете. Компьютерная программа — это нормальная, полноценная система, но, скорее всего, только небольшая часть того, что вам на самом деле нужно.

#ВидеоШСМ
ТЕЗАУРУС: ОПИСАНИЯ, МОДЕЛИ И ВОПЛОЩЕНИЕ

О моделях и их воплощении рассказывает Виктор Агроскин, партнер Школы Системного Менеджмента, соучредитель ТехИнвестЛаб.ру, член INCOSE.

https://clck.ru/JR5Ex

#СтатьиШСМ
ВВЕДЕНИЕ В "ПОЛНОСПЕКТРОВОЕ" МЫШЛЕНИЕ
Мир есть совокупность фактов, а не объектов.
(с) Л.Витгенштейн
Терминология и построение онтологий.
Обычно мы разговариваем как попало и во многих ситуациях, особенно в сложных, мы бы не поняли, что говорит человек, если бы у нас не было некоторого ожидания того, что он может хотеть сказать.
Кроме того, людям редко свойственна терминологическая точность и совсем редко — навык сознательного построения онтологий (на самом деле имеются в виду, конечно, онтологические описания).
Но так или иначе мы все же строим онтологии, кривые, косые. То есть это значит, что у нас есть схема, в которую потом можно как-то запихивать содержание. Для этого нужно иметь "категорию" для явления, с которым мы сталкиваемся, иначе содержание никуда не влезает и мы его просто игнорируем.
Так что очень частая задача — это задача перевода с языка, в котором онтология не эксплицирована, на язык, в котором она есть в явном виде и как-то помогает.
Как правило, для этого нужно моделировать, а не делать двойник мира, то есть некоторым образом выделять существенное и отбрасывать несущественное. Именно поэтому онтологии для одного и того же куска мира бывают разные.
Как именно мы концептуализируем: объекты, классы объектов, классы классов.
Точность моделей как их полезность для предсказаний.
Как мы понимаем, что нам удалось сделать хорошую модель? Мы с ее помощью прогнозируем будущие события. Если удается, значит достаточно хорошо.
Чтобы делать полезные модели, нужно, чтобы элементы моделей указывали на те 4D или абстрактные объекты, поведение которых нам нужно предсказывать. Иначе мы ошибемся с уровнем и модель будет бесполезной.
А еще нужно, чтобы мы хорошо понимали, по каким правилам определять, что какой-то элемент модели указывает на что-либо.
Дело осложняется еще и тем, что мы взаимодействуем не столько с моделью, сколько с описанием модели, потому что описание неинтерактивно и мы никак по нему не можем проверить соответствие.
Семантика, синтактика и прагматика.
Семантика это о том, как связаны знак и значение, о том, как построить точную модель, онтологию, которая будет помогать нам воспринять всю реальность
Синтактика это о том, как связаны между собой знаки, как построить онтологию без существенных внутренних несоответствий, которую еще можно будет потом развивать и понимать интерсубъективно.
Прагматика — о том, как связаны знаки и люди, о том, как человек тебя понимает и что он делает, когда говоришь ему такие или другие слова.
Знак значение и смысл.
У нас обычно есть знак и его референт, то есть та вещь в реальном мире, к которой он отсылает или абстрактное понятие. Когда знак вроде бы должен отсылать к 4D объекту, но почему-то не отсылает, то мы говорим о несуществующем объекте.
Но между знаком и его значением есть еще и его смысл, то есть то, как он это означает. Этот смысл не потрогать, но он важный, потому что дает нам подсказку о том, какие модели в голове у человека, какая у него онтология.
Спорить о том, чей смысл правильный, если значение одинаковое — бесполезно, это спор о терминах.
Значение — 4D или абстрактный объект, а смысл — это обычно фраза, которая его описывает или отсылает к нему или говорит, как его найти.
Формулирование любых убеждений как предсказаний.
Чтобы избежать проблемы со спором о терминах в предельном варианте, можно формулировать любые свои убеждения о мире как предсказания.
Вероятностная природа убеждений.
А когда сформулировал предсказание, то уже хочешь не хочешь, а придется присвоить ему некоторую вероятность, потому что когда модель хоть сколько-нибудь сложная, приходится уже понимать, какие числа влияют на какие другие и как именно.
Свойство истинности для высказываний и свойство точности для моделей.

Так вот, хотя мы привыкли говорить об истинности (0,1) для высказываний, и более-менее привыкли говорить о точности моделей. Теперь у нас есть инструментарий, чтобы говорить, что высказывание истинно от 0 до 1 и модель точна от 0 до 1. Из более-менее истинных высказываний собираются более-менее точные модели и из более-менее точных моделей можно порождать новые более-менее истинные высказывания.
Разница между формальными выводами, чуйкой и байесианством.
Есть условно-истинные высказывания и такие способы рассуждений, которые позволяют получать из них тоже условно-истинные высказывания. Это правая часть спектра.
Есть неожиданные высказывания, которые появляются не из рассуждения, сделанного по правилам, а "просто" из совокупности прошлых высказываний. Это левая часть спектра.
Где-то посередине есть байесовские рассуждения, где мы учитываем не только условно-истинные высказывания и строгие рассуждения, но и высказывания с любой вероятностью и рассуждения разной степени точности с разным весом. Это дает нам возможность задействовать наши знания о мире более полно. Это некоторый компромисс между строгим рассуждением по правилам и полностью интуитивным выводом. Так что мы можем отобразить на байесовский язык остальные части спектра.
Перенос знания из одного домена в другой.
Итак, по умолчанию, мы можем строить модели и не вполне даже осознавать это. Чуть лучше, если мы можем строить модель и эксплицировать ее. И совсем хорошо, если мы можем эксплицировать и модель и способ построения модели, тогда у нас есть шансы перенести сам этот способ на другие домены и быть успешными в том числе там.
Практики (*)
Как понять, в каких ситуациях какую часть спектра мышления использовать?
Как развить навык собирать из мира (чаще всего речи или текста) поток данных так, чтобы они укладывались в схему?
UPD: Схема полного спектра например тут: https://ailev.livejournal.com/1390318.html
UPD2: Про творчество и прочий синтез: я считаю, что для продуктивного творчества сначала нужно освоить необходимый минимум, перечисленный выше. Потом можно подумать в сторону того, чтобы на волне какого-то особенного крутого или необычного переноса знания из одного домена в другой сделать что-то действительно новое.
Написала Прапион Медведева @ontologics .
https://thpectrum.livejournal.com/6250.html

#Левенчукворигинале
МЫСЛИ О ТАНЦАХ: ШАБЛОНЫ И ТВОРЧЕСТВО, СХЕМАТИЗАЦИЯ, ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННОЕ СОЗНАНИЕ
Анатолий Левенчук:
...1. Шаблоны против творчества: танец против пляски.
Вот один из моих ответов на проблему "шаблоны против творчества" (обсуждалась вчера опять в чате моего блога в телеграме, начиная с https://news.1rj.ru/str/ailev_blog_discussion/1685 -- "Не закладывает ли системное мышление паттерны в мышлении и хорошо ли это?"), пример социальных танцев -- https://vk.com/wall-179019873_616. Это ведь "подход": проблема шаблонов и творчества давно известна в танцах и подаётся как проблема танца (культурных шаблонов движений) против пляски (спонтанных неконтролируемых шаблонами движений). Вот в моём ответе на эту проблему задействована идея системных уровней и различного тренинга на различных уровнях. Шаблоны на одном уровне -- спонтанность в нюансировке в исполнении этих шаблонов на другом уровне, и так много уровней как вниз, так и вверх. И если это делать достаточно глубоко по уровням вниз и вверх, то проблема "шаблонности в творчестве" снимается.
Ещё один ответ про "шаблонность" лежит по линии теорий творчества. Для ответа на вопрос "помогают ли шаблоны творить" (помогает ли обучение системному мышлению создать что-то реально новое, обучение танцам танцевать что-то реально новое, и т.д.) опять обратимся к понятию интеллекта как возможности решения новых классов задач: https://ailev.livejournal.com/1498481.html. Новые классы задач -- это творчество, конечно! Интеллект как способность выработать в себе быстро какую-то (творчество!) новую компетенцию, если встретился с ситуацией, когда старых компетенций не хватает. Танцевальный интеллект тем самым я определяю как способность быстро научиться какому-то новому танцу, который преподы ещё и сами не видел — ибо весь набор компетенций по разбирательству с танцами уже будет. Телесный интеллект — быстро разобраться с новой телесной деятельностью (танцами, вокалом, спортом), потому как набор компетенций по разбирательству с двигательными практиками и вниманием к телу уже будет. Системный интеллект -- как быстро разобраться с какой-то новой системой, ибо весь набор компетенций и навыков по работе с системами уже будет. И так далее.
Будем ли мы учить сильному интеллекту, или ожидать, пока Маугли в джунглях сам познает все эти рутинные паттерны -- чтобы стать самым творческим Маугли на свете, чтобы не задействовать поганые шаблоны (поганые -- просто потому, что они шаблоны!) мысли и действия, приносимые цивилизацией? Ответ тут ровно тот же: чтобы творить на одном уровне мыслительных компетенций, нужно задействовать хорошо вышколенные шаблоны с нижележащих уровней. Чтобы творить на прикладном уровне, нужно шаблонно владеть трансдисциплинами. Чтобы овладеть трансдисциплинами, нужно вышколить в себе шаблоны осознанности, а чтобы и это было возможным, хорошо бы иметь хорошие гены в части интеллекта (хорошие шаблоны, чОрт возьми!).
Вот дальше вопрос: мы будем самые современные/state-of-the-art теории творчества использовать, или на коленке сочинять разные собственные теории, основанные на древних пониманиях творчества? Замечу, что даже понятие "художественный стиль" сегодня существенно формализовано — после того, как компьютеры смогли делать "перенос стиля". Уже нельзя размахивать руками, в этой области появилась теория/наука и эксперименты. И либо мы цитируем каких-то гуру в древних ремёслах, либо ссылаемся на какие-то обзоры литературы. Вот, например, на заход https://ailev.livejournal.com/1425331.html про системное творчество как процесс преодоления противоречий. Или немножко обзоров по компьютерной креативности (обсуждать креативность, так в общем виде -- кошечки ли, собачки ли, компьютера ли, человека ли, человечества ли вместе со всеми его компьютерами ли): https://ailev.livejournal.com/1251987.html, https://ailev.livejournal.com/1293469.html
Подробнее: https://ailev.livejournal.com/1506774.html

Вячеслав Мизгулин:
https://youtu.be/BPlphC88xR4
Выпускники курсов по системной инженерии, системному мышлению, системному менеджменту Школа системного менеджмента, настоятельно рекомендую посмотреть этот вебинар INCOSE - International Council on Systems Engineering.
Во-первых, почувствуете себя в мировой повестке после прохождения курсов.
Во-вторых, с другой стороны посмотрите на учебный материал, что тоже полезно. У доктора Vaneman достаточно широкий взгляд на проблематику MBSE, хоть и несколько архаичный. Тем не менее, он - практик, излагает достаточно простым языком, хоть и не по-русски. Замечу, что профессор сокрушается, хоть и неявно, на тему отсутствия общего системного языка. Конечно, есть подозрение, что он аккуратно пиарит LML.
https://www.facebook.com/viacheslav.mizgulin/posts/2831467993573969

#НачалаШСМ

СИСТЕМНЫЙ ПОДХОД 2.0. ПОНЯТИЕ ПРОЕКТНОЙ РОЛИ
В первом поколении системного подхода системы объективны, и мы заранее знаем, как они устроены и для чего предназначены. Во втором поколении появляются проектные роли и их системы деятельности. С этого момента системы становятся субъективными — “в глазах смотрящего”, и без проектных ролей не существуют.
В системном подходе нет наблюдателей, зато есть деятели. Их деятельность культурно обусловлена и распределена по ролям. Как вы помните, ранее мы говорили о том, что функция — это назначенное поведение системы. Так вот, это поведение назначают проектные роли в зависимости от своего интереса. Успешность системы тоже определяется проектными ролями — чем больше система соответствует ожиданиям самых различных проектных ролей, тем она успешнее.
Вполне естественно, что разные проектные роли по-разному определяют систему, и поэтому при работе с одной системой они должны договориться друг с другом. Если в в начале проекта потерять одну из проектных ролей, то не будут учтены какие-то части системы, а значит, система будет неуспешна. И выяснится это, когда проект потерпит неудачу, потому что появится проектная роль, которая скажет: мой интерес не учтен.
Итак, проектные роли — это деятельностные, культурно-обусловленные роли одного или нескольких людей, исполнение которых определенным образом влияет на проект по созданию системы, ее эксплуатации и выводу из эксплуатации, или же на которые влияет такой проект. Довольно близкий по смыслу перевод — “заинтересованная сторона” (но не “заинтересованное лицо” — это юридический термин, а дискуссии о терминологии с юристами нам ни к чему, о терминах мы должны договориться между собой). Есть еще один термин — “интересант”. Все эти термины мы будем использовать для обозначения проектной роли, который определяет систему в рамках системного подхода.