Продолжаю переписывать “Системное мышление”, по традиции публикую переписанный первый подраздел раздела “9. Целевая система и её надсистема”. Всего переписано уже 76%, по курсу уже идут две учебных группы, и я планирую успеть переписать остаток курса ещё до того, как до него дойдут студенты этих групп.
Сначала найти целевую систему
Первое, что нужно делать в системном мышлении — это не думать о всех системах сразу и глубокомысленно заявлять, что «всё системы, и всё со всем связано». Это правда, но ресурсов не хватит думать о всех системах сразу, а связи имеют разную важность. Поэтому системное мышление наоборот: помогает думать не обо всех системах сразу, а также выявлять самые важные связи между системами.
Увы, «менеджерские варианты» системного мышления полуторных поколений как раз говорят, что важно много думать, но не говорят, как именно думать: не дают метода мышления. А ведь «менеджерские варианты» изложены в самых издающихся и популярных книжках зарубежных авторов в области системного подхода в менеджменте, выпущенных в конце прошлого века (при чтении литературы всегда смотрите на даты её издания!).
Этот «менеджерский вариант» условно можно отнести к «полуторному» поколению системного мышления, потому как вроде бы говорится о системах создания (предприятиях), но задействуется первое поколение системного мышления: «всё очень сложно, система-предприятие состоит из частей, нетривиально связанных, и само это предприятие находится в очень сложном мире». Увы, дальше предлагается просто «думать больше, думать более тщательно», но не рассказывается, как именно – кроме ясного посыла, что к редукционизму неплохо бы добавлять холизм и думать всегда об окружении сначала, а собственно системе потом. Посыл верный, но пользы от такого мало.
Чтобы получить быструю и непосредственную пользу, в коллективном проекте надо понимать, что системное мышление должно быстро договорить всех вокруг – и для этого неплохо бы иметь понимание, зачем это все тут собрались в проект. Для этого надо выделить ту главную систему, которую вы в проекте хотите создать и развивать с нуля (greenfield), или развивать/изменять (brownfield). То есть первый ход – это сначала в графе создания определить ту систему, для которой самые разные создатели объединяются мышлением в граф по отношению создания. Эта система называется целевой, без договорённостей по поводу неё договориться обо всём остальном не удастся.
Сначала в проекте нужно договориться о том, какова целевая система (system-of-interest): понять её функцию в надсистеме и её границы, назвать её, чтобы можно было обсуждать дальше. Это очень непросто, речь идёт о творческом/предпринимательском/проактивном решении, высокорисковом моделировании неопределённого будущего. В целевую систему будет вложено много самых разных ресурсов, хорошо бы, чтобы она была успешна – чтобы она принесла выгоду, а не убыток, причём выгоду мы тут понимаем достаточно широко, речь необязательно идёт о денежной выгоде.
Чаще всего целевая система на момент достижения договорённостей о ней ещё не создана, проект только-только начинается, «ничего ещё не известно» – но системное мышление говорит, что это и есть повод задуматься: а что же создаём, что будем развивать? Но если ошибиться и не договориться, то все участники проекта будут создавать разные системы – и проект не получится, не будет успешным, реализуется басня про лебедя, рака и щуку.
Особенно важно не промахнуться в том, что если вы создаёте инструменты для какого-то метода (скажем, Software-as-a-Service, то есть какое-то серверное приложение, или инструменты какого-то сервиса), то целевыми тут являются системы, к которым вы эти инструменты применяете, а не сами создаваемые инструменты. Поговорка, что «никому не нужны свёрла, нужны дырки в стенах» – как раз про это, акцент всегда должен быть на системы, которые обрабатываются вашими инструментами, хотя самое сложное – это создать инструмент. Создатели обычно много сложней, чем изготавливаемые ими системы. Построить завод по массовому выпуску автомобилей много сложней, чем построить один прототип электромобиля в мастерской, причём не обращая внимания на стоимость постройки этого прототипа.
Чтобы создать инструмент, надо понимать, что вы этим инструментом собираетесь обрабатывать, что именно вы создаёте инструментом в момент эксплуатации инструмента. Вот это «создаваемое инструментом», «создаваемое предприятием» чаще всего и будет целевой системой. Но «чаще всего» – это не всегда, и с этим надо разбираться подробней.
Большинство затеянных проектов по созданию систем оказываются неудачными, и мы о них не знаем только потому, что о неудачах не принято трубить, трубят только об успехах! Систему ведь нужно создавать сейчас, а для этого предвидеть её успех в будущем. Но будущее предвидеть гарантированно в общем случае нельзя, можно только угадать — и это часто не удаётся, как минимум это не удаётся сделать с первой догадки, нужно несколько попыток. У вас должна быть какая-то «порождающая/generative модель мира» и вы должны будете сделать демоделирование/рендеринг/вообразить на основе этой порождающей модели мира с непонятной точностью и подробностями вашу целевую систему — это всё-таки «угадывание» в конечном итоге.
Целевую систему вы должны всё-таки угадать, а не «вычислить по формуле», «вывести по алгоритму». Дальше эту догадку надо прокритиковать, попытаться улучшить, если она оказалась хуже других догадок, и в итоге выбрать лучшую из имеющихся (поэтому обычно делают много догадок, и только выжившую критику принимают всерьёз, то есть кладут в основу проекта создания системы).
Про целевую систему говорят, что её «выявляют»/discover в ходе стратегирования. Стратегирование – это когда вы придумываете/выявляете метод улучшения вашей конкретной ситуации. Этот метод работы, который должен вам помочь, называется стратегией. Часто стратегирование заключается в том, что вы говорите, что ваша стратегия улучшит ситуацию тем, что вы будете делать такой-то класс систем, например, что вы будете создавать::«метод работы» автомобили::«результат работы по методу», будем «торговать электроэнергией»::метод с результатом работ – «сделка», будем «учить»::метод «мастеров игры в гольф»::результат метода. Выполнение работ по придуманному методу (реализация стратегии, получение результата) и должна привести к улучшению ситуации.
Успех – это что никто не отберёт от вас результат, не будет недовольных, вы получите прирост ресурсов, а не убыток от реализации стратегии. Вот целевая система – это и есть то, что создаётся в ходе выполнения какой-то стратегии::метод (обычно стратегии для какого-то коллективного агента – организации, где все договорились, как будут пользоваться ресурсами достижения результата в работах по стратегии. Конечно, в основе стратегии лежит догадка/гипотеза. Иногда эту догадку/гипотезу называют «предпринимательская ставка»/«entrepreneurial bet», как в азартной игре, ибо это только гипотеза, что команда выиграет при реализации стратегии – догадка о целевой системе и методах работы по её созданию может оказаться неверной, ресурсы будут инвестированы/вложены, а «улучшения ситуации»/выгоды/«превышения доходов над расходами с учётом дисконтирования» не будет. Иногда говорят и по-научному, «предпринимательская гипотеза» (и оценкой её верности при старте проекта занимается роль шумпетеровского предпринимателя, в наших курсах она называется короче – «визионер»).
Если нет беглости в системном мышлении, то вы будете определять целевую систему неправильно не только потому, что плохо предвидите будущее, но и просто из-за ошибок непродуманности. Вы будете терять в мышлении требующие вашего внимания объекты, и это привнесёт в проект риски. Скажем, вы определили целевую систему как поведение – всё, вас мало кто поймёт, вы мало с кем договоритесь. Типичная фраза: «моя целевая система – это разработка софта», и никакого звоночка в голове что «разработка::метод» это не система, отглагольным существительным называют обычно функции/методы::поведение, а неявно помянут софт в качестве системы и создатель софта в качестве ещё одной системы, но мы помним, что с софтом надо ещё разобраться, ограничивается ли дело только программой, или надо ещё поглядеть, кто создаёт организацию, которая использует софт для получения искомого результата. И дополнительно ещё «моя целевая система» – точно ли «моя»? Целевая система нужна для того, чтобы договориться всем, договорить всех, а не вам со всеми договориться. Хотя если инвестор вы лично – нет проблем, «моя целевая система» пойдёт, всех остальных наймёте, но всё равно «поведение» системой называть не стоит, нанятые вообразят в качестве целевой системы каждый что угодно – и проект развалится, коллективного мышления не случится.
Если вы определите целевую систему неправильно, то вы просто будете заниматься не тем, чем надо, будете зря тратить время: фокус вашего внимания будет не на важном, а «рядом с важным» или даже «далеко от важного». Системное мышление — это про осознанное управление вниманием, удерживание этого внимания на важном, определяемом типами объектов системного подхода — даже когда лень, «не хочется», когда думать трудно.
Системное мышление требует собранности (ещё и поддержанной компьютером: результаты системного моделирования должны быть записаны, чтобы не было шанса их забыть). Например, если вы высказали догадку о целевой системе, то системное мышление тут же говорит: «смотри от границы системы наружу, в надсистему. И не думай пока над прозрачным ящиком, тем более во время создания. Разберись сначала со временем использования, с чёрным ящиком). Это трудно – выдерживать это замечание, но без этого не поймёшь, что же тебе надо делать, каковы будут создатели и какие методы работы эти создатели будут применять для создания системы. Это трудно, поскольку речь обычно идёт о самом старте проекта, когда про целевую систему почти ничего нельзя сказать, но системное мышление требует рассказать о том, что она делает в каком именно окружении, зачем она это делает и почему это кому-то может быть нужным. Это буквальное следование мантре системного мышления.
Успешность (в том числе коммерческая успешность) создаваемой системы не может быть только «спроектирована» и тем самым гарантирована (неопределённое будущее всегда внесёт свои коррективы, исследования показывают, что доля удачи в успехе больших проектов больше, чем доля того же интеллекта, это подробней рассказывается в курсе «Системный менеджмент» в разделе по стратегированию). Тем не менее, удача может присутствовать — но всегда есть шанс, что она не будет использована из-за ошибок мышления. Системное мышление поможет избежать ошибок мышления в их наиболее вероятных местах, поможет договориться с самыми разными людьми, достигшими мастерства в исполнении самых разных профессиональных проектных ролей и поэтому заранее предупреждающих о самых разных рисках. Эти ошибки системное мышление поможет отслеживать в ходе всего проекта по созданию и развитию системы. Вам неоднократно придётся замысливать, проектировать и изготавливать, тестировать и эксплуатировать, модифицировать систему снова и снова, выкидывать/ликвидировать ненужные экземпляры системы, закрывать проект создания и развития системы за исчерпанием интереса к системе – и системное мышление требует, чтобы вы и все остальные участники проекта чётко понимали, о какой именно системе идёт речь, чтобы все могли договориться.
Вовремя замеченные признаки возможной неуспешности проекта создания целевой системы дадут команде проекта шанс как-то на них отреагировать, в том числе и отреагировать путём закрытия проекта — тратить ресурсы на заведомо неуспешный проект ни в коем случае нельзя, а системное мышление поможет обнаружить необходимость закрыть проект раньше. Системное мышление как санитар леса: заведомо дохлый проект оно убивает сразу, экономя время, нервы, деньги всех участников такого проекта. Если вы обнаружили, что создаётся софт ERP, а нужно создавать подразделение, которое будет задействовать софт для планирования работы предприятия, но этим подразделением никто не озабочен, все озабочены только софтом – всё, это неудача, бегите из такого проекта (если, конечно, вы не считаете, что можно скушать деньги на бесполезный проект, а отвечать за скушанные вами зря деньги будете не вы, а кто-то другой – это для вас этически приемлемо. Если неприемлемо – или реорганизуйте проект, или убегайте).
Системное мышление поможет и найти способы продолжить двигающийся к неуспешности проект, увеличить вероятность его успешности — оно подскажет, над чем нужно будет задуматься в первую очередь, на что потратить время размышлений о создаваемой и развиваемой системе. Системное мышление не столько помогает преодолеть проблемы (придумать, как решить проблемы), сколько вовремя выявляет проблемы, обращает на них внимание (буквально: оно же про управление вниманием!). Системное мышление больше связано с критикой, чем с выдвижением догадок. Системное творчество связано с выдвижением догадок и последующей критикой, так вот системное мышление говорит только, на какую тему нужны догадки (но не даёт метода выдвижения догадок), а потом помогает эти догадки прокритиковать. Изобрести системное мышление само по себе ничего не может, но может подсказать, что изобретать – и затем прокритикует, если окажется, что вы изобрели что-то не то.
Что надо делать, если вы определились с целевой системой, но догадка оказалась неверной? Дальше системное творчество: при найденных конфликтах и противоречиях нужно или подправить текущую догадку, или выдвинуть новую догадку. И тут нужно помнить, что единственного верного решения нет, решений огромное количество, но все они субоптимальны, и лучшие из доступных решений примерно одинаковы по их качеству (неустроенность). Кардинальные улучшения, «гениальные догадки» – редки!
Предприимчивость/проактивность/деятельность (тут слово «деятельность» как противоположное слову «бездеятельность», пассивность) понимается в фундаментальных методах мышления совсем необязательно в классическом экономическом смысле слова (то есть системы создают и развивают совершенно необязательно из-за желания заработать деньги, вложив/инвестировав сегодня в ресурсы, имеющие небольшую стоимость, а получив побольше завтра за обработанные ресурсы, которые имеют стоимость больше). Но в любом случае деятель/практик/трудящийся/инженер, что-то предпринимая/делая, выполняя какое-то дело/проект, прикидывает его успешность: пытается представить будущий мир, в котором результат проекта (система) существует — и пытается понять/познать/learn (в том числе деятельно, «активным зондированием», проводя эксперименты в физическом мире, задавая вопросы и т.д. — это не «умозрительно понять», это провести полноценное исследование/познание с экспериментами!). Участники проекта должны совместно представлять, что самые разные проектные роли будут ощущать по итогам этого проекта – то есть оценить, будет ли проект успешным.
Проекты могут быть самыми разными. Кто-то может танцевать («делать из себя артиста-танцора» – не забываем, что поведение всегда относим к каким-то системам, которые надо будет создать), но и в этом случае нужно думать о том, чтобы перформанс был успешен: успех перформанса артиста-танцора определяется не успехом в глазах только его самого. В некоторых странах на похоронах не принято танцевать, а в некоторых странах наоборот, принято — с гробом на плечах. Нужно смотреть на обстоятельства танцевания, а не только на сам танцевальный перформанс как связанную только с танцеванием артистов-танцоров систему. И только ли артист-танцор тут будет целевой системой в момент перформанса, или артист в момент его функционирования только подсистема в чём-то большем. Артист-танцор – это часть перформанса как микро-мероприятия, но и тут можно не останавливаться – частью чего является перформанс? Фестиваль, вечеринка, концерт? Может быть, коллективная договорённость достигается по этому поводу, а не по поводу подготовки танцора и доучивания его до уровня артиста и целевого выхода на перформанс?
Системное мышление не даст ответа на подобные вопросы, но оно даёт типы для того, чтобы вы могли задаться такими вопросами в вашем проекте – и в результате быстро коллективно договориться, что же вы-команда создаёте и развиваете. И ещё обратить внимание, что состав агентов этого «вы» могут быть существенно разные в зависимости от того, о каком проекте вы думаете, какого проекта вы считаете себя участником. А если вы участник нескольких проектов, то они ещё могут и конфликтовать, например, два проекта каждый могут срочно требовать от вас отдать 100% рабочего времени именно ему, и надо будет как-то объяснить и себе, и окружающим, почему вы тратите свой ресурс так, а не иначе.
Проекты существенно различаются по их масштабу. Так, кто-то может замысливать культурную революцию, воображая сообщество или даже общество, которое ведёт себя по-другому, чем сейчас – и это будет для него целевой системой. Осталось только найти участников проекта, для которых это же общество будет целевой системой с теми же характеристиками (о которых ещё надо договориться).
В любом случае, в проекте нужно реалистично вообразить: что (какая система) будет в итоге выполнения проекта. Более того, надо выполнить все предписания системного подхода: оценить не только, какой окажется целевая система и каково будет её поведение в момент эксплуатации, но и окружение этой целевой системы и влияние поведения целевой системы на это окружение, и что на эту тему влияния целевой системы на окружение будут думать внешние проектные роли, и что будут делать агенты, которые играют эти роли, если им проект понравится, и если не понравится. И это мы не касаемся систем в графе создания! Но эти системы должны договориться, эта оценка результата проекта (целевая система с её функцией/методом работы в её окружении, удовлетворение интересов внешних проектных ролей) должна быть общей для создателей, а поскольку речь идёт не только о создании, но и о развитии системы, эта оценка результата проекта должна проводиться на протяжении всего проекта, а не только в его начале.
Предпринимательский/проактивный/творческий/исследовательский характер любой деятельности в проекте происходит из-за того, что все стратегии и реализующие их планы – это только «прогнозы»/гипотезы/догадки, а также они являются не «объективными» (о них не догадываются как о «законах природы»), а предметом договорённостей (о них догадываются как о том, по поводу чего проще будет договориться), плюс договорённости могут «передоговариваться», будущее невозможно предугадать точно, а предсказание будет верным, но вряд ли будет верным долго.
Эта неопределённость заставляет и инженеров-технарей, и менеджеров как инженеров организации с этими инженерами-технарями, и инвесторов в эти организации, и политиков, которые заняты системами более высоких уровней, снова и снова думать о том, как в конечном итоге будет использована целевая система в её окружении и какие ещё могут быть эффекты от этого использования, удерживать внимание на ситуации использования целевой системы и отслеживать происходящее вокруг этого использования, хотя это использование будет только в будущем.
Все инженеры, когда создают и развивают свои системы, воображают их работающими ещё при замысливании и проектировании — без этого не было бы инженерии! Не было бы ни классической инженерии, ни инженерии предприятия, ни социальной инженерии! Неизвестность будущего не отменяет необходимости иметь порождающую модель (то есть модель, по которой вы можете породить образ будущего как варианта воплощения в нём целевой системы с какими-то параметрами), из которой вы обязательно должны вообразить/отрендерить/породить образ этого будущего и представить себе все возможные приятные и неприятные сюрпризы в этом будущем!
В системном мышлении нужно всегда думать о системе в её системном окружении (время использования!) и о мнении внешних проектных ролей по всей цепочке создания (внешние проектные роли должны быть готовы заплатить за создание и/или модернизацию целевой системы и систем её создания, но помним и о тех внешних ролях, которые будут считать проект неэтичным, сколько бы вам ни сулили за его реализацию. За изготовление газовых камер могут платить, и неплохо, но возьмётесь ли вы за такой проект?). Если система никому не нужна (то есть никому не нужно её поведение в надсистеме, ни для чьей надсистемы не нужна функция этой системы в достаточной мере, чтобы окупить затраты на создание системы), если система заведомо неуспешна по коммерческим или этическим соображениям — её обычно не делают. Ну, или делают, когда кто-то готов за это заплатить ради морального удовлетворения. Случаи, когда «готов заплатить, но не свои – например, сворованные деньги, или деньги налогоплательщиков», мы не рассматриваем.
Перед тем, как пытаться оценить успешность системы, нужно её найти/выявить/discover. Это стратегирование, предпринимательская/проактивная/enactive часть инженерии/деятельности/труда, и это должно выполняться коллективно.
Целевая система в системном мышлении — это как начало координат в ментальных «полярных координатах». Все остальные решения самых разных ролей по поводу выделения других систем — надсистемы, систем в окружении, подсистем, систем создания — делаются по отношению к целевой системе. Чтобы можно было понять, по поводу чего принимаются эти решения, сначала договариваются о целевой системе. И успешность тоже тем самым определяется по отношению к целевой системе и проекту её создания, это в разговор о том, что будет целевой системой проекта вовлекает не только роли в команде проекта и всём графе создания, но и внешние проектные роли.
Как использовать знание целевой системы? При любых попытках договориться или кого-то договорить:
• Вы объявляете, что вы с контрагентом (или два контрагента и вы, если вы кого-то договариваете) в общем проекте по созданию целевой системы – и называете эту систему. Контрагенты должны согласиться с предлагаемой целевой системой. Если нет общей целевой системы – то что вы вообще делаете вместе? Общность интересов устанавливается именно на основе того, что вы и ваши контрагенты находятся где-то в графе создания одной целевой системы.
• Теперь вы предъявляете связь того, что делает контрагент в отношении целевой системы – цепочку создания в графе создания.
• Далее предъявляете свой интерес к целевой системе (вы же в одном проекте!).
И только после этого говорите, что у вас за дело к контрагенту. Без того, что вы и контрагенты в графе создания одной целевой системы все вы там – «агенты с улицы» (речь ведь не обязательно о людях, агентами могут быть и организации – вы и ваши собеседники могут представлять, интересы организаций, и помним о конфликтах между системными уровнями, интересы представляемых контрагентами организаций и интересы ваших контрагентов в переговорах могут и отличаться, свои организации они могут и легко продать за тридцать сребренников). Без предъявления рассказа, что вы в одном проекте (создаёте одну целевую систему, только на разных местах в графе создания) вы все – случайные собеседники, кредит доверия минимален. Но если вы и контрагенты в одном графе создания какой-то целевой системы – ситуация меняется, вы в одной команде проекта на понятных вам местах. И поэтому может быть понятен интерес вас друг ко другу: вы хотите сделать проект успешным! Поэтому во всех договорённостях проверяется: если в них целевая система, или это частная договорённость, которая смоется в унитаз истории после того, как её перебьют другие договорённости – по поводу реальной целевой системы, а не того, что вы решили сделать маленькой вашей частной целевой системой в ходе переговоров. Целевые системы объединяют самых разных агентов в граф создания, без их упоминания очень трудно договориться о том, какое отношение два агента из непонятных мест в графе создания непонятно чего имеют друг ко другу, о чём им надо договариваться, какой там может быть взаимный не только предмет интереса, но и интерес.
Повторимся: целевая система – это вид системы, поэтому для выявленной вами целевой системы вы должны положительно ответить на все вопросы чеклиста выявления любой системы. Собственно, материал нашего курса в существенной мере как раз и даёт вопросы для такого чеклиста. Вот только несколько пунктов:
• Мы думали о ней прежде всего как о чёрном ящике в момент её работы (а не прозрачном ящике в момент создания). Всё остальное мы думали только потом, после этого.
• Это вещь, а не процесс/метод. Но она, несомненно, что-то делает (или будет делать, если ещё не существует) в окружении, функционирует/работает по какому-то методу, выполняет какую-то функцию в окружении. Если речь шла о процессе/методе, то не забыли поинтересоваться двумя системами: одна агент-создатель (не меняет своего состояния, как молекула катализатора) и вторая – у которой меняется состояние. Но сам процесс не перпепутан с системой! Это проверили три раза! Не забыли, что система может быть весьма неклассической (мероприятие, «договорка», игровая сессия), есть способы об этом думать как о вещи. Но метод – точно не система!
• Это не описание. Если уж речь зашла об описании, то проверили, что там за система описана этим описанием. Система физична, можно указать на место в пространстве-времени!
• Если есть слово «система» в названии, то мы его игнорируем (оно вполне может быть бытовым словом и сбивать с толку – типа «системы похудения»).
• Где проходят границы системы и какая её функция – договорились, она не «найдена объективно существующей». Что для вас «объективно», для других участников проекта будет пустой звук. Проверили, что эта договорённость известна всем участникам проекта и соблюдается.
• Отслеживаем, не поменялись ли договорённости, не поменялась ли система в ходе проекта: жизнь не останавливается, выявленные системы тоже меняются.
• В названии системы звучат слова из какой-то предметной области. Никаких «оборудование» или «потребительский товар» или даже «сервер» – любой такой широкий класс объектов в названии не участвует. Вы не назвали систему «зверь», поскольку один подумал о мышке, а другой – о тигре, и проблем разночтения с этим потом не оберёшься.
Про системы надо думать, применяя этот чеклист буквально. Если вы сказали, что «наш завод выпускает оборудование», то автор курса ехидно заметит, что это оборудование хлебопекарное или сантехническое, а ваши сотрудники будут считать, что это оборудование, которое меньше всего вам придёт в голову. В курсе «Моделирование и собранность» вам рассказывалось, что надо выбирать уровень абстракции, когда что-то говорите. Если фраза относится непонятно к оборудованию какого проекта (вашего или не вашего, слишком общо сформулировали), то лучше бы вы её не произносили. Это общая ошибка – говорить фразами из учебников инженерии и менеджмента, которые приложимы ко всем ситуациям вообще. Поэтому при обсуждении рабочих проектов такие фразы смысла не имеют, если вы не обсуждаете сами эти принципы инженерии и менеджмента, а обсуждаете свой рабочий проект.
Хорошо подвешенный язык не спасёт, спасёт знание материала курса. Хорошо подвешенный язык просто продемонстрирует, что вы плохо формулируете мысли, мутно доносите содержание.
Буквальное применение чеклиста такое: если сказано, что система это вещь, а не поведение вещи, то «у меня системой является увеличение производительности труда» — показывает, что вы глаголы от существительных не отличаете (вы говорите «система = увеличение», но увеличение — это не вещь, место увеличения::процесс::поведение в пространстве-времени вы не покажете). Если попытаетесь заменить систему с «увеличения производительности труда» на саму «производительность труда», то производительность — тоже не вещь, а характеристика труда, а если попытаетесь заменить производительность труда на сам труд, то труд — это опять-таки поведение, а не вещь, тоже не проходит чеклист. И если вы не включаете думалку, то подряд несколько раз при попытке выявить систему (не только целевую, но любую) будете выглядеть нелепо, ибо покажете окружающим вас людям, что не в состоянии разобраться, что в мире занимает какое-то место в пространстве-времени, а что — только описания, свойства, поведение чего-то в материальном мире (есть много ещё чего, кроме вещей).
И так буквально надо воспринимать все пункты чеклиста по выявлению систем, а также все положения курса. Курс про вашу работу главным образом, а на работе надо работать: быть умным, платят за это.
