Частая ошибка – это считать, что системы создания (enabling systems, constructor systems) находятся в системном окружении. Нет, они не входят в системные уровни той иерархии по отношению «часть-целое», к которой принадлежит целевая система. Отношение их с целевой системой (и другими системами обсуждаемых системных уровней, то есть надсистемой, подсистемами) – отношение создания (на диаграмме оно не показано).
На рисунке одна из систем в окружении (этих систем множество!) – система 3. Например, для шестерёнки в часах таким окружением будут стрелки, тоже входящие в состав часов. А ещё в окружении могут быть какие-то системы, даже не входящие в состав надсистемы, но без которых трудно обсуждать работу/функционирование целевой системы – хотя они входят в какую-нибудь над-над-надсистему. Например, солнце, нагревающее часы и тем самым влияющее на шестерёнку (при нагреве она может поменять свои размеры, что может оказать влияние на основное поведение – точно передавать движение, что далее оказывает влияние на поведение надсистемы – точный показ времени). Окружение – это системы из состава надсистемы, над-надсистемы и т. д. Главное, что окружение – это вовне границ целевой системы и речь идёт о моменте, когда система работает и выполняет свою функцию (а не когда она задумывается, изготавливается, испытывается).
Заправочная станция для целевой системы такси, входящего в состав таксопарка как надсистемы – это система в окружении. Дорога для едущего по дороге такси – это система в окружении. Повторимся: совершенно необязательно, чтобы система в окружении была именно подсистемой надсистемы, «смежником» для целевой системы. Хотя иногда все другие (кроме целевой системы) подсистемы надсистемы для целевой системы выделяют специально, называя ближним окружением, а за пределами надсистемы системы называя дальним окружением. Для автомобильного мотора в составе автомобиля как надсистемы салон автомобиля и его колёса – ближнее окружение, это подсистемы автомобиля. А вот дорога и палящее солнце – это системы из дальнего окружения).
Подсистема – какая-то часть системы. В системном мышлении подсистемы в момент их использования рассматриваются главным образом как роли, функциональные объекты, причём только после рассмотрения окружения и определения функции целевой системы в окружении – ибо пока мы не понимаем, что должна делать целевая система, какую функцию/поведение она несёт в окружение, мы не можем ничего сказать про её состав и уж тем более не можем обсуждать конструкцию (какие там конструктивы, задействованные во время создания, играют роли выделенных подсистем). На рисунке пример такой подсистемы целевой системы показан под номером 4.
Проблема в том, что целевой системой для разных проектов может стать любая, которая будет проявлять интересную для них эмерджентность, нужный для них системный эффект. И тогда все остальные виды систем будут определяться по-другому. Скажем, если целевой системой в каком-то проекте объявить систему 4, то система 2 будет в этом проекте её надсистемой. И если все в том проекте договорились, что целевой системой будет система 4, то так тому и быть – именование разных систем в том проекте будет другое, хотя состав систем в системной иерархии будет одним и тем же. Если какая-то фирма делает интерьеры, то они в ней будут «целевая система», а если интерьерные часы – то «целевая система» – они, а если массово изготавливает шестерёнки (в том числе и к часам) – то «целевой системой» будет шестерёнка. И все разговоры будут крутиться вокруг целевых систем. А как же взаимодействие между проектами? Придётся договариваться: участники этих трёх проектов друг для друга будут «внешними ролями». При этом общения между проектом интерьера и проектом изготовления шестерёнок не будет, а вот часовщикам придётся общаться и с заказчиками – интерьерной фирмой, и с поставщиками – фирмой по изготовлению шестерёнок.
