Надсистема: её тоже нужно найти!
Надсистема (иногда говорят using system, «использующая система») прежде всего должна проверяться на то, что целевая система является в момент эксплуатации (operation, работы, функционирования) неотъемлемой физической частью этой системы, то есть буквально входит в состав (composition) надсистемы. Увы, большинство ошибок происходят именно по невниманию к этому её признаку.
Системное разбиение (system breakdown structure) --- это иерархия по отношению состава/сборки/часть-целое, а не по каким-то другим отношениям. На ошибку выделения надсистемы и целевой системы указывают обнаружение между ними отношений вызова подпрограммы, классификации и специализации, принадлежности в части имущества, назначения на роль --- ведь есть огромное количество других отношений, кроме предписанного для системного разбиения отношения состава (composition, is_part_of, включения как физической части).
Например, рассмотрим мужчину и женщину. Какая у них надсистема? Да, они как-то взаимодействуют, у них есть какая-то функциональность в составе надсистемы. Какой? В студенческих аудиториях эту загадку решают минут пять, а в более взрослых аудиториях на это тратят пятнадцать секунд: надсистемой тут является семья (студенты часто говорят «пара», подчёркивая возможность более слабой связи), а женщина и мужчина находятся друг у друга в операционном/эксплуатационном/рабочем окружении. Загадка решается путём выявления пропущенной, не названной, не выявленной системы в системном разбиении. Это типичная ситуация: надсистемы обычно плохо различимы, иногда для них нет устоявшихся названий. Эти «пропущенные» системы приходится выявлять/определять (то есть описывать их роли, функции, границы) и как-то называть. Как называть? Точно так же, как любую другую систему, т.е. преимущественно (если нет какого-то явно устоявшегося исторического названия) по роли этой надсистемы в её надсистеме, т.е. по роли в над-надсистеме по отношению к целевой.
Признаком надсистемы в её отделении от целевой системы (а команде проекта обычно приходится иметь дело с обеими этими системами) является то, что команда не уполномочена как-то самостоятельно изменять саму эту систему или даже её описания/модели (концепцию использования, концепцию системы, архитектуру). Ещё десяток лет назад не предполагалось, что команда как-то может повлиять на надсистему --- она брала её в проект как данное, и должна была просто стыковать свою целевую систему с имеющимся системным окружением. Сегодня это не так: команда проекта не уполномочена изменять системное окружение непосредственно, но она может влиять на то, чтобы в целях согласования характеристик целевой и надсистемы эта надсистема была изменена --- самостоятельно её владельцами, или командой проекта по согласованию с владельцами надсистемы. Для этого команда проекта (внутренние проектные роли) активно работает с внешними проектными ролями/стейкхолдерами, влияет на них, и это происходит долго, ибо «непрерывное всё», развитие системы продолжается долго, это не «изготовили и забыли».
При выявлении надсистемы нужно помнить, что в зарубежных текстах иногда надсистему называют «использующей системой», using system.
Это потому, что в её составе инженер использует целевую систему. Это using относится к моменту создания, а не к моменту эксплуатации. Хотя часто так говорить можно и о моменте работы системы, функционировании её, ведя речь об окружении. Но «часто» --- это не всегда. Так, если оговориться, что «женщина использует мужчину», то дальше можно ошибочно по чисто лингвистическому рассуждению сказать, что женщина --- это использующая система. И отождествить с надсистемой. То есть мужчина получается в составе женщины (все молекулы мужчины входят в число молекул женщины), что есть нелепость. Поэтому аккуратней со значениями слова «использование», их два:
- Использование инженером в конструкции в design-time (речь обычно о надсистеме)
- Использование кем-то или чем-то в окружении в run-time/operations (нужно разбираться, что это вообще за использование).
При определении надсистемы важно, чтобы это был ближайший системный уровень (принцип почтальона, адрес должен быть точен --- нельзя отсылать в слишком общий объект), на котором ожидается эмерджентность/системный эффект от работы целевой системы в её составе.
Верный способ выявить надсистему --- это разобраться, с какими людьми приходится разговаривать (помним, что разговариваем с ролями!), чтобы проект состоялся. Они обычно и есть владельцы надсистемы. Скажем, вы делаете «систему перевозки самолётов», используемую во время ремонтов самолёта. Надсистема --- авиация страны, министерство промышленности? Нет, принцип почтальона говорит, что это «правда, но бесполезная правда», с равным успехом можно говорить и о «человечестве» как надсистеме, и даже о «всей вселенной»! В данном случае довольно просто выясняется, что «системой перевозки самолётов» интересуются главным образом люди из эксплуатационной службы одного из авиапредприятий.
Эксплуатационная служба этого авиапредприятия (и даже не всё авиапредприятие!) и является надсистемой для системы перевозки самолётов, а целевая система там будет --- самолёт, который надо в том числе перевозить. Система перевозки самолётов тут одна из систем-создателей для самолёта, сервис перевозки. У команды эксплуатационной службы авиапредприятия (внешние проектные роли по отношению к системе перевозки самолётов) есть потребности --- им нужно ремонтировать самолёты, которые не летают. И поэтому у них есть какая-то концепция использования наземной системы перевозки самолётов (заведомо не летающих). Всё, с этого момента (система перевозки самолётов как часть эксплуатирующей службы авиапредприятия = система как часть надсистемы) можно начинать обсуждать проект по созданию системы перевозки самолётов. Ход на выявление владельцев надсистемы (если только это не система систем) обычно крайне продуктивен: всё равно с этими владельцами нужно общаться, они важнейшие внешние роли в вашем проекте.
Ещё одна ошибка, когда надсистема и целевая система называются одинаково (мы уже говорили об этой ошибке, но её повторяют снова и снова, поэтому повторим ещё раз, другими словами). Разбиения типа «А состоит из А и Б» недопустимы, может быть только «А состоит из Б и В» --- и скорее всего эта ошибка не в том, что само разбиение в жизни какое-то неправильное, а просто неправильно выбраны имена для систем в нём. Например, «ячейка состоит из ячейки и прокладки». Подробное обсуждение показывает, что речь идёт о ячейке, которая состоит из корпуса и прокладки. «Жилая комната состоит из комнаты и интерьера». Подробное обсуждение показывает, что жилая комната состоит из помещения (строительной части, коробки без отделки) и интерьера (в который входят даже приклеенные к стенам помещения обои).
А ещё системное мышление состоит в том, что вы должны разобраться с устройством надсистемы, чтобы понять роль в ней целевой системы. На картинке в этом разделе это обозначено как reverse engineering для using system (а ontology --- это разные описания надсистемы, получаемые путём обратной инженерии, разбирательства с устройством надсистемы). А вот целевую систему вы будете получать прямой инженерией, или просто инженерией: описания целевой системы вы будете разрабатывать, чтобы целевая система смогла выполнить свою функцию в надсистеме. Как это всё делать, разбирается подробно в системной инженерии. В системном мышлении только указывается, что вам обязательно нужно понять функцию целевой системы в надсистеме, для этого нужно обязательновыявить надсистему и как-то разобраться в её устройстве. Если вы не разбираетесь с надсистемой, не разбираетесь с вышестоящим системным уровнем, то у вас не системное мышление. Ход проектного внимания от целевой системы на надсистему и разбирательство с ближним системным окружением --- это главное в системном мышлении.