Дадим общие объяснения того, как смотреть на любую коллективную деятельность с точки зрения системного мышления. То есть как нарезать мир на отдельные части и как их связывать между собой, чтобы в конечном итоге создать успешную целевую систему и не упустить из виду систему-создателя. Вам это поможет работать не только в команде, которая создает целевую систему или «нашу систему», но и взаимодействовать с другими командами, которые создают надсистемы или системы в окружении, подсистемы или системы создания.
Опишем кратко то, что вы уже изучили в прошлых разделах о системном подходе, и обратите внимание на вторую часть следующего описания, где речь пойдет о системе-создателе. Это продолжение описания сути системного подхода, которое было начато в подразделе «Систематичность и системность» раздела 1, а потом уточнялось в подразделе «Области интересов» раздела 5.
Теперь пришло время дать более полное описание с учетом всех изученных системных понятий. Логическая последовательность рассуждений при этом не меняется. Начинаем с области интересов надсистемы, то есть смотрим на мир, который хотим как-то поменять. Потом переходим к целевой системе и её устройству. И далее обсуждаем систему-создателя, в том числе методы создания, роли и ресурсы.
Деятель меняет мир к лучшему за счет создания успешной системы, которая прогнозируемо решит определенные проблемы (неудовлетворенности) какой-то группы людей (целевых аудиторий). Эти люди как предполагает продвиженец будут менять свое поведение, а потому важно понять их проектные роли и практики, в т. ч. технологии. Успех системы зависит от удовлетворения интересов внешних проектных ролей , а для этого нужно предположить функцию работающей системы (роль целевой системы) в её окружении и учесть предметы интересов проектных ролей.
Для этого product owner создает концепцию использования системы как «черный ящик». Это всё помогает разработчикам сделать концепцию системы, в которой описываются взаимодействие функциональных частей системы и предлагается конструкция системы, а также делается увязка с пространственной компоновкой и с оценкой полной стоимости владения системы. Данные концепции также используются визионером для принятия решения о коммерческой эффективности выхода на рынок с данной целевой системой.
Наряду с разработчиками системой как «прозрачным ящиком» интересуются архитекторы, которые исходя из важных предметов интересов* определяют принципы разделения системы на модули и организацию связей их между модулями. Совокупность таких архитектурных решений называется архитектурой системы, которая получается согласно системного подхода 3.0 как результат оценки множества конфликтов между системными уровнями .
Архитектор, руководствуясь принципом непрерывности всего, старается организовать выпуск инкрементов системы для максимально незацепленных модулей автономными командами систем создания**. Общая команда старается добиться детализации описания всех систем с точностью, достаточной для изготовления целевой системы на выбранной производственной платформе — и изготовить по предложенным технологами и DevOps практикам. Далее происходит эксплуатация системы, снова и снова повторяя всё сделанное для улучшения каких-то частей системы, а то и для её полного изменения или изменения подсистем или для выпуска других целевых систем***.
Для всего этого необходимо иметь эффективную систему-создателя (чаще всего – организацию, предприятие). На развитие и текущую деятельность производственной платформы (до окупаемости) бизнесмен привлекает ресурсы инвесторов, и его интересует успешность всего предприятия.
Мышление про систему-создателя устроено примерно так же — функциональные части там проектные роли (оргроли), которая выполняет самые разные практики, а конструктивные части — оргзвенья. Сотрудники предприятия в разных проектных ролях выполняют работы по определенным практикам как бы находясь на производственном конвейере (с другими агентами, в т.ч. другие предприятия, AI, оборудование), руководит же этой производственной деятельностью операционный менеджер . А инициирует создание или организовывает конвейер – директор по развитию. Он же может в процессе создания и/или непрерывного развития целевой системы запустить проект развития системы-создателя для того, чтобы перестроить текущую производственную платформу.
Системное мышление по изменению физического мира проходит рекурсивно на многих уровнях и для самых разных систем. В рамках вашей проектной деятельности или вашего предприятия речь может идти о создании и развитии не только целевой системы (с её подсистемами), но также о создании и развития системы-создателя. При этом даже в большей степени речь идет о бесконечном процессе развития, для системной организации которого нам необходимы системные понятия и определенные мыслительные приемы.
Возможно, что представленное описание применения системного мышления вам не полностью понятно, но полная картинка будет складываться по мере прохождения основной программы ШСМ. Скорее всего, вам была хорошо понятна первая часть этого текста, и не совсем понятна вторая его часть, где пошла речь о системе-создателе. Вот этой расшифровкой второй части мы займемся в этом разделе.
*Так называемые «–ilities/-ости», то есть такие архитектурные характеристики система (предметы интересов) как доступность, непрерывность, производительность, возможность восстановления, надёжность и безопасность, устойчивость, масштабируемость, конфигурируемость, расширяемость, устанавливаемость, повторное использование, локализация, сопровождаемость, переносимость, поддерживаемость, возможность апгрейда. А еще архитекторы используют ключевые 4 метрики «непрерывности всего»: частота ввода в эксплуатацию; длительность прохождения изменений; процент сбоев для изменений; время восстановления обслуживания.
**Архитекторы вынуждены выбирать наименее плохие решения, ибо хороших решений не будет, поскольку, согласно системному подходу 3.0 нельзя мечтать об устаканенности, наоборот, в мире сплошные неустроенности. Поэтому с более высокого или более низкого системного уровня обязательно придет какая-то проблема.
***Не забывайте, что в проекте описывается сразу несколько систем, а не только целевая. Некоторым командам будет еще необходимо изготовить подсистемы, а другим и системы создания.
Источник: версия курса “Введение в системное мышление” 2024 года.