О выделении систем в рабочем проекте

Когда начинаешь заниматься выделением систем/системных уровней "по всем правилам", с учетом принципа почтальона, количество этих систем плодится так быстро, что становится неудобно это обсуждать с коллегами, потому что есть сильное ощущение, что это бесполезное блуждание в словах и абстракциях.

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

Другой пример: при системном мышлении/системном моделировании организации, количество внутренних функций и ролей (например, "разработка", "инженер по эксплуатации") приблизительно равно количеству конструктивных элементов и сотрудников ("отдел разработки", "Вася Пупкин"). Даже неформальное моделирование всего этого многообразия систем в productivity tool требует заведения страницы/строки в таблице на каждую и функциональную, и конструктивную систему. Если организация не состоит исключительно из фанатиков системного мышления, эти объекты будут все время путаться как в обсуждениях, так и в описаниях. С другой стороны, наверное, цена этой путаницы не такая большая. Это разделение скорее полезно при планировании и приоритизации найма.

Вы написали, что количество систем плодится, когда начинаешь смотреть на предприятие “системным взглядом”, но потом в тексте было выделено 4 уровня системы (что логично, и совсем не много).
И у каждого предприятия есть уровни, на каждом из них - описание надсистемы (для чего подразделение/уровень работает, его функции, требования к этим функциям и ограничения.
Мне кажется, что здорово, что можно это описать и создать для сотрудников ясность в их Ролях, Функциях и Требованиях.