3. Целевая система и её надсистема

Сначала найти целевую систему

Первое, что нужно делать в системном мышлении — это не думать о всех системах сразу и глубокомысленно заявлять, что «всё системы, и всё со всем связано». Это правда, но ресурсов не хватит думать о всех системах сразу, а связи имеют разную важность. Поэтому системное мышление наоборот: помогает думать не обо всех системах сразу, а также выявлять самые важные связи между системами.

Увы, «менеджерские варианты» системного мышления как раз говорят, что важно много думать, но не говорят, как именно думать: не дают метода мышления. А ведь «менеджерские варианты» изложены в самых издающихся и популярных книжках зарубежных авторов в области системного подхода в менеджменте, выпущенных в конце прошлого века (при чтении литературы всегда смотрите на даты её издания!).

Этот «менеджерский вариант» условно можно отнести к «полуторному» поколению системного мышления, потому как вроде бы говорится о системах создания (предприятиях), но задействуется первое поколение системного мышления: «всё очень сложно, система-предприятие состоит из частей, нетривиально связанных, и само это предприятие находится в очень сложном мире». Увы, дальше предлагается просто «думать больше, думать более тщательно», но не рассказывается, как именно — кроме ясного посыла, что к редукционизму неплохо бы добавлять холизм и думать всегда об окружении сначала, а собственно системе потом. Посыл верный, но пользы от такого мало.

Чтобы получить быструю и непосредственную пользу, в коллективном проекте надо понимать, что системное мышление должно быстро договорить всех вокруг — и для этого неплохо бы иметь понимание, зачем это все тут собрались в проект. Для этого надо выделить ту главную систему, которую вы в проекте хотите создать и развивать с нуля (greenfield), или развивать/изменять (brownfield). То есть первый ход — это сначала в графе создателей определить ту систему, для которой самые разные создатели объединяются мышлением в граф по отношению создания. Эта система называется целевой, без договорённостей по поводу неё договориться обо всём остальном не удастся.

Сначала в проекте нужно договориться о том, какова целевая система (system-of-interest): понять её функцию в надсистеме и её границы, назвать её, чтобы можно было обсуждать дальше. Это очень непросто, речь идёт о творческом/предпринимательском/проактивном решении, высокорисковом моделировании неопределённого будущего. В целевую систему будет вложено много самых разных ресурсов, хорошо бы, чтобы она была успешна — чтобы она принесла выгоду, а не убыток, причём выгоду мы тут понимаем достаточно широко, речь необязательно идёт о денежной выгоде.

Чаще всего целевая система на момент достижения договорённостей о ней ещё не создана, проект только-только начинается, «ничего ещё не известно» — но системное мышление говорит, что это и есть повод задуматься: а что же создаём, что будем развивать? Но если ошибиться и не договориться, то все участники проекта будут создавать разные системы — и проект не получится, не будет успешным, реализуется басня про лебедя, рака и щуку.

Особенно важно не промахнуться в том, что если вы создаёте инструменты для какого-то метода (скажем, Software-as-a-Service, то есть какое-то серверное приложение, или инструменты какого-то сервиса), то целевыми тут являются системы, к которым вы эти инструменты применяете, а не сами создаваемые инструменты. Поговорка, что «никому не нужны свёрла, нужны дырки в стенах» — как раз про это, акцент всегда должен быть на системы, которые обрабатываются вашими инструментами, хотя самое сложное — это создать инструмент. Создатели обычно много сложней, чем изготавливаемые ими системы. Построить завод по массовому выпуску автомобилей много сложней, чем построить один прототип электромобиля в мастерской, причём не обращая внимания на стоимость постройки этого прототипа.

Чтобы создать инструмент, надо понимать, что вы этим инструментом собираетесь обрабатывать, что именно вы создаёте инструментом в момент эксплуатации инструмента. Вот это «создаваемое инструментом», «создаваемое предприятием» чаще всего и будет целевой системой. Но «чаще всего» — это не всегда, и с этим надо разбираться подробней.

Большинство затеянных проектов по созданию систем оказываются неудачными, и мы о них не знаем только потому, что о неудачах не принято трубить, трубят только об успехах! Систему ведь нужно создавать сейчас, а для этого предвидеть её успех в будущем. Но будущее предвидеть гарантированно в общем случае нельзя, можно только угадать — и это часто не удаётся, как минимум это не удаётся сделать с первой догадки, нужно несколько попыток. У вас должна быть какая-то «порождающая/generative модель мира» и вы должны будете сделать демоделирование/рендеринг/вообразить на основе этой порождающей модели мира с непонятной точностью и подробностями вашу целевую систему — это всё-таки «угадывание» в конечном итоге.

Целевую систему вы должны всё-таки угадать, а не «вычислить по формуле», «вывести по алгоритму». Дальше эту догадку надо прокритиковать, попытаться улучшить, если она оказалась хуже других догадок, и в итоге выбрать лучшую из имеющихся (поэтому обычно делают много догадок, и только выжившую критику принимают всерьёз, то есть кладут в основу проекта создания системы).

Про целевую систему говорят, что её «выявляют»/discover в ходе стратегирования. Стратегирование — это когда вы придумываете/выявляете метод улучшения вашей конкретной ситуации. Этот метод работы, который должен вам помочь, называется стратегией. Часто стратегирование заключается в том, что вы говорите, что ваша стратегия улучшит ситуацию тем, что вы будете делать такой-то класс систем, например, что вы будете создавать::«метод работы» автомобили::«результат работы по методу», будем «торговать электроэнергией»::метод с результатом работ — «сделка», будем «учить»::метод «мастеров игры в гольф»::результат метода. Выполнение работ по придуманному методу (реализация стратегии, получение результата) и должно привести к улучшению ситуации.

Успех — это что никто не отберёт от вас результат, не будет недовольных, вы получите прирост ресурсов, а не убыток от реализации стратегии. Вот целевая система — это и есть то, что создаётся в ходе выполнения какой-то стратегии::метод (обычно стратегии для какого-то коллективного агента — организации, где все договорились, как будут пользоваться ресурсами достижения результата в работах по стратегии. Конечно, в основе стратегии лежит догадка/гипотеза. Иногда эту догадку/гипотезу называют «предпринимательская ставка»/«entrepreneurial bet», как в азартной игре, ибо это только гипотеза, что команда выиграет при реализации стратегии — догадка о целевой системе и методах работы по её созданию может оказаться неверной, ресурсы будут инвестированы/вложены, а «улучшения ситуации»/выгоды/«превышения доходов над расходами с учётом дисконтирования» не будет. Иногда говорят и по-научному, «предпринимательская гипотеза» (и оценкой её верности при старте проекта занимается роль шумпетеровского предпринимателя, в наших руководствах она называется короче — «визионер»).

Если нет беглости в системном мышлении, то вы будете определять целевую систему неправильно не только потому, что плохо предвидите будущее, но и просто из-за ошибок непродуманности. Вы будете терять в мышлении требующие вашего внимания объекты, и это привнесёт в проект риски. Скажем, вы определили целевую систему как поведение — всё, вас мало кто поймёт, вы мало с кем договоритесь. Типичная фраза: «моя целевая система — это разработка софта», и никакого звоночка в голове что «разработка::метод» это не система, отглагольным существительным называют обычно функции/методы::поведение, а неявно помянут софт в качестве системы и создатель софта в качестве ещё одной системы, но мы помним, что с софтом надо ещё разобраться, ограничивается ли дело только программой, или надо ещё поглядеть, кто создаёт организацию, которая использует софт для получения искомого результата. И дополнительно ещё «моя целевая система» — точно ли «моя»? Целевая система нужна для того, чтобы договориться всем, договорить всех, а не вам со всеми договориться. Хотя если инвестор вы лично — нет проблем, «моя целевая система» пойдёт, всех остальных наймёте, но всё равно «поведение» системой называть не стоит, нанятые вообразят в качестве целевой системы каждый что угодно — и проект развалится, коллективного мышления не случится.

Если вы определите целевую систему неправильно, то вы просто будете заниматься не тем, чем надо, будете зря тратить время: фокус вашего внимания будет не на важном, а «рядом с важным» или даже «далеко от важного». Системное мышление — это про осознанное управление вниманием, удерживание этого внимания на важном**, определяемом типами объектов системного подхода — даже когда лень, «не хочется», когда думать трудно.**

Системное мышление требует собранности (ещё и поддержанной компьютером: результаты системного моделирования должны быть записаны, чтобы не было шанса их забыть). Например, если вы высказали догадку о целевой системе, то системное мышление тут же говорит: «смотри от границы системы наружу, в надсистему. И не думай пока над прозрачным ящиком, тем более во время создания. Разберись сначала со временем использования, с чёрным ящиком). Это трудно — выдерживать это замечание, но без этого не поймёшь, что же тебе надо делать, каковы будут создатели и какие методы работы эти создатели будут применять для создания системы. Это трудно, поскольку речь обычно идёт о самом старте проекта, когда про целевую систему почти ничего нельзя сказать, но системное мышление требует рассказать о том, что она делает в каком именно окружении, зачем она это делает и почему это кому-то может быть нужным. Это буквальное следование мантре системного мышления.

Успешность (в том числе коммерческая успешность) создаваемой системы не может быть только «спроектирована» и тем самым гарантирована (неопределённое будущее всегда внесёт свои коррективы, исследования показывают, что доля удачи в успехе больших проектов больше, чем доля того же интеллекта, это подробней рассказывается в руководстве по методологии в разделе по стратегированию). Тем не менее, удача может присутствовать — но всегда есть шанс, что она не будет использована из-за ошибок мышления. Системное мышление поможет избежать ошибок мышления в их наиболее вероятных местах, поможет договориться с самыми разными людьми, достигшими мастерства в исполнении самых разных профессиональных проектных ролей и поэтому заранее предупреждающих о самых разных рисках. Эти ошибки системное мышление поможет отслеживать в ходе всего проекта по созданию и развитию системы. Вам неоднократно придётся замысливать, проектировать и изготавливать, тестировать и эксплуатировать, модифицировать систему снова и снова, выкидывать/ликвидировать ненужные экземпляры системы, закрывать проект создания и развития системы за исчерпанием интереса к системе — и системное мышление требует, чтобы вы и все остальные участники проекта чётко понимали, о какой именно системе идёт речь, чтобы все могли договориться.

Вовремя замеченные признаки возможной неуспешности проекта создания целевой системы дадут команде проекта шанс как-то на них отреагировать, в том числе и отреагировать путём закрытия проекта — тратить ресурсы на заведомо неуспешный проект ни в коем случае нельзя, а системное мышление поможет обнаружить необходимость закрыть проект раньше. Системное мышление как санитар леса: заведомо дохлый проект оно убивает сразу, экономя время, нервы, деньги всех участников такого проекта. Если вы обнаружили, что создаётся софт ERP, а нужно создавать подразделение, которое будет задействовать софт для планирования работы предприятия, но этим подразделением никто не озабочен, все озабочены только софтом — всё, это неудача, бегите из такого проекта (если, конечно, вы не считаете, что можно скушать деньги на бесполезный проект, а отвечать за скушанные вами зря деньги будете не вы, а кто-то другой — это для вас этически приемлемо. Если неприемлемо — или реорганизуйте проект, или убегайте).

Системное мышление поможет и найти способы продолжить двигающийся к неуспешности проект, увеличить вероятность его успешности — оно подскажет, над чем нужно будет задуматься в первую очередь, на что потратить время размышлений о создаваемой и развиваемой системе. Системное мышление не столько помогает преодолеть проблемы (придумать, как решить проблемы), сколько вовремя выявляет проблемы, обращает на них внимание (буквально: оно же про управление вниманием!). Системное мышление больше связано с критикой, чем с выдвижением догадок. Системное творчество связано с выдвижением догадок и последующей критикой, так вот системное мышление говорит только, на какую тему нужны догадки (но не даёт метода выдвижения догадок), а потом помогает эти догадки прокритиковать. Изобрести системное мышление само по себе ничего не может, но может подсказать, что изобретать — и затем прокритикует, если окажется, что вы изобрели что-то не то.

Что надо делать, если вы определились с целевой системой, но догадка оказалась неверной? Дальше системное творчество: при найденных конфликтах и противоречиях нужно или подправить текущую догадку, или выдвинуть новую догадку. И тут нужно помнить, что единственного верного решения нет, решений огромное количество, но все они субоптимальны, и лучшие из доступных решений примерно одинаковы по их качеству (неустроенность). Кардинальные улучшения, «гениальные догадки» — редки!

Предприимчивость/проактивность/деятельность (тут слово «деятельность» как противоположное слову «бездеятельность», пассивность) понимается в фундаментальных методах мышления совсем необязательно в классическом экономическом смысле слова (то есть системы создают и развивают совершенно необязательно из-за желания заработать деньги, вложив/инвестировав сегодня в ресурсы, имеющие небольшую стоимость, а получив побольше завтра за обработанные ресурсы, которые имеют стоимость больше). Но в любом случае деятель/практик/трудящийся/инженер, что-то предпринимая/делая, выполняя какое-то дело/проект, прикидывает его успешность: пытается представить будущий мир, в котором результат проекта (система) существует — и пытается понять/познать/learn (в том числе деятельно, «активным зондированием», проводя эксперименты в физическом мире, задавая вопросы и т.д. — это не «умозрительно понять», это провести полноценное исследование/познание с экспериментами!). Участники проекта должны совместно представлять, что самые разные проектные роли будут ощущать по итогам этого проекта — то есть оценить, будет ли проект успешным.

Проекты могут быть самыми разными. Кто-то может танцевать («делать из себя артиста-танцора» — не забываем, что поведение всегда относим к каким-то системам, которые надо будет создать), но и в этом случае нужно думать о том, чтобы перформанс был успешен: успех перформанса артиста-танцора определяется не успехом в глазах только его самого. В некоторых странах на похоронах не принято танцевать, а в некоторых странах наоборот, принято — с гробом на плечах. Нужно смотреть на обстоятельства танцевания, а не только на сам танцевальный перформанс как связанную только с танцеванием артистов-танцоров систему. И только ли артист-танцор тут будет целевой системой в момент перформанса, или артист в момент его функционирования только подсистема в чём-то большем. Артист-танцор — это часть перформанса как микро-мероприятия, но и тут можно не останавливаться — частью чего является перформанс? Фестиваль, вечеринка, концерт? Может быть, коллективная договорённость достигается по этому поводу, а не по поводу подготовки танцора и доучивания его до уровня артиста и целевого выхода на перформанс?

Системное мышление не даст ответа на подобные вопросы, но оно даёт типы для того, чтобы вы могли задаться такими вопросами в вашем проекте — и в результате быстро коллективно договориться, что же вы-команда создаёте и развиваете. И ещё обратить внимание, что составы агентов этого «вы» могут быть существенно разные в зависимости от того, о каком проекте вы думаете, какого проекта вы считаете себя участником. А если вы участник нескольких проектов, то они ещё могут и конфликтовать, например, два проекта каждый могут срочно требовать от вас отдать 100% рабочего времени именно ему, и надо будет как-то объяснить и себе, и окружающим, почему вы тратите свой ресурс так, а не иначе.

Проекты существенно различаются по их масштабу. Так, кто-то может замысливать культурную революцию, воображая сообщество или даже общество, которое ведёт себя по-другому, чем сейчас — и это будет для него целевой системой. Осталось только найти участников проекта, для которых это же общество будет целевой системой с теми же характеристиками (о которых ещё надо договориться).

В любом случае, в проекте нужно реалистично вообразить: что (какая система) будет в итоге выполнения проекта. Более того, надо выполнить все предписания системного подхода: оценить не только, какой окажется целевая система и каково будет её поведение в момент эксплуатации, но и окружение этой целевой системы и влияние поведения целевой системы на это окружение, и что на эту тему влияния целевой системы на окружение будут думать внешние проектные роли, и что будут делать агенты, которые играют эти роли, если им проект понравится, и если не понравится. И это мы не касаемся систем в графе создателей! Но эти системы должны договориться, эта оценка результата проекта (целевая система с её функцией/методом работы в её окружении, удовлетворение интересов внешних проектных ролей) должна быть общей для создателей, а поскольку речь идёт не только о создании, но и о развитии системы, эта оценка результата проекта должна проводиться на протяжении всего проекта, а не только в его начале.

Предпринимательский/проактивный/творческий/исследовательский характер любой деятельности в проекте происходит из-за того, что все стратегии и реализующие их планы — это только «прогнозы»/гипотезы/догадки, а также они являются не «объективными» (о них не догадываются как о «законах природы»), а предметом договорённостей (о них догадываются как о том, по поводу чего проще будет договориться), плюс договорённости могут «передоговариваться», будущее невозможно предугадать точно, а предсказание будет верным, но вряд ли будет верным долго.

Эта неопределённость заставляет и инженеров-технарей, и менеджеров как инженеров организации с этими инженерами-технарями, и инвесторов в эти организации, и политиков, которые заняты системами более высоких уровней, снова и снова думать о том, как в конечном итоге будет использована целевая система в её окружении и какие ещё могут быть эффекты от этого использования, удерживать внимание на ситуации использования целевой системы и отслеживать происходящее вокруг этого использования, хотя это использование будет только в будущем.

Все инженеры, когда создают и развивают свои системы, воображают их работающими ещё при замысливании и проектировании — без этого не было бы инженерии! Не было бы ни классической инженерии, ни инженерии предприятия, ни социальной инженерии! Неизвестность будущего не отменяет необходимости иметь порождающую модель (то есть модель, по которой вы можете породить образ будущего как варианта воплощения в нём целевой системы с какими-то параметрами), из которой вы обязательно должны вообразить/отрендерить/породить образ этого будущего и представить себе все возможные приятные и неприятные сюрпризы в этом будущем!

В системном мышлении нужно всегда думать о системе в её системном окружении (время использования!) и о мнении внешних проектных ролей по всему графу создателей (внешние проектные роли должны быть готовы заплатить за создание и/или модернизацию целевой системы и систем её создания, но помним и о тех внешних ролях, которые будут считать проект неэтичным, сколько бы вам ни сулили за его реализацию. За изготовление газовых камер могут платить, и неплохо, но возьмётесь ли вы за такой проект?). Если система никому не нужна (то есть никому не нужно её поведение в надсистеме, ни для чьей надсистемы не нужна функция этой системы в достаточной мере, чтобы окупить затраты на создание системы), если система заведомо неуспешна по коммерческим или этическим соображениям — её обычно не делают. Ну, или делают, когда кто-то готов за это заплатить ради морального удовлетворения. Случаи, когда «готов заплатить, но не свои — например, сворованные деньги, или деньги налогоплательщиков», мы не рассматриваем.

Перед тем, как пытаться оценить успешность системы, нужно её найти/выявить/discover. Это стратегирование, предпринимательская/проактивная/enactive часть инженерии/деятельности/труда, и это должно выполняться коллективно.

Целевая система в системном мышлении — это как начало координат в ментальных «полярных координатах». Все остальные решения самых разных ролей по поводу выделения других систем — надсистемы, систем в окружении, подсистем, систем создания — делаются по отношению к целевой системе. Чтобы можно было понять, по поводу чего принимаются эти решения, сначала договариваются о целевой системе. И успешность тоже тем самым определяется по отношению к целевой системе и проекту её создания. Это в разговор о том, что будет целевой системой проекта, вовлекает не только роли в команде проекта и всём графе создателей, но и внешние проектные роли.

Как использовать знание целевой системы? При любых попытках договориться или кого-то договорить:

• Вы объявляете, что вы с контрагентом (или два контрагента и вы, если вы кого-то договариваете) в общем проекте по созданию целевой системы — и называете эту систему. Контрагенты должны согласиться с предлагаемой целевой системой. Если нет общей целевой системы — то что вы вообще делаете вместе? Общность интересов устанавливается именно на основе того, что вы и ваши контрагенты находятся где-то в графе создателей одной целевой системы.

• Теперь вы предъявляете связь того, что делает контрагент в отношении целевой системы — путь по отношениям начального создания и последующего развития в графе создателей.

• Далее предъявляете свой интерес к целевой системе (вы же в одном проекте!).

И только после этого говорите, что у вас за дело к контрагенту. Без того, что вы и контрагенты в графе создателей одной целевой системы все вы там — «агенты с улицы» (речь ведь не обязательно о людях, агентами могут быть и организации — вы и ваши собеседники могут представлять, интересы организаций, и помним о конфликтах между системными уровнями, интересы представляемых контрагентами организаций и интересы ваших контрагентов в переговорах могут и отличаться, свои организации они могут и легко продать за тридцать сребренников). Без предъявления рассказа, что вы в одном проекте (создаёте одну целевую систему, только на разных местах в графе создателей) вы все — случайные собеседники, кредит доверия минимален. Но если вы и контрагенты в одном графе создателей какой-то целевой системы, и это вам обоим известно — ситуация меняется, вы в одной команде проекта на понятных вам местах. И поэтому может быть понятен интерес вас друг ко другу: вы хотите сделать проект успешным! Поэтому во всех договорённостях проверяется: если в них целевая система, или это частная договорённость, которая смоется в унитаз истории после того, как её перебьют другие договорённости — по поводу реальной целевой системы, а не того, что вы решили сделать маленькой вашей частной целевой системой в ходе переговоров. Целевые системы позволяют выстроить самых разных агентов в граф создателей, без их упоминания очень трудно договориться о том, какое отношение два агента из непонятных мест в графе создателей пока непонятно ещё чего (потом это будет целевой системой) имеют друг ко другу, о чём им надо договариваться, какой там может быть взаимный не только предмет интереса, но и интерес.

Повторимся: целевая система — это вид системы, поэтому для выявленной вами целевой системы вы должны положительно ответить на все вопросы чеклиста выявления любой системы. Собственно, наставления нашего руководства в существенной мере как раз и даёт вопросы для такого чеклиста. Вот только несколько пунктов:

• Мы думали о ней прежде всего как о чёрном ящике в момент её работы (а не прозрачном ящике в момент создания). Всё остальное мы думали только потом, после этого.

• Это вещь, а не процесс/метод. Но она, несомненно, что-то делает (или будет делать, если ещё не существует) в окружении, функционирует/работает по какому-то методу, выполняет какую-то функцию в окружении. Если речь шла о процессе/методе, то не забыли поинтересоваться двумя системами: одна агент-создатель (не меняет своего состояния, как молекула катализатора) и вторая — у которой меняется состояние. Но сам процесс не перепутан с системой! Это проверили три раза! Не забыли, что система может быть весьма неклассической (мероприятие, «договорка», игровая сессия), есть способы об этом думать как о вещи. Но метод — точно не система!

• Это не описание. Если уж речь зашла об описании, то проверили, что там за система описана этим описанием. Система физична, можно указать на место в пространстве-времени!

• Если есть слово «система» в названии, то мы его игнорируем (оно вполне может быть бытовым словом и сбивать с толку — типа «системы похудения»).

• Где проходят границы системы и какая её функция — договорились, она не «найдена объективно существующей». Что для вас «объективно», для других участников проекта будет пустой звук. Проверили, что эта договорённость известна всем участникам проекта и соблюдается.

• Отслеживаем, не поменялись ли договорённости, не поменялась ли система в ходе проекта: жизнь не останавливается, выявленные системы тоже меняются**.**

• В названии системы звучат слова из какой-то предметной области. Никаких «оборудование» или «потребительский товар» или даже «сервер» — любой такой широкий класс объектов в названии не участвует. Вы не назвали систему «зверь», поскольку один подумал о мышке, а другой — о тигре, и проблем разночтения с этим потом не оберёшься.

Про системы надо думать, применяя этот чеклист буквально. Если вы сказали, что «наш завод выпускает оборудование», то автор нашего руководства по системному моделированию ехидно заметит, что это оборудование хлебопекарное или сантехническое, а ваши сотрудники будут считать, что это оборудование, которое меньше всего вам придёт в голову. В предыдущих руководствах программы рабочего развития вам рассказывалось, что надо выбирать уровень абстракции, когда что-то говорите, нельзя использовать абстракцию на любом уровне, этот уровень надо отслеживать. Если фраза относится непонятно к оборудованию какого проекта (вашего или не вашего, слишком общо сформулировали), то лучше бы вы её не произносили. Это общая ошибка — говорить фразами из учебников инженерии и менеджмента, которые приложимы ко всем ситуациям вообще. Поэтому при обсуждении рабочих проектов такие фразы смысла не имеют, если вы не обсуждаете сами эти принципы инженерии и менеджмента, а обсуждаете свой рабочий проект.

Хорошо подвешенный язык не спасёт, спасёт следование наставлениям руководства, для этого их надо знать. Хорошо подвешенный язык просто продемонстрирует, что вы плохо формулируете мысли, мутно доносите содержание.

Буквальное применение чеклиста такое: если сказано, что система это вещь, а не поведение вещи, то «у меня системой является увеличение производительности труда» — показывает, что вы глаголы от существительных не отличаете (вы говорите «система = увеличение», но увеличение — это не вещь, место увеличения::процесс::поведение в пространстве-времени вы не покажете). Если попытаетесь заменить систему с «увеличения производительности труда» на саму «производительность труда», то производительность — тоже не вещь, а характеристика труда, а если попытаетесь заменить производительность труда на сам труд, то труд — это опять-таки поведение, а не вещь, тоже не проходит чеклист. И если вы не включаете думалку, то подряд несколько раз при попытке выявить систему (не только целевую, но любую) будете выглядеть нелепо, ибо покажете окружающим вас людям, что не в состоянии разобраться, что в мире занимает какое-то место в пространстве-времени, а что — только описания, свойства, поведение чего-то в материальном мире (есть много ещё чего, кроме вещей).

И так буквально надо воспринимать все пункты чеклиста по выявлению систем, а также все наставления наших руководств. Руководства говорят, как лучше делать вашу работу, чтобы быть умным. На работе надо работать: быть умным и не делать много ошибок, платят (даже если ваша работа заключается во владении фирмой) за это.

Целевая система зависит от того, кто её ищет

Обычное дело, когда на каком-нибудь заводе топ-менеджеры признают, что 50% сотрудников не знают, что выпускает предприятие — у них перед глазами только какие-то части каких-то систем времени создания, а вот что там из этого становится инструментами создания целевой системы, а что — самой целевой системой, за какие характеристики целевой системы платятся деньги, как связана их работа с этими деньгами, как вообще выглядит целевая система в момент эксплуатации — это неведомо. Это плохо, ибо это означает, что многие люди принимают неоптимальные решения: они буквально не знают, что надо сделать, чтобы целевые системы становились лучше. Надо сделать вес детали поменьше, или прочность повыше, или цену поменьше, или класс обработки поточнее при заданном бюджете — что важнее? Это зависит от того, куда эту деталь планируется поставить. А если ты не знаешь? Решение будет «какое-нибудь», и так будут приниматься «как-нибудь» сотни и тысячи решений. По поводу целевой системы обязательно надо договориться.

Вы менеджер системы создания, хотите поднять производительность труда, поднять скорость выпуска продукта. Если это сервис, то там тоже надо поднимать скорость выпуска продукта, но продукт этот «на давальческом сырье» — вы просто меняете состояние не вашего материала, а материала чьей-то чужой системы. Но это и будет целевая система: то, что вы изменяете вашим проектом в целом, вашим мастерством и инструментарием на выходе большого графа создателей. Проект определится масштабом коллективных договорённостей в вашей организации. Так как определить скорость выпуска продукта, нельзя же её поднимать, не зная, что это? Выпуск — это количество экземпляров целевых систем, которые изготавливает проект системы-создателя (то есть количество экземпляров готовых систем на выходе всего графа создателей целевой системы). Скорость выпуска — это выпуск за небольшую единицу времени. Скорость — это название первой производной по времени от какой-то величины, а производные определяются по отношению к «дельтам» как малым величинам. Так что следим, чтобы это не было «систем в год», цельтесь в минимальную единицу измерения — секунды, дни, но не месяцы и годы, ибо вы слишком поздно будете знать ваши результаты, чтобы что-то менять как операционный менеджер.

Если неизвестно, что такое «целевая система» (класс/тип продукта/изделия) и сколько вы их выпускаете за период времени — неизвестна скорость выпуска. Если скорость выпуска (проход/throughput, но нас волнует не денежное выражение, а натуральное выражение) неизвестна, то нельзя сказать, как какое-то организационное изменение, которое вы затеяли, на неё влияет. Надо договориться, что же является целевой системой, все расчёты выпуска дальше вести для неё, а не для какой-то другой системы.

Первое, что должно интересовать менеджера — это целевая система, а не граф её создателей, за который менеджер формально ответственен. Менеджера не должно сначала интересовать предприятие::создатель::система. Ибо если не знаешь, что должен создавать, то никакое решение по поводу создателя не будет осмысленным. Сначала «что надо создать» — потом думаем о том, «каким методом будем создавать», потом «кто будет создавать, умеет ли он такое делать».

Надо ли нам увеличить число сварщиков, чтобы ускорить выпуск продукции? Ответ на этот вопрос будет понятным, только если мы пробежимся по системной мантре:

• Что делает целевая система в системном окружении.

• Из чего её надо делать, чтобы она могла это делать.

• Каким методом надо систему делать, нужны ли там вообще роли сварщиков для этих методов.

• Какой там граф создателей, который будет создавать и развивать систему, какими методами мы будем делать создателей. Какие границы «мы» в исходном вопросе? Где «мы» на этом графе? Нужны ли там роли сварщиков для создания и развития систем в графе создателей?

• И только тут можно будет прикинуть, надо ли увеличивать число сварщиков по методу критической цепи¹ или какому-то другому методу принятия решений в операционном менеджменте.

Это очень тонкий момент: вам надо не целевую систему строить такую, какую может сделать ваша организация, а организацию (создателя) делать такого, какой сможет выпустить целевую систему. А целевая система должна быть такой, чтобы она была успешной. Если вы плохой повар и будете печь пирожки уж как сумеете (но шикарно организуете предприятие, будете печь плохие пирожки быстро и дёшево), то заниматься вы будете этим только пока деньги инвестора не кончатся. Вам придётся-таки разобраться с целевой системой:

• Какие пирожки должны быть, чтобы они были кому-то нужны (сегодня говорят ещё жёстче — не «кому-то нужны», а «снимали чью-то боль», то есть очень и очень нужны, а не просто «могли бы пригодиться»).

• Какое мастерство и какие инструменты должны у вас быть, чтобы выпускать хорошие пирожки.

• И только после этого можно заняться предприятием, до этого момента надо разбираться с пирожками.

• И пока вы будете заниматься предприятием, надо не забывать заниматься пирожками: они могут успеть перестать быть нужными или может оказаться, что нужны немножко другие пирожки, для которых нужно будет перестроить граф создателей (вместо пирожков с вишней начать выпускать пирожки с мясом  — и там всё по линии приготовления начинки в графе создателей придётся переделывать).

Это крайне важно: в мышлении целевая система должна быть сначала, а предприятие-создатель (и даже весь граф создателей) потом. Менеджер, который объявляет целевой системой свою организацию — ошибается, ибо он теряет возможность договорить всех в рамках всего проекта, в рамках всего графа создателей. Как минимум, он может не договориться с клиентами, мнение клиентов по поводу его восхитительного предприятия будет негативным, поскольку клиентов волнует целевая система и не волнует предприятие. Поэтому лучше бы целевая система у менеджера и клиентов была одной и той же. Ещё ведь есть и инженеры-технари (они будут называться по-разному: садовники, учителя, конструкторы радиоэлектроники), но и с ними у менеджера хорошо бы, чтобы была общая цель. У менеджера булочной целевая система — булочки, а не булочная! А булочная? Она у менеджера — создатель целевой, её создадим и будем развивать как одну из систем в графе создателей. Но сначала — определимся, булочки там или бульдозеры. И договорим всех, что булочки, а не бульдозеры. Договорим всех — это сильнее, чем «договоримся со всеми», ибо если вы договоритесь с A и B, и они потом передоговорятся между собой, то ваша договорённость с ними нарушится. Если вы договорите не только себя с A и B, но и их между собой, то и ваши договорённости будут стабильней. По поводу целевой системы надо договорить всех в проекте, чтобы не было того, что половина людей в графе создания делает булочки, а вторая половина — бульдозеры, а информационные системы (включая AI) там поддерживают создание вертолётов (поэтому бульдозеры ещё хоть как-то получаются, а булочки — никак, и мало вообще понятно, что происходит и почему). Спросите, что именно (вот буквально: комплектация, характеристики, состояние в ходе работы) выпускает и с какой скоростью ваш проект — вы будете удивлены разнообразием ответа. Но каждый отвечающий будет уверен, что все остальные прекрасно понимают, что там за целевая система и какая скорость её выпуска! При этом понимаю, конечно, ровно так же, как они сами. Ваша задача — заранее знать, что понимание у всех разное, а дальше договорить всех по поводу этой целевой системы.

Целевая система определяется субъективно, «система в глазах смотрящего», поэтому вопрос определения «системы, которую вы хотите сделать» начинается с внимания к тому, кто такие «вы»: сколько вас, какие у вас интересы. Системное мышление — это мышление коллективной/групповой деятельности, с его помощью большие команды договариваются в проектах с целевыми системами на миллионы индивидуальных деталей каждый экземпляр, с сотнями и тысячами предприятий в графе создателей таких огромных систем. В разделении труда задание общей для проекта целевой системы важно, чтобы удержать внимание разных агентов в самых разных ролях на их общем важном (целевой системе!), чтобы без потери этого внимания к системному целому позволить заботиться о деталях подсистем отдельным членам каждой команды.

Что делать, если вы директор по развитию огромного холдинга, в котором сотня проектов по созданию и развитию сотни разных видов целевых систем, обширнейшая номенклатура продуктов и сервисов? Для начала надо понять, что разобраться разом со всеми этими целевыми системами не получится. Надо будет всё равно разбираться с каждой системой, не переобобщая. Иначе у вас получится какое-нибудь «оборудование» или «мастерство» — и невозможно будет осмысленно на этом уровне общности обсуждать хоть что-нибудь. Для начала надо разобраться с каждой целевой системой в каждом проекте, и только потом поглядеть на их общую систему-создателя, из частей которой будут составлены организации-создатели каждой из целевых систем — и обсудить, насколько общи получаются в своих частях графы создателей, насколько конкурируют за ресурсы проекты создания и развития отдельных целевых систем (и ещё проекты создания и развития систем из графа создателей, они ведь тоже берут ресурсы!).

Всё равно надо начинать с целевых систем, только не обобщая: брать проекты по одному. А если махнуть рукой и делать «просто холдинг»? Не получится! Если не знать, чем именно занимается холдинг, какая его стратегия (какими методами мы будем учить холдинг работать, какие целевые системы будут успешными, если действовать этими методами) — ничего не получится, кроме дикой путаницы и разбазаривания ресурсов на недоделанные проекты. Не надо лениться, надо разбираться с отдельными целевыми системами отдельных проектов, хотя и в этом деле можно задействовать разделение труда.

Для выявления целевой системы нет строгих правил, алгоритма, последовательности мыслительных шагов, порядка опроса каких-то людей, типологии случаев/cases (это предпринимательская/творческая/исследовательская задача! Нет алгоритма предпринимательства/творчества/исследования, есть только порождение догадок и отвод их критикой!). Так или иначе в решении по поводу выбора целевой системы будут участвовать самые разные агенты в самых разных ролях, пытающиеся удовлетворить самые разные интересы самыми разными методами работы, причём речь идёт не только о членах команды создателей целевой системы, но и о внешних ролях. Если у вас проект, который вы можете сделать в одиночку, то вам не потребуется развёрнутого системного мышления, хватит его обрывков. Но если проект сложный и работает группа, то в принятии решений заведомо будет сложный переговорный процесс и о целевой системе придётся договариваться по ходу дела.

Обычно целевую систему нельзя определить, сидя на своём рабочем месте и размышляя: требуется не только читать самые разные документы и хорошо знать свою предметную область, но встречаться и разговаривать со многими людьми, а иногда и делать эксперименты, в том числе реализовывать макеты, прототипы. Иногда даже говорят, что пока не вылез из рабочего кресла и не пошёл общаться с разными агентами, системного мышления не происходит — ты ничего не будешь знать про целевую систему, ничего не будешь знать о том, по поводу чего все договорились, и договорились ли.

Не нужно путать:

• «нашу систему» (MySystem, OurSystem, engineered system «мою» личную, или «нашей маленькой команды») и

• целевую систему, которая общая для многих команд, и по поводу которой эти команды договариваются.

Без целевой системы нельзя разобраться и с «нашей системой»: для неё прежде всего должно быть понятно, где она находится: в подсистемах ли какого-то уровня целевой, в надсистемах целевой, в системах графа создателей. Если не разобраться, каким образом наша система даёт вклад в создание целевой системы — наша система не будет успешной, вы не сможете объяснить, почему команда-создатель вашей системы имеет какие-то вопросы к другим командам, создающим какие-то другие системы. А если есть целевая система — с кем бы вы ни разговаривали в проекте, вы члены одной команды создателей!

Да, если сделать «нашу систему» удовлетворяющей именно нашим командным интересам (или даже интересам непосредственного заказчика нашей системы — внешней проектной роли нашего подпроекта создания целевой системы) — мы будем счастливы, наши интересы учтены, и даже интересы заказчика нашей системы учтены, но успех всего проекта создания целевой системы в целом определяется главным образом успехом для внешних ролей проекта целевой системы, а не успехом для ролей нашей маленькой команды и даже внешних ролей нашей маленькой команды!

«Нашу систему» мы, конечно, сделаем, и потребуем оплаты за наш труд. Но деньги обычно платят за целевую систему: нет связи нашей системы с целевой — не будет денег за работу, проект нашей системы можно сразу не делать, а если мы ухитрились как-то договориться об оплате, то эту оплату найдут способ не сделать: если наша система никак не помогает создавать и развивать целевую систему, то как вообще можно за неё платить из денег общего проекта?

Похожее рассуждение будет и в тех случаях, когда речь идёт не об оплате деньгами, а преследовании каких-то других целей. Например, если делаешь какой-то политический проект и выполняешь в нём какую-то небольшую часть, инвестируя собственный трудовой ресурс и ожидая от реализации нашей системы и в конечном итоге целевой системы неденежных результатов.

Каждый проект уникален своей целевой системой и методами её создания. Уникален не только вид целевой системы, уникальны и создатели в их графе, уникальны методы работы создателей и степень мастерства создателей в этих методах. Каждая ситуация в работе по каким-то методам с каким-то типом систем уникальна, так что ничего нельзя будет запомнить и применить потом в том виде, в котором запомнили — в одну реку нельзя войти дважды, одну и ту же систему нельзя сделать дважды одинаковым способом.

Даже если вы (как команда!) подряд второй раз делаете что-то очень похожее, то у вас по сравнению с первым разом появляется опыт, вы лучше знаете риски, чем это было в первый раз, имеете больше информации — и вы уже на основании этого опыта можете принять совсем другие решения, по-другому организовать работу, не повторить тех ошибок, которые были допущены в первый раз. Создание системы может задействовать какие-то одни методы работы, но развитие системы может подразумевать замену методов работы. Скажем, первый раз вы забивали гвозди микроскопом, но вот второй раз вы это вряд ли уже будете делать — вы учтёте неудачный опыт первого раза.

«Запомните метод, как мы это делали и всегда так делайте» — это не про системное мышление, системное мышление привлекает внимание к важным в мышлении объектам, но самого мышления не отменяет, и прежде всего мышления о системах в их окружении, а затем методах работы по созданию этих систем. Доставать голову из кармана и думать придётся в каждом проекте, для каждого создаваемого инкремента функциональности системы при развитии системы: системное мышление помогает ставить вопросы, но искать на них ответы, беседовать с самыми разными людьми, принимать решения после этих бесед всё равно придётся. Системное мышление даёт типы объектов для вашего мышления, но оно не мыслит за вас: что делать дальше с этими объектами — это всё одно остаётся вашему прикладному мастерству и вашему фундаментальному мастерству мышления (интеллекту, это его вопрос: что делать, когда неизвестно, что делать — каким методом работать, когда метод неизвестен).

И ещё раз напомним, что рассуждения по поводу достижения коллективных договорённостей по поводу целевой системы, «выявления системы» (как и все остальные рассуждения по проектированию системы) обычно делаются «в классах/типах», с типами систем, а не с индивидуальными системами-экземплярами/индивидами. Да, вы работаете в уникальной ситуации, но как бы ни были уникальны проекты и системы, всё равно делается попытка максимум знания перетаскивать из проекта в проект, накапливать знание, повторно использовать знания, акцентировать работу с паттернами, а не с индивидами. Даже если вы делаете что-то типа Эйфелевой башни, всё равно работать вы будете с типами, индивиды появятся только при изготовлении и сборке конструктивов разных системных уровней целевой системы.

Все системы в глазах самых разных смотрящих, так что потребуется

• самому делать догадки по поводу целевой системы (придумывать эти догадки самостоятельно, или беседовать с разными людьми, если вы недавно пришли в уже давно ведущийся проект). Это вы «выявите целевую систему» для себя самого, но это ещё не значит, что эта целевая система стала целевой системой всего проекта. Поэтому

• дальше вам надо договориться с командой и внешними проектными ролями про целевую систему (а если вы организатор проекта, то не договориться с ними, а договорить их всех между собой — и заодно с вами), и про надсистему с системами в ближнем и дальнем окружении. Это будет рассмотрение целевой системы как «чёрного ящика», создание концепции использования.

• И только после этого обсудить подсистемы (целевая система как «прозрачный ящик», функциональная декомпозиция) и из чего их делать (концепция системы — какими конструктивами-аффордансами будете воплощать подсистемы).

• обсудить методы создания целевой системы, то есть способы изготовления, сборки, испытаний, пуска в эксплуатацию целевой системы, общий метод создания и развития (систему надо будет не только создать как MVP, но и развивать, выпускать много версий, может быть даже выпускать каждую версию мелкой серией или даже налаживать крупносерийное производство).

• И только после того, как методы создания целевой системы стали известны, можно обсудить, какие роли нужны для поддержки этих методов создания,

• и дальше уже обсуждать самые разные системы создания (включая команду как одну из систем создания!) по всему их графу, учитывая мастерство этих создателей в необходимых методах работы, а также наличие инструментария для этих методов,

• и ещё помнить при этом про «нашу систему» во всём множестве этих систем проекта.

Конечно, это мы опять в краткой форме изложили мантру системного мышления. Нужно только ровно так и рассуждать, во всех проектах, это и есть норма системного мышления: не только читать о том, что так надо делать, а брать — и делать. Не надо только читать, что обычно люди чистят зубы и принимают душ. Надо ещё и чистить зубы (хотя не хочется) и принимать душ (хотя лень). Вот с системным мышлением так же: лень, а надо. Вздыхайте — и думайте по системной мантре, пока не привыкнете делать это «на автомате», всё время, во всех проектах, подпроектах, разговорах с друзьями про их проекты, задаваясь этими вопросами при участии в беседах. Вот это — системное мышление!

Конечно, каждый участник проекта (а взаимосвязанных проектов тут может много обнаружиться, так что и участники других проектов тоже) имеет по поводу целевой системы проекта своё мнение, отличное от других. И участники проекта могут ещё и менять это своё мнение по поводу того, что является целевой системой проекта — прямо по ходу достижения между ними самых разных договорённостей (договорённости-то именно про это: про изменение мнений, было одно мнение — договорились о чём-то, это означает, что кто-то начальное мнение поменял).

Что делать в такой ситуации, когда мнения расходятся?! Непрерывно договариваться, проверять сохранение договорённостей — и продолжать договариваться всё время проекта, а не только в начальный его момент. А если вы организатор — ещё и непрерывно договаривать всех вокруг себя.

Вы к этому быстро придёте, когда поймёте, что любые ваши договорки будут нарушаться, если их участники в момент достижения ваших договорённостей ещё не договорились между собой. А потом они договорятся — и их договорённость окажется сильней договорённостей с вами, а когда вы договоритесь с ними по-новой, они опять передоговорятся — и опять ваши собственные договорённости с ними не устоят. Поэтому лучше бы вам самому их договорить — и достичь коллективной договорённости, она будет более стабильной.

Системы создаются коллективно, в этих коллективах договариваются. Системное мышление помогает определить, по поводу чего договариваться. Прежде всего — по поводу того, что именно мы делаем: какая система является целевой, т.е. успешность какой системы будет ключевой для проекта. Нет договорённости по поводу целевой системы — коллективно не знаем, что делать, каждый делает что-то по своим представлениям. Добра в такой ситуации не будет.

Легко не распознать эту ситуацию, когда в речи и документах лишние генерализации. Если мы делаем «обувь», то это не означает, что договорились. Я считаю, что это женские босоножки 36 размера, соседи посчитали, что это мужские зимние ботинки — и разработали для них шнурки. Да, всё это «обувь», но при встрече этих уже разработанных шнурков с уже разработанным верхом босоножек у обеих команд будет сюрприз. А если подмётку «обуви» поручили делать третьей команде, то можно только догадываться, что им придёт в голову — валенки? Есть только один способ: специализировать в договорённостях целевую систему по максимуму и гарантировать, что результат договорённости по поводу целевой системы известен всем командам.

Почему так сложно определить систему? Потому как в культуре может ещё не существовать понимания удобного системного уровня, на котором определяется система.

Скажем, вы пытаетесь предложить новый способ создания стены из крупных блоков, но строят в этот момент только здания из кирпича (а понятия «стена» нет, только кирпичи). Мы приводили этот пример, когда говорили о системном мышлении, которое помогает бороться со сложностью: осмысленных операций с кирпичом в здании нет, но понятие «стена» может быть ещё не сформировано, поэтому с ним и не работают! Идея определить стену как систему, да ещё и дать её альтернативную конструкцию может быть очень, очень свежей!

Один из реальных кейсов: требовалось создать систему транспортировки самолётов с одного из аэродромов до завода-изготовителя, это нужно было для ремонта. Для этого где-то нужно было увеличить проём ворот, где-то добавить крепления на вагоне, где-то соорудить дополнительный пандус. Но все эти задачи решались как отдельные проекты, «по мере возникновения», у них не было общего финансирования (и деньги выделялись не сразу все, а на каждый проект отдельно, и нужно каждый раз было устно объяснять, зачем нужно потратить ту или иную сумму и выполнить ту или иную работу, общего списка работ не было). Не было понимания, что это всё нужно сделать, чтобы появилась «система транспортировки самолёта как целевая», не было в языке названия этой «системы транспортировки самолёта», не было проекта, не было менеджера проекта, был только человек, который был озабочен организацией транспортировки самолёта (хотя и проекта формально не было, и в голове этого человека не было «системы транспортировки самолёта», только где-то было желание ворота расширить, где-то крепление на прицепе переделать — но это не воспринималось как какие-то операции с «системой транспортировки самолёта»). Как только было осознано, что речь идёт просто о разных частях системы транспортировки самолёта, и если не сделать хоть один из этих проектов, то самолёты не будут проходить путь от аэродрома до завода, не будут ремонтироваться — всё волшебно наладилось, был назначен менеджер проекта, выделено финансирование, нашлись внешние проектные роли. При этом целевой системой был именно самолёт в точке окончания транспортировки, а система транспортировки — «наша система», создатель «самолёта в точке назначения».

В человеческом движении уровень мышц и костей — это совсем не тот уровень, на котором мы можем говорить о том, как строить движения тела, в теле только мышц выделяют более семисот. Понятно, что при движении человек не управляет сотнями мышц, он удерживает во внимании другие объекты. А тело в целом — это слишком высокий системный уровень, двигаем-то частями тела, да ещё и воспринимаемыми изнутри. Пришлось найти пропущенный ранее системный уровень: мышечные «ленты» (часто говорят о «линиях», о «струнах», ленты мы говорим, чтобы легче было разговаривать о скрутках этих лент, а ещё «мышечность» их условна — там участвуют и мышцы, и связки, и фасции, и сухожилия, так что «опорно-двигательные ленты» было бы вернее), соразмерные человеческому телу, воспринимаемые изнутри как такой специальный функциональный орган, конструкцию которого выполняют в разных позах разные кости, мышцы, фасции, сухожилия. Этот функциональный орган присутствует в сознании движенца как один объект, с которым и работают. Объяснения того, как двигаться, становятся короче точно так же, как в случае присутствия стены между уровнями кирпичей и дома, присутствия транспортной системы между отдельными хитрыми приспособлениями на пути самолёта и «системы ремонта самолётов»::надсистема.

В одном из проектов менеджеры-основатели фирмы/предприниматели собирали по чуть-чуть железнодорожным транспортом отдельные фракции отходов нефтеперегонки в прибрежные огромные хранилища. Потом сливали эти фракции одной большой порцией/лотом (порция для торговли, для сделки, для обработки) в танкер, отправляли на завод (мелкие партии сырья завод не принимал), и там перерабатывали в весьма дорогой продукт. Какая была их целевая система? В чём был секрет их бизнеса? Они создавали лот (ибо меньше лота определённой величины заводы исходную фракцию нефти не принимали в переработку). Как только «лот» был осознан как целевая система, фирма запустила ещё несколько проектов по той же схеме. Без этого всё предприятие выглядело как случайная стратегическая/предпринимательская/визионерская находка, разовый проект. Конечно, лот упоминался во всех разговорах — целевые системы часто присутствуют в речи. Но дело двинулось только после того, как было осознано, что именно лот — целевая система, а не десяток других систем, которые мелькали в обсуждениях.

Целевая система в начале проекта находится вне внимания. Её упоминают обычно в первые пять минут разговора, иногда даже называют, но людям в голову не приходит, что они ищут именно её. Но когда эта система находится (на неё обращают внимание, именуют и вводят в проект явно как целевую систему, по поводу которой все договариваются), жизнь становится много, много проще.

Ещё раз: никаких алгоритмов, рецептов, лайфхаков по определению целевой системы нет, это исследовательские догадки/«предпринимательские гипотезы»/негарантированное визионерство, творчество, что «по алгоритму», «по рецепту», «по лайфхаку», «по процедуре» или ещё как-то «по правилам» невозможно. Наоборот, вместо помощи в догадках системное мышление даёт множество способов критики предлагаемых догадок по поводу того, что будет целевой системой в проекте, и реализовывать нужно (понимая, что это всё только гипотеза/догадка) лучшую из выдержавших критику. Это подробно рассматривается в рамках методов исследований (на базе лучших объяснительных теорий того, как они устроены, сегодня это развитие идей попперианской эволюционной эпистемологии) и рациональности (на базе лучших сегодняшних объяснительных теорий о том, как строить действия в условиях неопределённого будущего).

Тем самым вы должны высказывать на базе вашей интуиции (возможно, коллективной! Хорошо организованные совместные рассуждения многих агентов, да ещё поддержанные компьютерным моделированием!) догадки/гипотезы о целевой системе и далее разворачивать от этих догадок системы создания и критиковать эти догадки, прогоняя их через многочисленные эвристики, которые приведены в наших руководствах по программе рабочего развития. Вспоминаем чеклист для проверки догадок по поводу систем из предыдущего раздела. Этот чеклист можно продолжать и продолжать, используя все подсказки по критике и поиску ошибок в договорённостях по поводу систем из нашего руководства.

Целевая система добавит ещё несколько пунктов. Например, несоблюдение вот этого пункта делает проект «дохлым»:

• совокупная стоимость владения системой должна быть меньше оценки пользы от её использования/эксплуатации.

Но если всё это оказалось соблюдено, то вы (вероятно! Это прогноз/гипотеза/догадка! Гарантировать ничего нельзя!) нашли целевую систему — и поэтому должны взять эту догадку всерьёз, то есть строить проект создания и развития системы исходя из этой догадки.

Моделирование: целевые системы

Заполните табличку по целевым системам от трёх рабочих проектов, в которых вы участвуете. Не забудьте проверить эти целевые системы по чеклисту.

Системы-продукты и сервисы/методы провайдеров/создателей

Целевая система раньше часто мыслилась как поставляемый товар (какая-то вещь, изготовленная для продажи): продукт/изделие::система::«физический объект», в разных отраслях это может иметь разные названия, например, в строительстве — здание или сооружение, которые не принято называть продуктами или изделиями, но по сути — это то же самое**.**

Продукт/изделие изготавливается его создателем обычно из закупаемого этой командой сырья, а затем физически поставляется его конечному потребителю для использования, условно «пересекает границу предприятия», меняет собственность. И уже в собственности у потребителя этот продукт/изделие выполняет свою роль/функцию, работая в составе надсистемы в ходе эксплуатации. После перехода собственности потребитель продукта/изделия::система использует его двумя способами:

• в составе уже своей целевой системы как конструктив-аффорданс (например, ваши часы-продукт ваш клиент устанавливает в свой автомобиль-продукт, а затем продаёт автомобиль как продукт уже своему клиенту, и часы показывают время в ходе эксплуатации автомобиля)

• в составе систем из графа создателей его продукта (например, ваши часы-продукт он устанавливает в свой цех на стену, чтобы рабочие могли следить за временем в ходе сборки ими автомобиля как уже его продукта, а затем продаёт уже своему клиенту автомобиль без ваших часов или с какими-то другими, не вашими часами. Ваши часы оказываются эксплуатируемыми в составе цеха, системе из графа создателей автомобиля).

Альтернативный вариант — считать сразу, что целевая система — это будет продукт не у вас, а у клиента, который пришёл к вам со своим сырьём — недоделанным продуктом, своей целевой системой, предметом сервиса/метода. Работа ваша идёт не с вашим сырьём и у вас нет передачи вашего продукта заказчику, вы как создатель продукта своего клиента только работаете по методу-сервису, используя своё мастерство и свой инструментарий этого метода (сервисной, обслуживающей) работы. Работа идёт над сырьём заказчика ваших работ и продукт остаётся у заказчика ваших работ, в его собственности. Вы лишь меняете состояние каких-то систем, которые принадлежат на этот момент не вам и потом войдут в состав или продукта заказчика, или в состав инструментария заказчика (хотя тут надо быть аккуратней: если вы работали над обучением сотрудников заказчика, то рассуждение сохраняется, только мастерство сотрудников трудно считать инструментарием, да и как «сырьё» они очень условно принадлежат вашему заказчику). В принципе, рассуждение тут чуть сложней, потому как сервисы и методы работы, конечно, по цепочке отслеживаются вплоть до какой-то системы, но в жизни часто может встретиться и какая-то работа с информацией (описание системы — проектирование «железной» системы, обработка данных эксплуатации и т.д.). Большинство рассуждений про методы и сервисы работает и тут, это необязательно именно изменение систем, но обязательно, что все эти изменения самых разных объектов как-то отслеживаются по всей (возможно, очень длинной) цепочке изменений до целевой системы. И если отследить не удаётся, то ставить выполнение этих работ под вопрос, может их и не надо делать, ничего ведь к лучшему не изменится. Контрольный вопрос: «а если работ этого метода/сервиса не делать, что будет с целевой системой?». Если это работы с создателем, то дальше по цепочке: «а потом этот создатель что лучше сделает для целевой системы»? Если рассуждение не дотягивается до целевой системы по какой-то цепочке причин-следствий, то всё плохо: вы, похоже, встретили маскировку никому не нужной работы (хотя, конечно, агенту, которому заплатят за ненужную для создания целевой системы работу, эта работа очень нужна — он хочет за неё денег, или хочет потренировать своё мастерство, или ещё хочет что-то локальное «для себя», но не глобальное — для всего проекта создания целевой системы).

Даже со всеми нюансами ситуация выполнения сервисных работ сводится к тому, что никакого продукта/изделия у вас в проекте не будет, но вы просто примете участие в работах создателей какой-то целевой системы по какому-то методу, и даже не непосредственно создателей, а каких-то работах создателей из графа создателей, достаточно далеко от целевой системы. Метод, которым вы меняете состояние чужих систем (чужой целевой системы, чужих конструктивов, которые потом составят чужую целевую систему, или даже чужого инструментария в графе создания), называется сервис/service/услуга.

Ваши тут будут только работы/поведение/изменения по вашему методу (то есть работы вашего мастерства и инструментария по знаниям/теориям/алгоритмам метода) вас как создателя над не принадлежащей вам целевой системой, изменение её состояния. Вы будете тут только системой создания, ваша команда будет предоставлять клиенту только внешнее поведение — работы сервиса.

В литературе (в том числе англоязычной, там та же ситуация, что и в русском языке) можно найти много разных мнений, что такое «сервис»², основные из них:

• Сервис/провайдер, роль агента, выполняющего работы над предметом метода работ — например, автосервис как провайдер работ по методам ремонта автомобилей, микросервис — софт как провайдер работ по методам обработки данных (редкое использование «сервиса» для неодушевлённых систем).

• Сервис/работа по методу над чьими-то предметами, например «получил сервис для клиентского автомобиля» (выполнены работы не указанного метода сервиса для автомобиля::предмет клиента).

• Сервис/метод выполнения работ над чьими-то предметами, например, «выполнил сервис клиентского автомобиля» (выполнил неспецифицированный метод работ, то есть работу по методу для клиентского автомобиля).

По-русски «службой» называют и service::процесс (метод, разворачивающийся во времени паттерн действия, наблюдаемый извне паттерн работы) «оказания услуги»::работа (слова оказание/проведение/выполнение тут указывает на то, что метод ещё должен быть реализован работой), и ту систему, которая вызывает это поведение, т.е. server/слугу/provider. И это иногда функциональный «слуга» (роль), а иногда конструктивный (агент). Изредка «сервисом» называют ещё и интерфейс между «слугой» и изменяемым этим слугой внешним миром.

В нашем руководстве мы придерживаемся мнения, что сервис — это метод выполнения работ (различаем сервис как метод работ, общий для всех работ какого-то сервера/роли и работы сервиса/метода), а роль, выполняющая метод/сервис, называется server/«service provider»/сервер/служба/провайдер. Тем самым есть и синонимия роль/провайдер/служба, но там те же проблемы, что и с роль/stakeholder (то ли оргроль::«функциональный объект», то ли оргзвено-в-роли::«конструктивный объект», примером тут будет — «то ли принц Гамлет, то ли Вася Пупкин»).

Мы всё-таки придерживаемся мнения, что провайдер — это оргроль (сервер всё-таки чаще используется, когда речь идёт об инструментах какого-то агента, хотя в русском языке сервер часто переводят как «служба», и тогда это тоже может быть оргролью, а не ролью инструмента).

В проектах провайдер — это обычно условно-внешняя проектная роль. Условно-внешняя — внешняя, ибо работает «чужой над нашим материалом», а формально — внутренняя/командная, ибо в нашем графе создателей, работает в составе общей расширенной команды (состоящей из множества отдельных команд в большом графе создателей) над общей целевой системой. Если речь идёт о провайдере как роли, можно назначать сервис-провайдером какого-то сервиса/метода одно или другое оргзвено в ходе оргпроектирования.

Тем самым сервис пополняет синонимический ряд метод/способ/практика/стратегия/культура/стиль/сервис, причём используется главным образом тогда, когда речь идёт о работах создания над чужим материалом. Сервис — это метод для работ создания (самых разных, например, измерения/описания, изменения в физическом мире, предсказания/проектирование), проводимых над чем-то внешним, «чужим», «на давальческом сырье». Если речь идёт о сервисе «забивание гвоздя», то речь идёт том, чтобы взять оргзвено, исполняющее роль провайдера/службы и заставить его выполнить работы его метода/сервиса (работы забивания::метод/сервис) для нашего гвоздя. Если сами будем забивать гвоздь, то всё то же самое, только не будем использовать терминологию сервиса и провайдера/службы.

Конструктивный объект (оргзвено) как функциональный объект (служба/провайдер/роль) выполняет работы сервиса/метода над предметом метода. Наш плотник забивает наш гвоздь: «забивание гвоздя»::«метод работы для изменения состояния гвоздя», плотник::роль. Чужой плотник забивает наш гвоздь или наш плотник забивает чужой гвоздь: «забивание гвоздя»::«сервис/метод для изменения состояния гвоздя», плотник::провайдер/роль. Всё то же самое, слова другие и в словах — отсылка на «внешнесть» (при этом можно долго ещё обсуждать, что там «наше», а что «не наше», об этом надо будет коллективно договориться. Собственность в экономике определяется не как то, что вы считаете своим, как то, что считают вашим окружающие вас люди, с чем они готовы согласиться).

Для неодушевлённых создателей (инструментарий: станки, измерительные инструменты/instruments, инструменты/tools, гаджеты, оборудование и аппаратура) всё то же самое: молоток просто обзовут не провайдером сервиса (но так могут обозвать владельца молотка), а сервером (при этом даже «сервер сервиса» будет звучать как «масло масляное»: «работник работ», «служение службы»). Молоток::сервер/инструмент::создатель в роли «забивала» выполняет сервис «забивание»::метод::поведение над меняющим своё состояние объектом «гвоздь».

Мы не очень различаем в рассуждениях про системы в графах создателей (если речь не идёт о проектных ролях, играемых агентами, вырабатывающими свои стратегии по достижению своих целей — молоток не может играть трудовую/проектную роль! Молоток не актёр, его не принимают на работу!) живые и неживые системы, сервером/службой/провайдером/слугой/server у нас может быть и предприятие, и человек, и просто какой-то инструмент, разница тут больше терминологическая. Их метод работы как создателя по изменению чего-то не их собственного — сервис.

Мы уже встречались с ситуацией, когда системы классифицировались на основании их принадлежности каким-то владельцам, это системы систем (SoS). С сервисами то же самое: речь идёт просто о работах каких-то создателей, только не над собственным продуктом или собственным создателем в графе создателей собственного продукта (например, инструментарием для реализации какого-то метода), а над чужим продуктом или чужим создателем, например, чужим инструментарием. Если вы пришли поточить кому-то ножи на его кухне, и это не ваши ножи и не ваша кухня — то это вы пришли «оказать сервис», «выполнить работы сервиса»/«выполнить работы по методу».

Сервис «забивание гвоздя» может оказаться функцией/методом/способом в составе более крупного метода, работающего над более крупной ситуацией: скрепления досок, подготовки крепления для картины на стене, устранения царапающего гвоздя и т.д.

Так что не удивляйтесь, когда про один и тот же предмет, один и тот же продукт и его одно и то же поведение вы услышите два совсем разных разговора по части терминов: это специфика интересов. Сервис — это обычно про поведение создателя, метод его работы над «не своим» предметом, который должен поменять состояние в ходе работ сервиса. Сервис при этом — метод (забить гвоздь), а работы — задействования/оказания сервиса (забить десять гвоздей — это десять работ по методу «забить гвоздь»). Как и в случае метода, различаем оказание сервиса (выполнение метода) и сам сервис (метод). Бытовые выражения типа «предоставить сервис» по факту означают «предоставить сервер, который выполнит работу сервиса» (то есть предоставить оргзвено или инструмент, который исполнит работы, находясь в роли исполнителя работ по методу).

Внимательный инженер-менеджер уже заметил, что мы тут просто тренируем его нейронную сетку десятком повторений чуть разными словами одного и того же: агент, находясь в роли, выполняет работы по методу, меняя состояние предметов данного метода. Разница только в принадлежности предметов, меняющих состояние в ходе проведения работ по методу: для разной принадлежности (своё или чужое) терминология разительно отличается, слова все разные, а суть дела — не меняется. И в случае «чужого» целевая система для провайдера — вот этот самый предмет его сервиса. Для плотника и даже молотка целевую систему искать нужно там, где гвозди, даже если они не свои, а тебе их дали для забивания! Если вас позвали покрасить чей-то забор, и даже дали краску, то можно дальше выбирать — целевой системой является слой краски в правильных местах, или забор в целом, переведённый из состояния «некрасивый» в «красивый» видом методом/сервисом «покраска» (другой вариант методов/сервисов — «перестройка», «драпировка» и даже «ликвидация», ибо нет забора — нет проблемы его красоты).

В этом и сила системного мышления, сила мета-мета-модели: рассуждения с объектами внимания проводятся «в понятиях» на уровень абстракции выше, чем уровень рассказа о предметных областях.

Пример парикмахерской как сервис-провайдера

Давайте сделаем ход на конкретизацию, рассмотрим пример чуть сложней, чем плотник с молотком, забивающий чужой гвоздь. Парикмахерская (роль/провайдер, реализованная оргзвеном ООО «Чикчик») оказывает услуги/сервис по стрижке волос. Слово «сервис/услуги» указывает, что волосы там будут внешние, чужие, приносимые прямо на голове, «материал заказчика услуги». Рассуждения не меняются — идёт ли стрижка волос собственной головы или чужой головы, меняется только терминология, про свою голову говорят «провести работы стрижки::метод для волос», а про чужую — «оказать сервис стрижки волос». В «оказать сервис стрижки» и слово «сервис» тут как тип для «стрижки», наподобие того, как иногда для пущей убедительности говорят «система самолёт», а не просто «самолёт». Можно было бы сказать и короче, не упоминая тип «сервис» — «провести стрижку», и сразу становится неважным, это чужая голова или своя, язык методов и ролей более универсальный, чем язык сервисов/услуг и серверов/служб.

Дальше мы рассмотрим небольшой чеклист по важным объектам ситуации сервиса. Мы даём сначала тип более абстрактной мета-мета-модели (например, «сервис»), а потом указываем конкретизацию/специализацию этого типа мета-модели для мета-модели предметной области стрижки волос (например, «стрижка и укладка» для предмета сервиса «волосы», метаУ-модель, «из учебника парикмахерского дела», учебника метода, или даже метаС-модели, «из ситуации этой парикмахерской», из регламента работ по стрижке и укладке для этой парикмахерской).

Это мы так пытаемся показать, что сами объекты рассуждения задаются их типами мета-мета-модели мира («картина мира», upper ontology) из наших руководств, а потом под эти типы находим объекты в жизни/«рабочем проекте», а не берём первые попавшиеся объекты в жизни и пытаемся потом для них найти типы из руководств. Моделирование идёт не так, что вы смотрите на понравившийся вам объект и подыскиваете к нему тип, а наоборот: вы имеете уже абстрактный тип и подыскиваете к нему объект. Скажем, берёте тип «целевая система» и выявляете, что это такое у вас в проекте.

Зачем этот чеклист нужен, зачем его проходить в проекте? Чтобы структурированно обсуждать проект, не пропуская важного. В случае парикмахерской это легко, все знают эту предметную область. Но в случае новых видов сервиса всё не так очевидно, и нужно думать. Типы мета-мета-модели помогают не пропустить какие-то важные объекты в рассуждениях о предметной области, то есть мета-модели. А рассуждения по предметной области (мета-модели) помогают потом не пропустить важные объекты модели конкретной жизненной ситуации в конкретном рабочем проекте, в физическом пространстве-времени. Вот этот чеклист, и надо помнить, что это просто начало мышления, дальше системное мышление включает много больше понятий, заставляет подумать о много большем числе важных объектов:

• Целевая система: причёска (ролевой/функциональный объект). Получается из волос (в данном случае — волос клиента, прямо на голове клиента, это важно для использования формулировок «сервиса») путём выполнения работ по методам стрижки и укладки. Другая формулировка: причёска получается путём оказания услуг/service парикмахерской для волос клиента. Ещё одна формулировка: парикмахерская выполняет сервис стрижки и укладки для волос клиента, на выходе имеем причёску.

• Сервис: стрижка и укладка волос (причём волос клиентских — тип «сервис» говорит, что предмет сервиса — чужой). Это методы/функции/способы работы парикмахерской как роли агента-оргзвена.

• Предмет сервиса/метода: сырьё/заготовка — волосы, целевая система/продукт — причёска. Можно обсуждать смену состояния волос в ходе создания («не стрижены», «стрижены и не уложены», «стрижены и уложены»/причёсаны) или причёски в целом («не имеет формы», «стрижка есть, форма после мытья головы важна как бытовая причёска», «целевая причёска есть»/«стриженые волосы уложены»). Неплохо бы договориться. Акцент на волосах даст подробности в работе парикмахерской, акцент на причёске — будет меньше проблем с тем, что «все работы с волосами выполнены, а причёска почему-то получилась плохая». Тут хитрость: парикмахерская делает стрижку так, чтобы волосы без укладки смотрелись как причёска (а уж после укладки вообще должны производить неотразимое впечатление). Если мастерства стрижки у парикмахера нет, стрижка в результате приводит волосы в такое состояние, что без укладки смотреть на причёску нельзя, «ужас-ужас». Ещё надо отметить, что целевая система обычно физична, но если у вас сервис/метод на выходе даёт описание, то тут будет описание как предмет сервиса/метода, а целевая система будет отличаться. Скажем, интернет-сервис подбора причёски будет иметь предметом эскиз причёски, а целевой системой — таки саму причёску. В любом случае работы по методу (в том числе работы сервиса) меняют состояния предметов предметной области метода/сервиса, и нас интересует конечное состояние предмета сервиса, того предмета, ради достижения ожидаемого состояния которого ведутся работы.

• Надсистема в окружении целевой системы: ближайшее окружение причёски, как ролевой/функциональный объект: «голова для свидания» (но не «голова для еды в неё», например, или «голова для занятий спортом». Определение объекта по назначению/функции/целевому поведению). Тут важно брать системное окружение как можно ближе к целевой системе: берём голову клиента в какой-то ситуации (над-надсистеме — свидании), а не всё тело клиента. Тут «ближе» — ближе по системным уровням, но помним, что системные уровни непосредственно связаны с близостью в пространстве-времени (ибо отношение композиции/«частей-целых», которым связаны системы разных системных уровней работает как раз над частями и целыми областей пространства-времени).

• Потребность (клиента как внешней оргроли, владельца головы с волосами на ней): «впечатлить партнёра на свидании красотой головы» (фраза описывает надсистему для целевой системы проекта стрижки-укладки. «Красивая голова» — инструментарий клиента для его целевой системы «впечатлённый партнёр». Причёска — часть/подсистема инструментария «красивая голова»::система, вторая часть будет — макияж::система (не путаем с «нанесением макияжа»::метод или даже работы по какому-то методу нанесения с предметом этого метода «макияж»). Нанесением макияжа (изготовлением красивого лица для впечатления партнёра на свидании) клиент хочет заняться сам. Мы (персонал парикмахерской::служба/роль, «мы» обсуждаем этот проект — отслеживайте всегда состав случайно оброненного «мы» — кто это, сколько их, чем они заняты?!) не обсуждаем, хочет ли клиент впечатлить партнёра не только красотой головы, но и общей красотой всего драпированного одеждой тела.

• Концепция использования: сценарий подразумевает переход партнёра в состояние «восхищён» после демонстрации партнёру по свиданию головы с причёской. А также присутствуют самые разные другие сценарии (дождь и ветер по пути на свидание, сон перед свиданием, что будет с причёской после душа, когда пропадёт укладка и останется стрижка и т.д.). Мы, конечно, учитываем по возможности более и более дальнее окружение — сценарии, включающие голову с макияжем, всё тело с его драпировкой, окружающую ситуацию, например, помещение или открытая площадка с дождём и ветром. Наша целевая система должна хорошо работать в широком разнообразии ситуаций, и эти ситуации надо учесть — часть таких ситуаций можно узнать от клиента, но часть таких ситуаций учитывается из знаний/теорий метода, клиент может и не знать, что его от чего-то защитили, удовлетворили потребность, о которой он и не знал, и которая у него появится, если он вдруг попадёт в какой-то вариант сценария использования. Конечно, если учёт всё большего и большего числа ситуаций/сценариев использования в концепции использования ведёт к росту цены системы или удобства использования, то надо будет договориться с клиентом по этому поводу.

• Архитектурная характеристика выживаемости/survivability причёски как целевой системы парикмахерской: волосы с укладкой должны выглядеть сногсшибательно, а без укладки (если пришлось принять душ в ходе свидания) приемлемо.

• Создатель целевой системы: система, оказывающая сервис. Парикмахерская::провайдер/служба/server/provider/роль — это и есть создатель причёски::«целевая система». То, что внутри парикмахерской есть парикмахер, который и создаёт причёску, пользуясь своим мастерством и инструментарием — это нам сейчас неважно, у нас рассмотрение чёрного ящика, и мы не учитываем внутреннее разделение труда в парикмахерской, там и роботы могут работать. Создатель::роль — это нормально, это просто функциональное рассмотрение создателя (а не конструктивное, оргзвеном тут будет ООО «Чикчик»). Сервис (стрижка и укладка волос) — это не сама парикмахерская и даже не её работы. Сервис (стрижка и укладка волос) — это метод работы, экземпляров работ для экземпляров волос по этому методу будет много. Сервис — это поведение парикмахерской, описанное как содержание/метод работ, а не сама парикмахерская.

• Пользователь целевой системы: «клиент парикмахерской»/«причёсываемое лицо» (тут, похоже, нет специальных названий типа «игрок» или «сталевар», поэтому берём общие термины типов мета-мета-модели «клиент» или «лицо» и добавляем предметно-специфичные слова роли «парикмахерская» или указываем на объектность в предметно-специфическом действии — «причёсывамое»).

Сервис тут «стрижка и укладка» (можно рассматривать и как два отдельных сервиса, «стрижка» и «укладка»), обратите внимание на отглагольное существительное (в английском это «-ing» форма слова»), это обычно для функций/методов.

Сложно? В первый раз — да, сложно. Потом будет проще и проще. И всё больше и больше ситуаций сервиса вы будете трактовать как подходящие под этот паттерн «парикмахерская» (пример был взят только для того, чтобы уж точно была «служба/провайдер», а не «товарное производство» — и примерно было бы понятно, о чём речь. Но мозг затем использует этот пример, рассуждая в рамках прототипной теории понятий — «все сервисы как-то похожи на парикмахерскую»).

Зачем так сложно, почему нельзя порассуждать про парикмахерскую, не поминая все эти типы мета-мета-модели из нашего руководства? Затем, что во внимании при обсуждении сервисов (да и просто любых методов работ) в самых разных ситуациях оказываются не случайные объекты, а главные/важные объекты ситуации. Относитесь к этому как фрагменту чеклиста тех объектов, которые надо обсудить, чтобы сорганизовать множество самых разных людей (создателей парикмахерской, сотрудников парикмахерской, клиентов парикмахерской) для коллективной работы.

Конечно, типов мета-мета-модели, которые указывают на вещи первостепенной важности для их коллективного понимания в проекте, много больше — в нашем руководстве их тоже много больше, этот чеклист тут выдан только как пример системных рассуждений. Но в жизни царит суета, суматоха, пожары-авралы, бессонница и затуманенное сознание от просто усталости. Важные объекты, которые берутся из понятий интеллект-стека в целом (и системного мышления в частности) помогают удержать рассеянное внимание на важном.

Например, в этом чеклисте есть потребности/интересы/предпочтения внешних (для проекта парикмахерской) проектных ролей — для чего клиент хочет обратиться к сервису. В чём счастье внешних ролей, а не счастье внутренних ролей команды (у которых, конечно, тоже есть интересы и предпочтения, хотя их редко называют «потребности»). Если причёска будет, но голова окажется после выполнения причёски не в порядке (например, в ходе стрижки отрежутся не только волосы, но и уши), то беда. Если причёска будет для занятий спортом, а не для похода на свидание — беда. Всегда обсуждаем/описываем в паре целевую систему (причёску, тут это только пример) и надсистему (голову, тут это только пример). Описание надсистемы — потребности внешних проектных ролей, описание целевой системы — концепция использования. Концепция использования как-то прослеживает/трассирует описание функциональности системы к потребностям/интересам внешних проектных ролей. Хотите или не хотите, а концепцию использования вам нужно иметь.

Выбранный клиентом сервис парикмахерской будет «стрижка» или «укладка» или оба вместе. Выбор метода — это стратегирование, для получения результата «впечатлённый партнёр» клиент выбирает метод/сервис «создание причёски» и обращается за работами по этому методу к провайдеру сервиса, организации в роли «парикмахерская». У парикмахерской есть мастерство выполнения работ по методу (у сотрудников парикмахерской — будь они люди или роботы) и инструментарий (зеркала, кресла, ножницы и машинки для стрижки, расчёски, шампуни и лаки — всё, нужное для «оказания сервиса», то есть выполнения работ по набору методов создания причёски, то есть методам стрижки и укладки).

Работа сервис-провайдера (работы сервиса, ибо можно говорить и «работы роли», и «работы по методу») занимает конкретное время, использует конкретное оборудование и ресурсы, изменяет конкретную голову с конкретными волосами. А если говорить про функциональный аспект «как это обычно делается, как это описывается в учебниках», то сервис — метод/практика/культура работы, а не сама работа. Могло бы быть «мытьё головы и укладка у подруги», «закрытие головы шляпой дома, чтобы волос не было видно» и т.д. Сервис выбирают в ходе стратегирования, дальше он выполняется как стратегия, для выбранного сервиса планируются работы, то есть планируется задейсвование конкретных экземпляров ресурсов. Планирование идёт после выбора стратегии, то есть планирование идёт после выбора метода достижения результата «впечатлить партнёра», в том числе планирование включает выбор самостоятельного выполнения работ по методу или покупку этих работ у провайдера (покупку оказания услуг, предоставления сервиса). Нет выбора из нескольких методов получения результата (не было стратегирования — метода выбора метода) — вы мало подумали (подробней об этом будет в руководствах по методологии, системной инженерии, системного менеджмента). Но для выбора надо различать:

• Работу по достижению результата — она может быть проведена разными методами/способами, задействовать разные ресурсы. Дальше работает рациональность как метод мышления из интеллект-стека. Рациональность задаёт способ/метод порождения альтернатив и далее использование теории принятия решений, в которой вы выбираете лучшее из альтернативных решений и дальше действуете в соответствии с вашим выбором. В экономике, когда говорят об альтернативных издержках, то имеют ввиду ровно это: вы можете получить результат разными методами/способами, эти способы конкурируют друг с другом, но в конце концов будет задействован какой-то из них (самый выгодный по ресурсам), и это задействование метода/способа и будет работой. Работа с разными ресурсами может быть проведена много раз по одному и тому же способу. Гвоздь вы можете забивать молотком, камнем, микроскопом, но даже перед этим можете выбрать — забивать гвоздь, или ввинчивать шуруп или склеивать клеем.

• Метод/способ/культура проведения работ. По одному методу можно выполнить множество экземпляров работ, то есть множество раз задействовать ресурсы для получения результатов (изменения состояния предметов метода) выбранным методом. Если вы забиваете гвозди микроскопом, то этим методом можно забить множество гвоздей.

Голова (надсистема целевой) и волосы на голове (подсистема целевой) принадлежат клиенту, парикмахерская — создатель, реализованный организацией со своим мастерством и инструментарием (включая помещение, но возможна и работа «на выезде»). Парикмахерская — это роль создателя, которая может выполнять работы по типовому набору методов работы с волосами клиента: меняет состояние волос для создания причёски, причём может и добавлять к волосам свои какие-то материалы как части целевой причёски (ленточки, шиньоны, лак и т.д.).

Что является целевой системой? Причёска! А если мы организуем нашу парикмахерскую? По-прежнему — целевая система причёска, а парикмахерская тогда — «наша система»! С парикмахерской как системой-создателем мы выполняем полностью всё системное мышление, но она находится в другом системном разбиении, нежели причёска — парикмахерская относится к разбиению систем создания, которые рассматриваем во время/realm создания причёски. Окружение причёски мы рассматриваем во время/realm эксплуатации/использования/функционирования/работы самой причёски, а окружение парикмахерской — во время работы парикмахерской (но не во время создания самой парикмахерской!). Отношение между парикмахерской::система и причёской::система — создание::отношение. По этому отношению выстраивается граф создателей, но по нему нельзя выстроить какие-то «системные уровни», ибо иерархия системных уровней выстраивается по отношению композиции, которое применяется на момент использования. В частности, сама парикмахерская как система может быть реализована очень по-разному: это может быть «частный парикмахер» с чемоданчиком инструментов, который выезжает к клиентам (причём клиенты любят вызывать таких парикмахеров ночью, этого не сделаешь с другим типом парикмахерской — «посетить парикмахерскую» придётся в других вариантах самим, она не приезжает к тебе), это может быть подразделение большого холдинга, это может быть семейное предприятие в одной из комнат частной квартиры. Парикмахерская (она тут служба/провайдер) может быть частью парикмахерского холдинга, городского квартала, у неё такие части как парикмахерское кресло, зеркало и ножницы. Когда речь идёт о сервисе, то мы обычно проектируем и изготавливаем нашу систему-службу/провайдера/сервер в составе систем создания, но выстраиваем всё мышление всё равно, думая о целевой системе, в которой сервис производит изменения, чтобы его предметы поменяли входное состояние на выходное. Во всех этих случаях разной организации парикмахерской (роль создателя как провайдера сервиса по стрижке и укладке чужих волос могут выполнят разные агенты) обсуждение того, что там происходит при выполнении методов стрижки и укладки — одно и то же. Это экономия мышления: ситуация может меняться, а способы мышления остаются стабильными и даже сохраняется часть результатов мышления, общая для многих ситуаций.

Мы будем создавать не только целевые системы, но и системы создания целевых систем — поэтому говорим также о графах создателей, а не только отдельных системах создания. Сами волосы себя не подстригут и не уложат в причёску, они не живые (это только бабочка сама себя создаст из куколки, куколка себя создаст из личинки, личинка — из яиц). Для проведения работ сервиса стрижки и укладки поэтому создаём парикмахерскую с её мастерством и инструментарием стрижки и укладки, а для этого создаём создателя парикмахерской (это может быть строительно-монтажная организация, специализирующаяся на создании парикмахерских. Но такая организация, понятно, сама не занимается стрижками, как не занимается стрижками и клиент парикмахерской — и вот мы вновь коснулись тематики разделения труда, специализации разных агентов на разных методах работы, на разных сервисах).

Если бы нужно было что-то делать с ракетами, а не с волосами клиента, то мы бы делали ракетное конструкторское бюро и завод ракет, а не парикмахерскую. Если бы нужно было что-то делать с мастерством, то открыли бы школу, или вуз, или курсы или программу наставничества. Сначала понимаем, что делаем (целевую систему в её окружении), затем понимаем, какими способами её можно делать (методы/сервисы), затем думаем о том, какой агент-создатель сможет своим мастерством и инструментарием выполнить работы этого метода/сервиса. Поставщиков/провайдеров работ по каждому сервису много, и они конкурируют. Но мы в том числе создаём этих создателей, если их ещё нет (иногда создавать приходится обширный граф создателей, которые создают, развивают и изменяют друг друга). Интеллектуальных агентов для этого учим мастерству (с учётом разделения труда), снабжаем инструментарием (капитал) и организуем (делаем известным кто кому что может поручить сделать, кто чем будет заниматься).

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

Описание системы делается и для причёски (целевой системы), и для парикмахерской (нашей системы). Воплощение системы будет и у парикмахерской (нашей системы), и у причёски (целевой системы). Внешние проектные роли с их предметами интереса и предпочтениями будут и у проекта создания парикмахерской, и у проекта создания причёски — роли будут разные, интересы их будут разные (даже при одинаковых предметах интереса!), забыть никого нельзя, ибо это связано и с успешностью причёски, и с успешностью парикмахерской.

Но целевая система будет — причёска, ибо только упустишь из виду, что делать в конечном итоге нужно причёску (а не «нашу» парикмахерскую, она тут только провайдер сервиса), парикмахерская будет отлично работать, только недолго, пока не кончатся деньги инвестора, ибо вся «клиентоориентированность» или «продуктоориентированность» будут утеряны.

Платят обычно за результаты работ создателей — за оказание сервиса, а не за создание создателя. Платят за то, что целевая система после того, как её изменили создатели (провайдеры сервиса), перешла в новое состояние, что-то во внешнем мире поменялось к лучшему, сделало шаг к удовлетворению потребностей, снятию чьих-то беспокойств, удовлетворению чьих-то интересов. Если сервис парикмахерской (то есть сервис стрижки-укладки), то платят за работы, дающие причёску, которая начинает потом эксплуатироваться в составе ухоженной головы. За эскиз причёски и разговоры парикмахера по поводу выбора модели причёски могут заплатить, но только в том случае, когда конечная причёска окажется годной к эксплуатации. Если окажется, что это в реальности не происходит, то заказчики вернутся в парикмахерскую и опротестуют и причёску, и эскиз, и результаты разговоров с парикмахером: это уже внутреннее дело службы, оказывающей сервис, разбираться, кто там в её внутренней структуре дал такой сбой, что внешнее поведение-сервис и его результаты оказались неправильными. Целевой же системой всё равно будут причёски, и от класса этих причёсок будет зависеть, брать за сервис стрижки будут 100 рублей, 1000 рублей или даже 10 тысяч рублей.

Интересно, что какой-нибудь инженер-конструктор всё понимает в этих рассуждениях про парикмахерские, про сервисы доставки потребительских товаров, но когда речь идёт о том, что он выполнил какой-то шаг проектирования своей целевой системы (например, промышленного трубопровода), то он хочет безусловной оплаты своего даже потенциально очень кривого и ошибочного труда независимо от того, будет ли в итоге хороша целевая система. Но он ничем тут не отличается от парикмахерской: по факту он хочет оплаты за эскиз трубопровода (не отличается от эскиза причёски — тут любая целевая система подойдёт), и ему всё равно, будет ли его «причёска» реализована, или нет. Беда ещё и в том, что многие конструкторы даже не знают, как выглядит в жизни их работающая целевая система — никогда не сталкивались с ней «в металле», причём не на заводе, а прямо у клиента. Нет, целевой системой тут будет работающий промышленный трубопровод, если он будет плохо работать — то денег за него не заплатят, и конструктор за свою работу долю своих денег не получит. Все бизнесы на свете — это такие «обобщённые парикмахерские», все прикладные рассуждения о бизнесе и инженерии похожи друг на друга, на уровне мета-мета-модели нашего руководства (в типах мета-мета-модели) это одно и то же рассуждение.

Сервис-ориентация. Мир провайдеров.

Переход в мышлении от поставки продуктов как целевых систем к оказанию сервисов (выполнению экземпляров работ услуги/метода провайдером/поставщиком услуги/метода над чужим предметом работы) оказался очень продуктивным и в современном языке называется сервис-ориентацией. И мы видим всё больше и больше провайдеров — «интернет-провайдеры» как раз отсюда, «поставщики сервиса доступа к интернету». Предмет их сервиса, он же целевая система — «доступ к интернету», подразумевающий определённое физическое состояние аппаратуры клиента и аппаратуры провайдера, обеспечивающей передачу данных между аппаратурой клиента и аппаратурой всех остальных клиентов всех остальных интернет-провайдеров мира, имеющих «доступ к интернету» в мире.

Поставщики софта, который работает как облачный инструментарий, обрабатывающий по какому-то методу чужие данные, используют бизнес-модель SaaS, software-as-a-service. Тут надо учесть, что в информационных технологиях сервис часто рассматривается как сервер (микросервисы — это вообще-то микросерверы, а не микросервисы как функции/методы серверов), в крайнем случае — неодушевлённый «станок», но не метод/поведение, метод вообще может быть опущен в рассуждениях, и сразу речь идёт о «вызове сервиса» как проведение работы провайдером, метод этой работы не обсуждается отдельно. Всегда пытаемся уточнить, что же имеет в виду собеседник, когда поминает термин «сервис», помним про множество словарных значений каждого термина! Софт-как-сервис — это софт, который оказывает сервис, софт тут — служба/сервер/провайдер сервиса. Но провайдером могут назвать и организацию, у которой есть мастерство проведения сервиса, а софт тут — инструментарий. Если бы это была мастерская, где точили ножи, то рассмотрение тут было бы то же самое — «станок-как-сервис», можно было бы принести свои ножи, как в софт в модели SaaS несут свои данные, поточить ножи, как в модели SaaS обрабатывают свои данные, и забрать ножи после заточки, как в модели SaaS забирают данные после их обработки. Плата только за выполнение (работ) услуги/сервиса, не надо платить за ножи или данные.

Все проекты перехода от товаров/продуктов/изделий к сервисам (сервис-ориентация) похожи в том, как о них думать. Сервис-ориентация начала затрагивать и традиционные продукты и изделия, то есть физические объекты, изготавливаемые как «товар» — то есть поставщики товаров начали тоже переходить на бизнес-модели поставки сервиса (вернее, поставки работ сервера по методу сервиса).

Например, возьмём чугунные чушки, «чугун серый литейный»:

Если учесть сервис-ориентацию, то услугой/сервисом будет «поставка», предметом сервиса будет «чугун» (чугунные чушки) и лучше говорить «поставка чугуна», ибо обычно оставление слишком общих слов в названиях «методов работы»::«паттернов поведения» (поставка, разработка, изготовление, создание, покупка) не позволяет вести содержательного разговора, не хватает конкретизации хотя бы до уровня метаУ-модели, предметной области.

Глаголов обычно мало, и они очень общие, это наследуют и отглагольные существительные (-ing форма глагола в английском), их мало и они очень общие. Поэтому для конкретизации указывают предметы методов, на которые указывают глаголы — и специфика предметной области вносится терминами предметов метода, а не терминами самих методов/функций/культур/способов/стратегий/сервисов.

Переход от «продажи чугуна» к «поставке чугуна» увеличивает возможности предприятия, превращающегося из «поставщика собственного товара» в «службу» или «провайдера доступа к чугуну»: сам чугун, как продукт, остаётся тот же самый — но если обратить внимание не на сам чугун, а на метод поставки, то могут существенно меняться состояния объектов в предметной области поставки. К спецификации чугуна появляется спецификация сервиса поставки, «условия поставки» (в сервис-ориентированном подходе говорят часто о SLA, service-level agreement³). Поставка точно вовремя для производства (just in time⁴), через склад предприятия или прямо к точке переплавки, поддержание минимального запаса в течение года или просто поставка одной крупной партии, возможности кредитования при поставке, поставка от третьих фирм, и т.п. — вариантов методов «поставка» для предмета «чугун серый литейный» множество. Получается, мы резко расширили ассортимент за счёт этих вариантов сервиса поставки, хотя предмет сервиса (чугун, который в конечном итоге будет «поставлен», перейдёт во владение получателя чугуна) оставили тем же самым.

Сервисы/функции/методы обычно легко распознать в языке — это отглагольные существительные, в которых скрыт глагол (поведение), но тем не менее в языке сохраняется словоупотребление по их поводу, как для вещи. Если действие/процесс «обучить», то сервис будет «обучение». Если действие/процесс «поставить», то сервис будет «поставка». В английском языке сервисы обычно выражены глаголами в их ing-форме. При этом не надо обольщаться высоким уровнем обобщения в названиях метода/сервиса (обучение, поставка). Помним, что обычно указывается и предмет: обучение азбуке Брайля, танцам, системному мышлению проходит абсолютно разными методами, но термин в названии метода будет «обучение». Поставка свежеприготовленных гамбургеров, литейного чугуна, коробочного софта проходит тоже абсолютно разными методами, но термин в названии метода будет «поставка». Интересуйтесь предметами метода, а также требуйте указать конкретный вариант метода (скажем, «чистка» может быть трубопровода и зубов, «чистка зубов» может быть с использованием разного инструментария — «ультразвуковая глубокая чистка зубов», «чистка зубов щёткой и зубной пастой», «чистка зубов зубной нитью»). Уточняйте: и когда сами говорите, и когда вам говорят про методы/сервисы/культуры! Если не уточните, то вас наверняка поймут неправильно, или вы поймёте собеседника неправильно. Выбирайте всегда правильный уровень абстракции для обсуждения!

Переход от «вещей» к «поведению», изменениям, динамике оказывается очень продуктивен, поэтому сервис-ориентация стремительно вытесняет ориентацию на продукт. Операционная система Windows 10 уже рассматривалась фирмой Microsoft не столько как продукт (целевая система, которая передаётся клиенту), но как сервис, то есть метод/культура поддержания продукта в постоянно обновлённом виде (целевая система как предмет сервиса, то есть Windows 10, принадлежит клиенту, но Microsoft меняет версии, добавляя новые возможности и исправляя ошибки — улучшает целевую систему своим внешним поведением). Microsoft из поставщика «коробочных» программных средств стал провайдером программных сервисов. Переход к Windows 11 по факту означал просто маркетинговое событие, смену имени, ибо ничего принципиально нового не привнёс: Windows 11 по факту просто очередная версия того же сервиса от фирмы Microsoft. А дальше Microsoft переводит клиентов-покупателей бывшего коробочного продукта MS Office на SaaS бизнес-модель, то есть от офисного софта как «товара» предоставляет только внешнее его поведение, делает серверный/облачный MS Office (ныне Microsoft 365) своим инструментом, размещает этот софт в своих датацентрах, оставляя на компьютерах клиентов-абонентов/подписчиков сервиса (а не покупателей коробочного софта) только знакомый им интерфейс MS Office. Предмет этого сервиса — данные клиента (обратите внимание, что методы/сервисы работают не только с системами, но и с самыми разными объектами предметной области методов/сервисов, которые называем предметами, и которые могут менять своё состояние с исходного на входе метода на выходное после применения метода —клиенты в ходе их обработки мастерством и инструментами Microsoft::провайдера::создателя меняют своё состояние с исходных на обработанные выходные после применения софта Microsoft. Предметы, а не целевые системы — методы/сервисы могут работать и с описаниями).

Сервис-ориентация чудесным образом расширяет возможные рынки: разных типов/видов/категорий/классов методов в мире не так много, несколько тысяч (и поэтому глаголов в языках всего несколько тысяч), а вот разных видов вещей — миллионы и миллионы (поэтому существительных миллионы). Мышление о методах/сервисах экономно: с миллионами и миллионами разных товаров работают одни и те же всё более и более универсальные сервисы. Эти сервисы соответствуют самым разным ожидаемым от создателей-провайдеров ролям в самых разных графах создателей. Поставщик чугуна обычно просто поставляет чугун-товар. Если же речь идёт о сервисе, который специализируется именно на методах/сервисах поставки, то легко можно кроме чугуна поставлять что-то ещё. Можно вообще стать «маркетплейсом». Если говорить о платежах, то можно платить за что угодно. Если говорить о поддержке облачного софта, то по большому счёту этот софт может быть каким угодно. Не только с одним продуктом можно делать::метод разное, но одно и то же делание::метод оказывается хорошо приложим к разным продуктам.

Современный магазин (скажем, интернет-агрегаторы розничных торговцев, «маркетплейсы» — «ходят» сегодня туда, Yandex.market, Wildberries, Megamarket, Ozon, Amazon, они сопряжены со службами доставки и сетью пунктов выдачи заказов с примерочными) тем самым поставляет не столько покупаемый продукт, сколько предоставляет сервис (метод работы с каким-то предметом метода/сервиса) по продаже::сервис и доставке::сервис продукта::предмет. Мастерство и инструментарий маркетплейса как провайдера сервиса «поставка против платежа» с предметом «поставка против платежа». Тут легко запутаться с одноимённым сервисом и предметом сервиса, ибо «поставка» и «платёж» с одной стороны отглагольные существительные (имена методов работы с товаром/продуктом::«предмет метода» и деньгами::«предмет метода»), с другой стороны — система в физическом мире, где продукт доставлен и перешёл в собственность клиента, деньги платежа доставлены на счета поставщика продукта и перешли в его собственность (про безналичные деньги думаем примерно так же, как про наличные: там с нюансами, но всё сводится к кучке золота в подвале банка, так что деньги — это про физический мир, а не описания).

Нужно при этом понимать, что целевая система проекта создания и развития провайдера сервиса и предмет сервиса находится у клиента. Сервис провайдера что-то меняет в системах клиента (целевой или каком-то создателе в графе создателей, например, инструменте какого-то метода создания) или даже не системе, а описаниях системы клиента (иногда по длинной цепочке «описаний описаний»). Например, сервис может менять описание целевой системы, отражая это в проектной документации. Сервис может менять содержание своей базы данных с описанием клиентской целевой системы — а затем это описание может быть использовано для физических изменений воплощения целевой системы (изготовления или ремонта), и вся затея с задействованием провайдера может быть именно для этого конечного физического изменения. Все такие связанные с провайдерами сервисов/службами/серверами цепочки изменений, тянущиеся до физического мира, обязательно нужно отслеживать и продумывать.

Если вам поручили «сделать сервис» (обычно это означает «сделать провайдера, который будет предоставлять услуги, то есть проводить экземпляры работ по какому-то методу работ»), то можно совершить крупную ошибку: считать, что целевой системой является сам провайдер: его инструменты и мастерство. Нет, целевой системой является та система, которую мы изменяем сервисом/методом (возможно, по цепочке описаний, если предметом сервиса является какое-то описание, а не система, а иногда предметом будет мастерство или инструментарий создания целевой системы).

Создаваемый сервис в данном случае — это метод::поведение нового создаваемого провайдера (который работает над какой-то чужой целевой системой, по факту входя в команду), и этот провайдер — «наша система». А ещё вы сами создатель для «нашей системы», да вам нужно ещё и самому создать себя как производителя работ по созданию провайдера, то есть речь идёт о каком-то пути создания в большом графе создателей целевой системы. Целевая система остаётся той системой, по поводу которой нужно договориться всем задействованным создателям в графе создателей — ваш проект создания нового провайдера имеет смысл ровно в той мере, что кому-то нужно что-то сделать с его целевой системой, и он приглашает «вашу систему» (провайдера) поучаствовать в проекте.

Нужно потом будет ещё убедиться, что сделанный вами провайдер/служба/сервер работами своего сервиса (работами своего метода, то есть работами своего мастерства с инструментарием) таки создаёт целевой продукт/систему с нужным уровнем качества, а ещё вы демонстрируете достаточные скорость и эффективность создания вами самого этого провайдера.

Почему графы создателей такие сложные? Вот один из путей/цепочек создания в графе создателей причёски (не парикмахерской, ибо целевая система в проекте создания парикмахерской — причёска, парикмахерская тут одна из «наших систем», а в графе создателей есть и другие «наши системы»):

• Система-1: вы, как создатель команды создания парикмахерской. Вы организуете небольшую инженерно-менеджерскую команду и поставщиков товаров (кресла, ножницы, лак) и сервисов (ремонт помещения) в проект, который создаст парикмахерскую (и мы даже не рассматриваем начало цепочки в графе создателей: вам ведь «поручили создать» парикмахерскую, то есть вы ещё и не в начале цепочки, но вас кто-то создал как создателя!)

• Система-2: инженерно-менеджерская команда и поставщики товаров и сервисов, которые создают парикмахерскую (эту команду организовали вы)

• Система-3: парикмахерская (люди с парикмахерским мастерством, помещение с инструментами, менеджеры), созданная вашей инженерно-менеджерской командой

• Система-4: причёска, целевая система всего проекта, создаваемая парикмахерской в ходе кейса/проекта для каждого клиента парикмахерской.

Вот это цепочку/путь на графе создателей хорошо бы себе ясно представлять. Без чёткого понимания кто какую систему создаёт, за что отвечает, нельзя разобраться в проекте, риск провала будет велик.

Так что в проекте создания парикмахерской::провайдер для выполнения работ сервиса стрижки и укладки целевой системой (продуктом) будет причёска чужих волос, которая меняет своё состояние с «не было» в «стало». Частные методы, составляющие все полные методы работ (сервис) по стрижке и укладке — выбор фасона, стрижки волос, укладки, возможного смешивания волос с лаком и всякими украшающими ленточками и цветочками (если они предусмотрены). Это и есть создание и (поскольку эти причёски будут делаться снова и снова, и будут становиться всё лучше и лучше) развитие причёски. Работы по созданию и развитию причёски и есть оказание/работа сервиса/метода ООО «Чикчик» со всеми его людьми-парикмахерами и помещениями с инструментами парикмахеров в роли парикмахерской.

Шикарный сервис стрижки (метод работы парикмахера с волосами клиента золотыми ножницами на кресле-троне под живой оркестр) с результирующей плохой причёской — это не то, что нужно, это явно не будет успешной целевой системой. В сервисе главное — достижение состояния целевого предмета сервиса (предмета метода работы, то есть предмета создания причёски — достижение целевого состояния причёски). Причёска для спорта вместо причёски для свидания — это ведь тоже не то, что нам нужно? Когда мы занимаемся системой создания, чтобы получить сервис создания целевой системы (разрабатываем серверный софт, открываем сервисную фирму-провайдера), никогда не нужно забывать о целевой системе и её надсистеме.

Очень легко забыть, для чего вообще существует создатель-провайдер, для чего будет задействован сервис — и после того, как это забыто, целевая система перестаёт быть успешной (а ведь всё делается для неё), довольные клиенты вдруг становятся недовольными, и вы их теряете. Если менеджер думает о заводе по выпуску самолётов как своей целевой системе, то завод может быть супер-пупер каким продвинутым, люди супер-пупер какими сотрудничающими, рабочие процессы супер-пупер какими отлаженными, но если выпускаемые самолёты не летают (целевая система — используемый, то есть летящий, самолёт), то и завод по выпуску таких нелетающих самолётов не нужен (более того, он вреден: прожигает деньги инвесторов).

Если вы думаете о целевой системе и внешних проектных ролях проекта по её созданию и развитию, то думайте в письменном виде: документируйте эти мысли и обсуждайте их с командой и этими внешними проектными ролями. И проверяйте по самым разным чеклистам, обо всех ли важных объектах проекта вы подумали, не пустили ли вы дело на самотёк, не сделали ли вы ошибок в своём мышлении, не пропустили ли чего в своих работах.

Примеры сервисов и их провайдеров

Вам совсем необязательно проговаривать типы из трансдисциплины системного мышления, как это мы делаем тут в учебном тексте: «фрукт яблоко», «мебель стул», «система самолёт», «сервис-провайдер парикмахерская» и т.д. В жизни важно просто обращать внимание на типы объектов (удерживать эти типы объектов в голове, молча), чтобы убеждаться в правильном выделении важных объектов из многообразия окружающих объектов и проверять, что вы выполняете правильные операции с этими типами (не ожидаете, что описание будет создателем, не ожидаете, что целевая система — предприятие, и т.д.).

Вопрос в запоминании чеклиста из типов, о типизированных ими объектах которых вы должны подумать, выделить их вниманием в ваших рабочих и личных проектах. Все эти типы из нашего руководства связаны между собой отношениями, и легко проходить в мышлении по этим отношениям, перенося дальше внимание с этих отношений и типов мета-мета-модели на конкретные объекты вашего проекта.

Если вы выявили целевую систему вашего проекта, то для неё обязательно должно быть окружение и функция/метод/сервис (тут длиннейший ряд синонимов) в этом окружении. И ещё у неё должны быть подсистемы, которые каждая имеют свою функцию в целевой системе. А ещё должен быть создатель/constructor, и часто не один, а целый граф таких создателей — граф по отношениям создания. Да, это мы опять в кратком виде упоминаем мантру системного мышления.

Всё это работает итеративно, и отношение проходится в разные стороны. Если есть какой-то создатель, то у него (возможно, по длинной цепочке через граф создателей) обязательно будет целевая система, а у неё надсистема. А наша система может быть какой-то вообще третьей системой (например, подсистемой в целевой, или подсистемой какого-то создателя в графе создателей).

Если вы не различаете все эти виды систем в проекте, вы будете пропускать во внимании важные объекты. Если у вас проект создания учебного курса (скажем, вы хотите делать onboarding, знакомить новых сотрудников с вашей организацией), то должна быть и целевая система — мастерство (скажем, мастерство надлежащего поведения сотрудника в организации). Если у вас проект какой-то системы доставки (провайдер сервиса доставки), то это создающая система, а целевая — «доставленная посылка» (вручённая в руки получателю, а не которая «в пути»). Главное тут: выявить все эти системы и убедиться, что вся команда проекта понимает, каковы эти системы, даже если вы каждый раз не приговариваете тип из мета-мета-модели (то есть говорите «мы все тут делаем причёски, наша парикмахерская нужна только для причёсок, а не сама по себе», а не «у нас целевая система причёска, наша система парикмахерской нужна только как создатель целевой»).

Это только гении могут вспоминать всё нужное вовремя и «по наитию» (хотя и они не могут, они тоже обычные люди). Системные мыслители обычно не гении, поэтому они поступают не «по наитию»: они используют перечисления понятий системного подхода как чеклисты для объектов своего мышления.

Типы понятий из системного подхода (например, предлагаемые нашим руководством) сами по себе полезны в момент обучения, но потом для обсуждения в рабочем проекте того, о чём уже подумали, а о чём хорошо бы подумать, надо ещё и пойти побеседовать со знающими людьми в проекте и не только (с некоторыми можно беседовать путём чтения их книг, статей, регламентов), потому как многое не нужно выдумывать, а нужно выявлять/discover: искать в мире объекты уже заданных в наших руководствах типов, а не вообще «какие-то» объекты, которые просто бросаются в глаза. «Какие-то» объекты могут оказаться как важными, так и неважными. Объекты тех типов, которые задаются системным мышлением, с максимальной вероятностью являются важными. Их типы и важность кажутся банальными, но попробуйте спросить членов вашей команды, что же в проекте создаётся и развивается (в наших терминах — целевая система, а в небольшой команде в большом проекте — «наша система»), и вы удивитесь разнообразию мнений. Как можно что-то создавать и развивать быстро и эффективно в таких условиях всеобщей недоговорённости?

Небольшие нюансы каждого проекта (например, по-другому организованная команда проекта) дают большую разницу в том, как удобно выделить разные системы в проекте. Каждый раз для каждого проекта нужно заново делать работу по выявлению целевой системы и нашей системы, определению потребных сервисов, и всему остальному системному мышлению. Поэтому дальше идут не «типовые ситуации» и «алгоритмы мышления», а просто примеры. Берите их как начало рассуждений и обязательно адаптируйте.

Рассмотрим простейший пример: проект, полностью эквивалентный созданию парикмахерской (и мы говорили, что ситуации сервисов на уровне мета-мета-модели все эквивалентны, объекты там типизированы одними и теми же типами и связаны одними и теми же отношениями) — но вы будете делать шлифовальную мастерскую. Удивительно, но редко сталкивающиеся со шлифованием люди мало задумываются над ровно теми же вопросами, которые им могут прийти в голову, когда они думают над хорошо знакомой им ситуацией стрижки в парикмахерской, просто потому что с парикмахерской они все сталкивались, а со шлифовальной мастерской — нет. И вот это «задуматься над важным, когда оно пропущено» — в этом и проявляется сила системного подхода, сами понятия системного мышления, типы из его мета-мета-модели (система в вариантах её видов, функция/метод/сервис/культура, работа, роль, агент и т.д.) тут являются ключевыми подсказками, чеклистом «о чём надо подумать», «о чём надо рассказать, когда спросят, чем занимаемся», «о чём надо спросить, чтобы разобраться».

Шлифовальная мастерская как провайдер сервиса шлифования имеет какую целевую систему? Шлиф: та самая зашлифованная работами сервиса шлифования поверхность (физический объект! Шлиф как целевая система занимает место в пространстве, характеризуется своей шероховатостью, с одной стороны прилегает к телу шлифуемого объекта, с другой стороны касается какой-то системы в окружении). Так что шлифовальная мастерская в целом (или шлифовальный станок в её составе, это смотря какой у вас проект) — это система создания шлифа.

Обязательно нужно рассмотреть надсистему: для чего шлифуем? Что будет соприкасаться со шлифом, или шлиф просто должен блестеть для красоты? Нужно ли закрывать шлиф лаком, чтобы он не окислялся? Каков класс обработки поверхности? Важно, что все эти вопросы автоматически придут в голову опытному шлифовщику. Но мы-то не опытные шлифовщики, а нам надо, чтобы эти все вопросы тоже пришли к нам в голову! Системное мышление даёт ровно это, когда заставляет подумать

• и о целевой системе (это не так просто понять, что это шлиф — хотя это полностью эквивалентно «причёске» в случае парикмахерской, только вместо стрижки и укладки — шлифовка и полировка, а вместо волос на голове — поверхностный слой вещества на заготовке),

• и о надсистеме (шлиф в соприкосновении со шлифуемой деталью с одной стороны и пока непонятно чем с другой стороны шлифа),

• и о потребностях внешних проектных ролей (зачем шлифуем? Что интересно получить инженеру от надсистемы, если в составе надсистемы будет шлиф?)

• и о концепции использования шлифа (какое поведение шлифа хотим получить в ходе его задействования в надсистеме, что от него ожидается?)

• и концепции шлифа (каким будет шлиф, не будет ли дополнительных покрытий, напылений, лакировки?),

• и о том, как обосновать результат (как убедиться, что все интересы удовлетворены?).

Если речь идёт о сервисе шлифовки, то можно подумать и о функциях создателя шлифа (заметили, что «функции создателя шлифа» это синоним «сервиса шлифовки», а также «метода работы шлифовальной мастерской»?), которые он будет выполнять по отношению к заготовке целевой системы в надсистеме создания детали в целом: функция «сделать блестящую поверхность» — для этой работы можно просто покрасить поверхность, или никелировать её, или даже заклеить блестящей плёнкой; «сделать гладкую поверхность» — для этой работы тоже можно предложить ряд способов, кроме шлифования.

Как выбирают обращение к шлифовальной мастерской:

• сначала определяется конечное состояние предмета метода/сервиса/функции,

• а затем можно выбирать из ряда вариантов возможных методов/сервисов/функций/практик.

Ещё один вариант сказать то же самое, но чуть подробней (близко к системной мантре):

• сначала определяется функциональный объект как предмет метода («гладкая поверхность» — и определяется, что там за свойства гладкости нужны в окружении этого предмета метода в момент использования этого предмета), концепция использования поверхности

• а затем предлагается конструктивный объект для воплощения функционального объекта (шлиф на болванке, гладкий слой краски, наклеенная сверху пластиковая плёнка и т.д.), концепция поверхности.

• Дальше думаем, каким сервисом/способом/методом это можно осуществить, (шлифовка! А предмет метода шлифовки — шлиф. С этого момента «гладкая поверхность» конкретизируется: «шлиф»::«гладкая поверхность»).

• Дальше думаем, кто может быть создателем, то есть провайдером такого сервиса (провайдером сервиса по созданию шлифа может быть шлифовальная мастерская, или даже шлифовальный станок, или даже шлифовка своими силами вручную, хотя в последних двух случаях «наших сотрудников, наших инструментов» продолжаем говорить о методе, но в первом случае «внешней мастерской» говорим о сервисе).

• Выбираем конструктивный объект, выполняющий роль шлифовальной мастерской (например, ООО «Вжжж»).

Системное мышление заставит подумать и о внешних ролях (инженер::клиент, которому нужен шлиф), и о внутренних/командных::роли (кто будет шлифовать?) и о внешних по отношению к создателю::система (кому нужна шлифовальная мастерская, но не нужны сами шлифы). Заставит документировать интересы внешних проектных ролей и концепцию использования шлифа (описать надсистему шлифа — что хотят внешние проектные роли от шлифованной поверхности плюс того, что к ней прилегает), концепцию самого шлифа, которая даёт ожидаемые свойства (класс обработки поверхности, необходимость какого-то покрытия после шлифовки, например, лакирования: как обеспечить те характеристики шлифа, которые важны в момент использования).

Ровно такие же рассуждения нужно делать и в других случаях. Так, вы делаете систему оформления командировок, и вы подозреваете, что вашим клиентом тут является бухгалтерия. Системное мышление заставляет пройти по следующим рассуждениям (подробней эти рассуждения по поводу служб администрации приводятся в руководстве по системному менеджменту, они типовые для почти всего, что связано с администрированием):

• Поскольку речь идёт о софте (хотя мы пока и не знаем, «система оформления командировок» включает ли в себя людей, не является ли каким-то оргзвеном, или это таки просто софт-инструмент без отдельного оргзвена для него), то этот софт что-то описывает в своих данных. Что описывает? Командировку, или на формальном языке — «деловую поездку». Итак, целевая система (ради которой всё затевается, включая оформление через ваш будущий софт) — деловая поездка, которая понимается как набор/composition вполне материальных объектов: человек (необязательно сотрудник!), который куда-то едет, пункт начала поездки, пункт конца поездки, транспорт, зарезервированное место в транспорте (описывается административно значимой записью на серверах перевозчика, а раньше это было «билетом», описание собственно «езды»), место проживания (описывается административно значимой записью на серверах гостиницы, но обычно достаточно выписки — квитанции) — и всё это на каком-то отрезке времени.

• Уточняем теперь целевую систему. Кандидатов в рассмотрение целевых систем становится три: 1. Удалённая работа (поездка тут не волнует, волнует то, что надо добиться каких-то изменений в объектах, хотя эти изменения без поездки невозможны). Например, начальник поручает сотруднику удалённую работу, или сам сотрудник решает, что надо провести работу. 2. Собственно, деловая поездка — как её для себя определяет сотрудник. В неё входит выполнение работы, а также собственно поездка — транспорт, ночёвки. 3. Оформляемая часть деловой поездки — это тот объект, который интересует бухгалтерию: только те части поездки, которые как-то связаны с оплачиваемым (а не всем) транспортом и оплачиваемыми (а не всеми) ночёвками. В большинстве связанных с администрированием ситуаций надо выделять похожие три целевых системы.

• Клиент при этом не бухгалтерия, а те, кому нужны удалённая работа (например, начальники командируемых) и деловая поездка (командируемые), а бухгалтерия оказывается в подчинённой роли внешнего провайдера сервиса по созданию оформляемой части деловой поездки. Так что дальше надо определяться: софт этот как инструментарий чей — инструментарий начальника для оформления удалённой работы, сотрудника для помощи в деловой поездке или бухгалтерии для оформляемой части деловой поездки.

• Если это понять, чей инструментарий из этих троих создаваемый софт и поддержать начальников и сотрудников в первую очередь, а бухгалтерию — в последнюю очередь (а не наоборот — удобный для бухгалтерии метод оформления, неудобный для начальников и сотрудников как клиентов бухгалтерии, а затем загонять начальников и сотрудников в неудобный сервис под угрозой отнять их деньги и нервы, зато сэкономить нервы бухгалтерам), то команда проекта с результатами её работы будет нужна прежде всего всем начальникам (которые хотят удалённой работы) и сотрудникам (которые хотят отправиться в деловые поездки), а не только бухгалтерам фирмы, которые эти поездки должны оформить, но им этого по большому счёту не надо («не смог оформить — не поехал, последствия неисполнения удалённой работы разгребаем не мы, бухгалтерия, так что заткнитесь и выполняйте любые дурацкие правила оформления»). Это существенно меняет переговорные позиции в проекте! Из врага всех начальников и сотрудников команда разработки инструментария (софта оформления удалённых работ/деловых поездок) становится другом всех начальников и их сотрудников! И дружат они все против бухгалтерии, для которой ноль поездок (ноль работ по предоставлению сервиса, да это и не классический сервис, они за него денег не получают!) — это идеал/предпочтение, ибо уменьшает количество их забот по оформлению. Такие развороты ситуаций типичны, когда речь заходит о системном мышлении: приходится честно отвечать на вопрос, кому что нужно и договариваться о балансе интересов для создаваемой системы, какой бы она ни была. При этом помощь со стороны типов мета-мета-модели в том, что становятся понятными объекты, по поводу которых надо договариваться (предметы договорённостей, обычно это предметы каких-то методов, которые используют договаривающиеся агенты-в-ролях) и понятно, кому договариваться.

• Какие методы работы нужно задействовать, чтобы целевая система «оформляемая часть деловой поездки» была создана, предмет этих методов из состояния «оформляемой части деловой поездки нет» превратился в «оформляемая часть деловой поездки создана», затем через несколько стадий «оформляемая часть деловой поездки выполнена»? Что содержательно нужно сделать, то есть каким способом поменять состояние каких предметов/объектов, (но пока не рассматриваем агента: кто или что будет проводить работы по этим методам)? Создатель с помощью инструментов (люди бухгалтерии с софтом, но мы уже выяснили, что там надо учитывать и командированных, и их начальников и даже случаи «сам себе начальник», самопосыл в командировку) должен зарегистрировать потребность в поездке и открыть мини-проект удалённой работы, выделить финансирование на поездку (но там может быть ещё и часть финансирования на сами работы!), купить билеты, возможно, забронировать гостиницу, выдать командировочные, оформить документы (командировочное удостоверение, билеты, бронь в гостиницу, грузовые документы для какой-нибудь провозимой с собой аппаратуры, если нужно), принять отчёт о поездке — и тут есть множество вариантов, зависящих от принятых методов ведения командировок. Где-то не нужны командировочные удостоверения, где-то не нужны даже отчёты, где-то юристы больше защищают сотрудников, где-то юристы настаивают на выполнении стандартов деловых поездок ещё советского времени (когда полёт на самолёте был чем-то экстраординарным).

• Какой создатель должен эти методы выполнить? Софт (и там создатель софта — команда программистов, «создатель создателя»), или служба/«провайдер сервиса» оформления (софт на серверах плюс люди из бухгалтерии, работающие с этим софтом как операторы? Терминология «службы» и «сервиса» будет задействована только в этом случае, но и тут варианты: чем более внешняя эта служба, например, внешний провайдер сервиса бухгалтерии, тем больше будет уместна эта терминология, а вот если это делают сотрудники той же фирмы, которая оформляет для других своих сотрудников командировки — вот тогда слово «сервис» для выполняемого там метода работы или «служба» для самих этих людей с их мастерством и инструментами-софтом можно не услышать, «язык сопротивляется»)? Что будет сочтено успехом проекта создания софта, создания службы, создания деловой поездки? Какие роли требуются для этих разных проектов создания создателя деловой поездки (создания службы оформления, а там внутри ещё и создания инструмента оформления, то есть софта), создания деловой поездки (и мы сходу там нашли оператора службы, начальника командированного, самого командированного — а роли программистов и менеджеров службы остались в прошлом проекте создания службы и там внутри создания софта)? Кто исполняет эти роли в команде программистов, в команде создающих службу менеджеров, в команде создающих деловую поездку (даже если в этой последней команде нет ощущения команды и даже проектом это никто не считает, но это же проект, и участвует в нём много людей, им надо договариваться и уметь сыграть свою ролевую игру!). Беда, если вы считаете «нашим проектом» проект создания софта, а в момент приёмки проекта в эксплуатацию, или в момент возникновения трудностей в связи с тем, что нет исполнителей других ролей в полноценной службе оформления поездок (время эксплуатации системы создания поездок) спрашивать начнут с текущего разработчика софта! Объяснений, что «мы считали, что от нас нужен только софт, а людьми займётся кто-то другой», слушать ведь никто не будет! В конечном итоге нужны оформленные деловые поездки, или даже сами полные деловые поездки (в которых сотрудники ухитрялись сходить в неоплачиваемый ресторан или переночевать в гостинице, которая не выдала никаких платёжных чеков), а то и выполненные удалённые дела — ибо важны в конечном итоге именно они, и если они сорвались по причине трудностей деловой поездки или оформления деловой поездки, то это «внутренние ваши трудности, а вот за выполненные дела отчитайтесь»! В зачёт идут только ожидаемые общие результаты деловой поездки, и если без каких-то людей-сотрудников службы оформления деловой поездки софт их сам выдать не может, то нужно будет «изготовить» и этих сотрудников, т.е. обучить новым методам работы ещё и каких-то людей, а ещё нужно будет обучить новым методам работы и начальников командированных, и самих командированных агентов!

Заметим, что всё сказанное по поводу проекта создания софта для оформления командировок не даёт чёткого ответа на вопрос: как же организовать оформление командировок. Но зато показано, как системное мышление даёт набор объектов, который удобен для обсуждения альтернатив. Можно не обсуждать то, что же именно нужно обсуждать. Обсуждать нужно сразу системы, их окружение, внешние проектные роли, графы создателей и отдельных создателей в них (как инструментарий, как провайдеров/службы с их сервисами, как агентов индивидуальных или коллективных), методы работы, роли и т.д. — мышление задействует объекты не любых типов, а именно этих типов, и эти типы берутся как раз из руководств по программам рабочего и исследовательского развития).

Ещё один пример: магазин предоставляет сервис покупки — он создаёт покупку как какой-то набор товаров, находящихся в собственности покупателя в его руках на выходе из магазина, и деньги покупателя на счетах магазина (о деньгах думаем как о физическом золоте, можем не отвлекаться на безналичные расчёты и их «нефизичность»). Магазин помогает сделать/создать/изготовить (инженерная терминология!) покупку: он сводит покупателя со своими полками и кассовыми аппаратами.

И тут надо различить два значения термина «покупка»:

• Процесс/метод/сервис, шоппинг/shopping — метод работы магазина, меняющий состояние товара с «выложен на полке» на «стал товаром в покупке», а денег «в кошельке покупателя» стали «платежом за покупку». Например, «чтобы завершить покупку, нажмите кнопку «оплатить»».

• Товар, который был куплен и собственность на который перешла в руки покупателя. Например, «разверни свою покупку, посмотрим, что купил».

Если это интернет-магазин, то «покупка» в этом значении становится наряду с платежом «поставкой», и там такая же путаница поставки::метод/сервис товара::«предмет поставки» и «платежа»::сервис денег:: «предмета платежа» с поставкой::«предмет поставки-сервиса» как уже бывший товар, а ныне собственность покупателя у него в руках, а также платежа::«предмет платежа-сервиса» как деньги, но уже на счетах у продавца. Иногда вводят и термин «поставка против платежа» — это тоже иногда конечное состояние товара и денег, но иногда — сервис интернет-магазина или маркетплейса (агрегатора магазинов плюс службы доставки).

Сервис::поведение и «предмет сервиса»::«предмет поведения» в бытовой речи тоже нещадно путаются, как и сервис::повдение и сервис-провайдер (в IT сервис-провайдер может быть назван микросервис или сервис, но не микросервер или сервер). поэтому внимательно следите за типами: что там объект, а что поведение объекта. В случае проекта магазина путаются метод/процесс покупки/поставки и предмет, который куплен-поставлен (его тоже назовут «покупка» или «поставка»). Если вы купили три килограмма сахара, потратив на это десять секунд в интернет-магазине, то в одном случае можно будет сказать «моя покупка заняла десять секунд», в другом случае — «моя покупка весит три килограмма».

Сервис покупки (поставки) и платежа — поведение провайдера сервиса в части паттернов этого поведения (способ/метод работы провайдера, когда он работает над чужим предметом метода, подразумевается, что магазин не производитель товаров/изделий/продуктов, а именно сервисная организация, «переработка чужого»), а в итоге у нас в руках (а у магазина на счетах) покупка (поставка) и платёж как материальные объекты — это результат предоставления/оказания сервиса/услуги, проведения работ сервиса: (бывший) товар в руках покупателя и деньги на счёте магазина.

В парикмахерскую приходят за стрижкой как работой сервиса или за причёской как результатом стрижки, итогом предоставленного сервиса? По большому счёту, за причёской. За результатом сервиса. Но главное там — стрижка и укладка как процессы/методы/сервис. В магазинах (и практически везде в других системах создания, по факту это часто предприятия или их части) то же самое. Сервис доставки в интернет-магазине имеет целевой системой «доставку», понимаемую как уже доставленный и оплаченный пакет уже в руках счастливого получателя этой «доставки». Этот интернет-магазин с его сервисом «доставки» (процесс/метод/способ работы) задействуется для получения «доставки» (бывший товар в его конечном состоянии нахождения у покупателя) примерно так, как парикмахерская с сервисом стрижки и укладки задействуется для получения причёски и шлифовальная мастерская с её сервисом шлифования задействуется для получения шлифа. Само слово-термин «доставка» в разных случаях может обозначать как сервис, так и целевую систему, обрабатываемую этим сервисом, так что его значение нужно обязательно уточнять. Отглагольных существительных нужно бояться: иногда они означают поведение/«глагол», а иногда и какую-то вещь/«существительное» как результат этого поведения.

Этот сервисный подход (сдвиг с изделий/продуктов как наших или целевых систем на заказ отдельных работ по каким-то методам для их получения) сдвигает внимание с рассмотрения только собственных проблем создателей «меня волнует мой завод, производящий товар/продукт» на рассмотрение также и проблем многочисленных подролей «клиента/заказчика», делает шаг к более детальному описанию подролей. В сервисе «продажи» магазина-провайдера (тут ещё важен и референтный индекс, то есть от чьего лица делается референция/«описание предметов/референтов» — для магазина этот сервис «продажи», для клиента во всех его подролях — сервис «покупки») надо бы учесть минимально:

• Бенефициар («конечный пользователь» создаваемой системы, хотя и пользователь тут слишком общее имя — мы говорили, что лучше для игры говорить не «пользователь», а игрок, для токарного станка говорить не «пользователь», а токарь, для мороженого — едок, а не «потребитель»). Скажем, девочка, которая будет носить купленное в магазине платье.

• Плательщик — с чьего счёта (кредитной карты) уйдут деньги. Например, кредитка папы, оплатившего покупку платья для девочки.

• Собственник, на чьё имя оформляется купленная вещь, выписывается гарантия. Это и будет обычно «покупатель». Например, это мама, покупающая платье девочке.

• Получатель (представитель) собственника. Например, дедушка, который встретит курьера из магазина — ибо девочка в садике, мама и папа на работе.

• Консультант. Например, подружка, которая запретит девочке носить платье, ибо оно не удовлетворяет её представлениям о моде. И поэтому уговаривать купить платье (магазин и производитель платья ведь занимаются маркетингом!) надо в том числе и консультанта!

• … и этот набор подролей «покупателя/клиента» можно продолжать.

Провайдер сервиса (участник графа создателей целевой системы) со всем своим мастерством и инструментами проведения работ по сервису выживает в долгосрочной перспективе только в том случае, когда нет вопросов к качеству результирующей целевой системы как результата сервиса. Если целевая система в итоге оказания сервиса получается плохая, а создатель-провайдер при этом восхитителен, то жизнь этого провайдера сервиса закончится в момент окончания инвестиций её создателя⁵.

Если владелец магазина будет заботиться не о состоянии покупателя и размере покупки в момент ухода покупателя из магазина, а просто о своём торговом зале, то покупатели будут только мешать торговому залу быть в идеальном состоянии! Корабли лучше всего сохраняются в порту, в гавани. Но их строят не для того, чтобы они стояли в гавани: их место в открытом море, где много опасней и хлопотней, но без этого не будет создана целевая система: груз в месте его назначения. В конечном итоге нужен не столько нетронутый инструмент и незадействованные работы мастерства, сколько, целевая система и какая-то работа и тем самым износ создателя целевой системы — та самая «покупка» или «доставка» для магазина, та самая «оформленная деловая поездка» для бухгалтерии. Тут, конечно, требуется лидерство, ибо если магазин не будет торговать, его просто закроют, а вот если бухгалтерия не будет оформлять деловых поездок, будет делать всё, чтобы этих деловых поездок не было и ничего не надо было бы оформлять, то её могут и не закрыть. Но это уже вопросы системного менеджмента, само по себе системное мышление только даёт объекты, которых достаточно для подобных обсуждений.

Давайте ещё раз разберём пример целевой системы «лот», там тоже акцентируем внимание на сервисе. Нефтеперерабатывающий завод производит небольшие порции какой-то фракции перегонки нефти. Эта фракция почти ничего не стоит, «отходы производства». Провайдер сбора::сервис лота::целевая система железной дорогой доставляет эти порции к месту на побережье, где сливает их в арендованный огромный резервуар. Потом, после заполнения этого резервуара провайдер сбора лота переливает фракцию в танкер и отправляет на переработку на один из химических заводов. И получает на выходе весьма дорогое сырьё. Почему ему нужно собирать лот на побережье в резервуаре, который ему даже не принадлежит? Химзавод не примет маленькую партию фракции, ему подавай сразу большой танкер. Почему не собирать маленькие порции в танкер? Танкер дорого стоит, и лучше бы ему быть в пути, а не стоять в порту и ждать прибытия маленьких порций фракции-сырья. Целевая система для провайдера сбора (предмет сбора) — лот::«единица торговли или переработки». Если не будет собранного лота, то не будет переработки фракции химзаводом. Вот поэтому провайдер сбора изготавливает лот путём накопления маленьких порций дешёвой фракции, получая большую порцию, которая позволяет ему заключить контракт на переработку: эта большая порция и есть лот. Следовательно, у нас в рассмотрении — провайдер сбора::сервис лота::«предмет сбора» (и этот же «лот» — целевая система для проекта создания провайдера — а не организация провайдера!). Провайдер изготавливает этот лот путём ведения работ по сбору лота как прохождения «сеансов» сбора как закупки и перевозки к резервуару отдельных порций сырья.

Провайдер обучения::сервис изготавливает мастерство::система, которое обучаемые будут эксплуатировать после обучения. Мастерство определяем как специализированный вычислитель (устройство), реализуемое частью мозга, а сам мозг рассматриваем как универсальный вычислитель. Вычислитель можем рассматривать вместе с устройствами ввода-вывода (в том числе манипуляторами и датчиками, ушами-глазами-руками-ногами-зубами — телом), а если нужно как-то задействовать силу тела, то обучение тренирует не только мозг, чтобы в нём выросло мастерство, но и тело, чтобы как-то наросли мышцы и фасции, нужные для эксплуатации мастерства. Телу можно дать инструменты, так что мастерство задействует не только себя самого (только обработка информации) или себя с телом (даже ввод-вывод информации для размышлений — это уже действия не только мастерства-вычислителя, но и тела), но и инструменты. Тело тут можно считать тоже инструментом, а мастерство — контроллером всех телесных и внешних (экзотелесных) инструментов. Подробней об этом всём говорится в руководстве по инженерии личности, ибо личность — это совокупность всех видов мастерства какого-то агента.

Создание провайдера обучения::сервис/метод мастерству::«целевая система» какого-то метода («создание создателя мастерства», но в этой формулировке нет сервиса/функции/метода создания, то есть не упомянуто «обучение») тоже может служить примером, который легко модифицировать как прототип для разных других проектов обучения::сервис: от классического программирования компьютера (трудно считать это «обучением», тем не менее) до корпоративных/организационных изменений (самых разных людей в фирме надо научить выполнять с удовольствием свои рабочие роли), и даже маркетинг можно рассматривать как частный случай (научить человека использовать какой-то продукт или пользоваться сервисом, начиная с того, что научить его покупать, как только увидишь, а если не увидел, то ещё и искать, чтобы купить!). Создание провайдера чего угодно имеет целевой системой не самого этого провайдера, а предмет его сервиса или какую-то иную целевую систему, которую помогает создать предмет его метода (если, например, предмет его сервиса/метода — описание, то целевую систему надо искать где-то ещё дальше в графе создателей).

Хорошие целевые системы — игровые сессии, которые создаются провайдерами игр (провайдер сервиса игры, игровая сессия как создаваемая сервисом система, чем больше скорость выпуска игровых сессий, тем больше может быть доход провайдера). Игровая сессия состоит из игроков в определённом состоянии, игрового оборудования в определённом состоянии (скажем, игровой компьютер, датацентр, связь между ними) и административного и игрового софта на этом оборудовании в определённом состоянии.

Если речь идёт о провайдерах безопасности, то никто не понимает, что это такое, договориться невозможно. Но как только вы скажете, что делаете, например, сигнализацию для каких-то понятных неприятностей (а непонятное слово «безопасность», похожее на название свойства, табуируете) — всё волшебно налаживается. И тут надо разобраться, что вообще обсуждается:

• Событие «неприятности» — можно ли тут рассуждать о нём как о мероприятии, по типу «танцевального перформанса», или это просто момент во времени и такого рассуждения не получится?

• Сигнализация — это что: инструмент, который выдаст сигнал, или метод/функция/сервис такого поведения? С отглагольным существительным надо быть осторожным.

• Тем самым: вы делаете сигнализатор::инструмент или провайдера сервиса сигнализации (например, людей плюс сигнализатор::инструмент, и это будет «служба сигнализации», а не «сигнализатор»)?

Целевые системы бывают самые разные, сервисы и их предметы бывают самые разные, типовых в плане объектов предметных областей (метаУ-модели) и тем более в ситуациях конкретных предприятий (метаС-модели) вы не найдёте. Но рассуждения про целевые системы, сервисы и их предметы — однотипны, если вы используете типы мета-мета-модели из наших руководств. Вопросы к самым разным видам сервисов задаются по одинаковым шаблонам, осмысленность ответов на эти вопросы легко проверяется.

Вы вашим сервисом будете менять состояния предметов сервиса, но каковы бы ни были эти предметы (описания, системы), вам надо добраться мыслью до каких-то систем, чтобы выбраться из мира описаний. Вы (в конечном итоге по цепочке описаний, или непосредственно, если речь идёт об обработке материалов) можете менять два типа систем вашим собственным сервисом:

• Какого-то из создателей целевой системы (команду с мастерством в каком-то методе и/или инструментарий). Создатель в ходе его работы (тут реже говорят «эксплуатации») будет задействован во время создания целевой системы, находиться где-то в графе создателей. Это часто будет называться «наша система», если вы создаёте и развиваете этого создателя, да и вы сами попадаете в граф создателей, разве что в нескольких отношениях создания от целевой системы.

• целевую, которая будет задействована где-то в потребительской надсистеме в ходе эксплуатации/использования/функционирования целевой системы. Это означает, что вы в графе создателей стоите в одном шаге/ребре от узла целевой системы (или её частей).

В первом случае будет граф создателей: вы как оргзвено-1 создаёте и развиваете оргзвено-2, которое в свою очередь создаёт и развивает целевую систему. Например, вы консультируете пиццерию (проводите серии консультаций::сеанс), которая выдаёт после этого пиццы всё лучшего и лучшего качества. И тут можно рассматривать пиццерию как производителя пиццы::системы, а можно как провайдера сервиса быстрого питания::поведение.

Это могут быть и очень длинные пути/цепочки создания в довольно «кучерявых» графах. Вот пример такого пути/цепочки: вы консультируете совладельца холдинга, который проталкивает проект реорганизации цеха красок в штаб-квартире красильного холдинга, штаб-квартира занимается организацией реорганизации цеха красок, потом цех красок занимается собственной реорганизацией, потом реорганизованный цех выпускает новую краску. Вот эта новая краска — это и есть целевая система! А вот это путь в графе её создателей: консалтинг — совладелец холдинга — штаб-квартира холдинга — цех красок как реорганизатор — цех красок как выпускающее краски оргзвено. Но для всех них выпускаемая краска — целевая система, по поводу которой все и договариваются. А те системы, которыми они занимаются при создании целевой по этой цепочке создания, разные «наши системы» (engineered systems) для разных команд в этой цепочке. Подчеркнём, что целевая система, в которую целится весть граф создателей, одна: выпускаемая новая краска, если об этом не помнить, то трудно обсуждать, что связывает в один проект все эти проекты создания и развития «наших систем» в графе создателей. При этом у реорганизованного цеха «наша система» совпадает с целевой.

Не забывайте, что в обширных графах создателей все системы создают одна другую только для того, чтобы надлежащим образом создать и развивать целевую систему. Повторим, речь не идёт обязательно о «создании целиком с нуля», но может быть и создание MVP, затем продолжительное развитие системы, а ещё создание и развитие может быть частичным: может быть только описание создаваемой системы, изменение какой-то одной характеристики, настройка-регулировка, но всё это будут действия создателя во времени создания и развития создаваемой системы.

Если целевая система оказывается не нужна каким-то клиентам (не учитывает интересов клиентов), то у вас довольно скоро не будет денег поддерживать работу всех систем в графе создателей — неучёт интересов внешних проектных ролей в пользу облегчения работы команды ведёт к созданию неуспешной системы. Большая вероятность того, что облегчившая себе жизнь в ущерб клиентам команда денег не получит. Клиенты (внешние проектные роли) просто не заплатят ей за работу и поток денег на весь граф создателей окажется нулевым.

При этом всё сказанное про формулирование целевой системы как принадлежащей клиенту и обслуживаемой/изменяемой каким-то провайдером сервиса создания (в том числе не полному созданию, а части создания, например, только описанию, или такому частному изменению как модификация/настройка, проведение одной производственной операции, например, операция окраски для красильной службы), не является «объективной истиной» или даже «типовой ситуацией». Может быть и просто поставка товара как целевой системы из собственного сырья поставщика товара, а не провайдера сервиса создания. Не всё в мире пока сервис-ориентировано. Но это для системного мыслителя практически не означает смены мышления. Если понимать, что метод и сервис — это синонимы, разве что принято говорить о них немного по-разному, ибо речь идёт по большому счёту только о том, «чьё сырьё и чей продукт», а это не так уж много меняет в проекте.

Разнообразие ситуаций в самых разных деятельностях очень велико, так что конкретные решения по составу систем проекта и по выбираемым терминам мета-мета-модели и мета-модели придётся принимать самостоятельно: в каждом конкретном проекте, с учётом интересов всех и внешних, и внутренних ролей в проектах по всему графу создателей.

Конечно, в этом подразделе был дан только минимальный набор понятий онтики сервиса. Дальше, конечно, нужно рассматривать множество самых разных ситуаций, к которым эта онтика может быть как-то адаптирована. Скажем, прохождение сервиса будет у сырья/заготовки::«предмет сервиса», а также может быть не одиночной заготовкой, а их партией/batch, заготовка и конечный предмет сервиса/метода могут быть на разных системных уровнях (если это сервис сборки, то это и есть цель), сам сервис может состоять в неоднократном приложении каких-то методов к предмету сервиса (сеансы).

Вот несколько примеров рассуждений, где мы покажем использование разной лексики и чуть более детальные описания с использованием онтики сервиса с адаптацией к различным проектным ситуациям:

• Шлифовка (шлифование) — это операция::сервис/метод провайдера шлифовки, который изготавливает шлиф::«предмет метода» в заготовке. Заготовка тут — сырьё для будущей готовой системы как носителя шлифа, надсистемы шлифа — то есть тут готовая система «отшлифованная деталь» на системный уровень выше, а целевой системой операции шлифовки будет шлиф — если провайдер шлифовки мастерская, то целевая система у неё — шлиф, а если это просто шлифовальный станок где-то на заводе, то даже готовая «отшлифованная деталь», где шлиф только её часть — это вряд ли целевая система, но может быть «нашей системой») в ходе операции::сервис шлифовки. Заготовка принимает участие в сеансе шлифовки, равно как и провайдер шлифовки (подключаясь на интерфейсе к болванке). Будет ли переименована болванка/заготовка детали в деталь как готовую систему после шлифовки, зависит от того, насколько выполнение операции шлифовки и создания шлифа::«функциональная часть готовой детали» будет последней работой/сервисом (грубо говоря, «гусеница» переименовывается в «куколку» только если метаморфоз завершён). Дальше можно рассматривать, что тут провайдер шлифовки: шлифовальный станок, шлифовальный станок и обслуживающие его люди («оборудование и приписанные к нему люди») или люди и приписанный к ним шлифовальный станок (это одно и то же, но если «станок и его люди», то проще обсуждать автоматизацию, устранение людей, а если «люди и их станок», то проще обсуждать, с кем договариваться, если станок не работает). Чем больше людей в составе «провайдера», тем больше шанс, что это будет сервис и провайдер сервиса (будут какие-то передачи материалов в шлифовку, затем будут забирать результаты — у людей, а не у станка), если нет — то просто инструмент какого-то создателя как сотрудника и метод работы этого создателя (никто ничего не «отдаёт в работу» и не «забирает из работы», это всё внутренние передачи между своими, ничего «чужого», никто никого не обслуживает, просто совместная работа в команде).

• Курс обучения — это сервис провайдера курса, который изготавливает мастерство в студенте::заготовка (тут тоже студент — надсистема-носитель для будущего мастера::«готовая система», носителя целевого для курса мастерства) в ходе «прохождения курса», состоящего из занятий::«сеансов сервиса». Студент::роль в 4D принимает участие (participation, специализация part_of) в «прохождении курса», то есть наборе занятий, равно как и провайдер курса, говорят о «наборе занятий». Будет ли агент, отыгрывающий роль студента переименован затем в мастера:: «готовая система» — точно так же зависит от того, последний ли это набор занятий курса в какой-то их серии курсов. Моделировать ли курс как мероприятие (система) или как процесс (прохождение курса студентом у провайдера курса) — обсуждаемо, лексика будет чуть разной. Несколько студентов, проходящих курс и их преподаватель можно представить, например, потоком::системой (с точки зрения провайдера курса, разные группы — разные потоки), группой — с точки зрения деканата, ибо группа сохраняется, проходя разные курсы в какой-то последовательности, как «сеансы». В потоке агенты, отыгрывающие роли студентов::«заготовки мастера» взаимодействуют не только с преподавателем (или компьютером, к которому приписан преподаватель — если планируем автоматизацию и в конечном итоге убрать людей), но и друг с другом при групповой работе. Подробней это всё разбирается в руководстве по инженерии личности.

• Игра — это сервис провайдера игры, который стимулирует продуцирование дофамина в организме игрока в ходе работ по задействованию сервиса («прохождение игры», состоящее из «сеансов» игры::сервис/метод работы провайдера игры). Игрок принимает участие в прохождении игры через участие в сеансах, равно как провайдер игры (и в групповых играх участники могут взаимодействовать и с провайдером, и друг с другом). Игрок не становится после игры «готовой системой» (хотя меняет состояние! Устаёт, или отдыхает, или злится от проигрыша) и тем более не становится «готовой системой» после сеанса игры (нет аналога переименования «гусеницы» в «бабочку» с возможными промежуточными состояниями, ибо нет какого-то радикального изменения, даже такого не слишком выраженного, как превращения «студента» в «мастера»).

• Курс лечения — это сервис провайдера лечения (курс считаем сервисом::поведением, а не мероприятием), который изготавливает здоровую часть организма в пациенте::«заготовка будущего здорового человека, носителя уже здоровой после курса лечения части») в ходе прохождения курса, состоящего из «лечебных процедур»::«сеансов лечения».

Ещё нужно смотреть на способы моделирования проектов по организации сервис-провайдеров: проекты можно моделировать как работы по каким-то методам (проект::поведение), но можно и считать организацией проекта (проект::организация). Будьте внимательными к типу того, что у вас называется «проект»:

• Проект организационного совершенствования/улучшения/improvement — это экземпляр работы (проект::работа::поведение с чётким сроком начала и конца, понятным результатом принятого метода/стратегии выполнения проекта, известными ресурсами) сервиса службы/провайдера орг-развития, который в ходе прохождения проекта улучшения за время ряда шагов улучшения (сеансы) вносит какие-то настройки/переключения в мастерстве как предмете метода/сервиса без изменения онтики этого мастерства (например, в настройки шлифовального станка вносятся коррективы, а обслуживающие станок операторы проходят тренинг, чтобы не смотреть каждый раз в инструкцию, а делать всё «по памяти». В этой ситуации не появляется никаких новых понятий и отношений, онтика шлифовки не меняется. Вот и в ходе оргсовершенствования ровно такие изменения, а не замена, например, шлифовки на напыление — и поменяется буквально всё, людей и AI надо будет переучивать на новый метод, инструментарий метода заменять). Альтернативный вариант моделирования ситуации — это проект как организация (люди, AI, инструментарий с понятными полномочиями по распоряжению трудом и капиталом). Проект тут провайдер, работы и сервис/метод плохо различимы — оргсовершенствование (работы одного задействования метода/сервиса оргсовершенствования). Как надо? Надо понимать, что бывают эти два варианта. Более классический, конечно, когда проект::«работа по методу»::поведение, а провайдер проекта — рабочая группа проекта.

• Проект оргразвития — это экземпляр работы сервиса офиса/службы::провайдер развития, который изготавливает новое мастерство (развивает уже имеющееся мастерство, то есть добавляет фичу, «модернизирует», что-то делает с текущей онтикой мастерства) и добавляет инструментарий в «новой оргвозможности»/«new capability»::«готовая система» в ходе прохождения проектом оргразвития ряда шагов развития, состоящих из курсов::проект обучения и лидерских мероприятий::проект для людей, а также проектов подготовки инструментов/оборудования (это специализации «шагов развития»::сеанс). Альтернативный вариант моделирования ситуации — проект это рабочая группа проекта (организация) оргразвития, включающая переучиваемых или вновь обучаемых людей, а также работников службы оргразвития. Тут опять-таки будут сложности с тем, что там сервис (оргразвитие::сервис::поведение) и кто над кем трудится. По этой линии (проект как организация) есть сложности моделирования (которые можно преодолеть по линии «программа проектов и портфель проектов — это программа и портфель организаций», но разговаривать в таком языке будет сложно), проще считать проект экземпляром работы по выполнению метода (это классика дисциплины project management, по этой линии проблем не будет).

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

Моделирование: сервисы в компании

Опишите от пяти сервисов в вашей компании:

Ты — член команды

Целевая система обычно выявляется для команды большого проекта и становится известной для координации работ внутри проекта. При этом, конечно, допускается, что большая компания может выпускать несколько видов продуктов и их не удастся представить одной целевой системой, это не слишком меняет ход рассуждений. Ошибка в том, что целевая система выявляется индивидуально в каждой маленькой команде, а уже эти маленькие команды пытаются связаться в один большой проект. Получается обычно так, что если одна команда заявила, что её целевая система «печень», другая — «кишки», третья — лекарство от болезней печени, то они потом будут пытаться объединиться в какой-то проект, но это будет трудно: печень окажется свиная, кишки — полевой мыши, лекарство будет от болезней лошадиной печени, а проект вдруг окажется лечением человека. Нет, тут делается всё-таки ход на то, что целевой системой будет здоровый человек, на входе — человек с больной человеческой печенью и дальше будет выстраиваться граф создателей, исходя из этой целевой системы. Ветеринарные подразделения будут или перепрофилированы, или выкинуты из проекта за ненадобностью — сколько бы они ни настаивали на том, что они системно выявили свои целевые системы. Свои системы — это не целевые, считать свои системы целевыми обычно в проекте могут не слишком много людей, у остальных это — эгоизм, попытка перетянуть одеяло на себя.

Напомним: целевая система вводится не как что-то «объективное», а для того, чтобы скоординировать работу в сложном графе создателей, чтобы было понятно, чем там все эти люди, AI, организации занимаются, что там должно появиться в результате проекта.

Системное мышление будет координировать в проекте работы самых разных агентов в самых разных ролях по самым разным методам, а не просто давать мыслительное превосходство одних агентов над другими. Это не боевое/спортивное мышление соревнования и победы (хотя выигрывать в конкуренции оно помогает), но мышление договорённостей и сотрудничества.

Вы как «член команды»/«внутренняя проектная роль» совсем необязательно заняты работой над целевой системой в её целостности. Вы можете быть заняты разработкой подсистемы для целевой системы, или даже подсистемой подсистемы, или даже созданием какого-то создателя (инструмент или даже оргзвено с людьми, AI и инструментами) в графе создателей — но это будет просто ваше личное мнение, что вы занимаетесь «собственной целевой системой», вы можете оставить это мнение при себе.

Вы занимаетесь «вашей системой»: это, конечно, по типу тоже система, но просто не целевая система, а важная для вас и вашей команды. В рамках проекта, в общении с вашей командой вы будете обсуждать вверенную вам подсистему или даже подсистему подсистемы, или даже создателя какой-то подсистемы в составе целевой, или даже клиентуру как систему. Вы вполне можете называть такую вашу систему «моя система», это же никого не смутит, это чистая правда. Но не надо требовать от команды признания вашей системы (система, которая только для вас engineered system, маленький винтик в большом аппарате, или пять подпрограмм в огромном программном комплексе, или даже вся фирма, которая занята выпуском целевого продукта/изделия или оказанием сервиса для чужих целевых систем) полноценной целевой системой для всех. Нет, вы должны делать три вещи:

• Уверенно называть целевую систему. Если вы не понимаете, что там целевая система, то что бы вы ни принесли в проект, чем бы ни занимались — это может оказаться ненужным. Поэтому сначала давайте поймём, что все вместе делаем в полном проекте по созданию целевой системы, а только потом будем разбираться с вашими проблемами вашего мини-проекта.

• Уверенно называть вашу систему, и тут всё то же самое, что для целевой, только речь идёт о вас или о вашей маленькой команде маленького проекта в составе большого проекта.

• Не забыть о том, что ваш маленький проект нужен только для того, чтобы была успешна целевая система. Поэтому потрудитесь показать причинно-следственную связь с успехом целевой системы того, что вы делаете и чем заняты.

Так, у топ-менеджера может быть три проекта: А, Б, В. И он неделю убил на разбирательство с проектом Б. На это время он называет «своей системой» проект Б. Проверяем:

• Уверенно ли он называет целевую систему, для которой работает в конечном итоге проект Б? Или он исторически занимается проектом Б, который уже вообще никому не нужен?

• Что там его система? «Проект Б» — это поведение рабочей группы проекта? Тогда проект не система, с самого начала ошибка. Меняем понимание: система этого менеджера — организация: команда проекта Б, «рабочая группа проекта». Это уже лучше, но если это топ-менеджер, то лучше бы он своей системой для проекта считал бы продукт/изделие для проекта Б, а если речь идёт о сервисе, то его система — это та система, состояние которой меняет своим сервисом команда проекта Б. Нацеленность должна быть сначала на результат, а не на создателя, а на создателя — после понимания ожидаемого результата! Отлично, вот это уже похоже на системное мышление.

• И вот тут третий пункт: надо показать причинно-следственную связь того, что вот прямо сейчас занятие нашего менеджера проектом Б как-то поможет выпуску целевой системы. Или качество целевой системы будет лучше, или цена станет дешевле, или снимутся возражения каких-то внешних ролей для всего проекта (а не системы проекта Б), или скорость выпуска целевой системы вырастет? Для этого нужно понять, где в графе создателей находится система этого менеджера и выдать причинно-следственную связь, рациональное обоснование решения. Если окажется, что ничего в целевой системе не поменяется, то менеджер выделил время на ерунду, безделицу, хобби. Он должен обосновать, почему не работал над А или В, а работал над Б. Для этого можно обратиться к обоснованию со стороны теории ограничений (операционный менеджмент, вы в предыдущих руководствах программы рабочего развития знакомились с современной версией этой теории, TameFlow⁶). Тревожный знак тут будет, что менеджер, занимаясь Б, подтвердит, что никакого немедленного эффекта его действия на целевую систему не дадут, а он делает «заделы». «Заделы» — это вред, это омертвление капитала, это work in progress, и операционный менеджмент с этими «заделами» борется, это привнесение рисков в работу. Вот эта связь «нашей системы» с «целевой системой» по цепочкам отношений создания, развития (в том числе проектирования, изготовления, изменения состояния и т.д.) и часть-целое — она должна предъявляться, а выделение времени на занятия «нашей системой» (одной из всех возможных систем проекта) — обосновываться. Почему занимались нашей системой, а не какой-то другой, не помогали соседям, например? Если связь не предъявляется, а потраченное на нашу систему время не обосновывается, то вы не можете сказать, пользу приносит эта работа, или вред.

Вы можете быть также заняты разработкой системы создания (например, реализовывать проект развития какого-то оргзвена: парикмахерской), то есть непосредственно сами не будете заниматься целевой системой. Но это не значит, что вы будете называть парикмахерскую целевой системой во всём проекте. Во всём проекте вам нужно создавать причёски, а в вашем проекте — создать парикмахерскую. Не нужно путать эти два проекта, считать их одним. Вам нельзя считать, что целевая система для вас это та, которая для всех остальных будет системой создания. Нет, ваша целевая система та же, что у всех, а именно, которая изменяется работами систем создания, в том числе теми системами создания, которые делаете вы в графе создателей, то есть вашими системами. Вы в проекте создания причёсок, вот и объясняйте, как ваши действия с парикмахерской что-то дают для создания причёсок. Например, увеличивают выпуск причёсок в уже действующей парикмахерской, или приближают выпуск причёсок в ещё не введённой в строй парикмахерской, или дают возможность выпуска более выгодного типа причёсок, или удешевляют процесс выпуска причёски, и т.д. — везде тут важно, что речь идёт о причёске, и если причёски в рассуждениях нет, то к вашей работе по улучшению парикмахерской сразу будут вопросы.

Если организуете авиазавод, то целевая система — самолёт, если консультируете организаторов авиазавода, то лучше бы вам считать целевой системой самолёт, чем этих организаторов! Самолёт, который летает (в момент эксплуатации) — вот целевая система, поэтому расскажите, как вы добиваетесь того, чтобы самолёт летал, и летал хорошо, и был дешёвым. Если консультируете организаторов завода — как ваши консультации помогут самолётам? Если никак, то и без ваших консультаций всё останется как было — разве что вы консультируете не организаторов авиазавода, а, например, владельцев каких-то пакетов акций, которые они хотят перераспределить. Но тогда сам авиазавод тут не при чём, речь идёт о консультировании по поводу инвестпроекта, и нужно честно назвать вещи своими именами — эта честность поможет всем.

Как в картах, каждый человек не строит карту с полярными координатами вокруг себя. Договорились в масштабах планеты о Северном полюсе как начале координат — и все на планете пользуются единой системой отсчёта, полюс никуда не скачет по прихоти какого-то одного человека или даже одной команды путешественников, он общий для всех. В системном подходе рекомендуется именно такой подход: договориться об общей целевой системе для всей большой команды проекта. И всем агентам договариваться о совместной деятельности, показывая причинно-следственные связи их работы с успешностью целевой системы.

Команда проекта — это совсем необязательно группа проекта под твоим руководством! Скорее всего, «ты» в этом «мы» занимаешь пару-тройку ролевых позиций, делаешь часть большого дела, не удерживаешь в сознании целую систему, а занимаешься либо какой-то отдельной практикой/культурой/видом труда (теплотехникой, менеджментом, программированием, хореографией), либо какой-то частью системы, либо клиентурой системы. Если у тебя часть целой системы, или система в графе создателей — это будет «наша система» для маленькой команды или «моя система» для тебя лично.

По поводу неё вполне можно и нужно развернуть полное системное мышление, вот прямо как про целевую систему, разве что не надо считать её целевой и называть целевой. Первый шаг тут — найти настоящую целевую систему всего проекта (как обычно в системном мышлении: смотреть не в детали, внутрь, а от границ — наружу, в данном случае из границ «нашего проекта» наружу, в большой проект создания целевой системы). Целевую систему надо выявить, чтобы определить относительно неё место «нашей системы» — и дальше договориться со всеми по поводу нашей системы (квалификация «практик» в организационном развитии) и даже договорить всех (квалификация «мастер» в организационном развитии).

Нужно тщательно выявить ту целевую систему, с выбором которой будут согласны все участники проекта, синхронизироваться в действиях по отношению к которой будут все, и дальше разбираться уже с той системой, которая к тебе ближе всего (ну, или с той системой, которая для проекта сейчас нужней всего — если ты топ-менеджер, и ещё обосновать, почему ты занимаешься какой-то выбранной одной системой, а не соседними).

Большая ошибка — это считать себя объективным и нейтральным системным инженером, системным менеджером, эдаким системным рыцарем, который весь в белом и с нимбом над головой ведёт команду к успеху проекта. Вовсе нет, всё не так. Системное мышление чаще всего нужно именно для того, чтобы поднять свою осознанность: позволить осознать, какие у тебя роли в большом проекте по созданию и развитию целевой системы, какими методами ты работаешь с какими предметами этих методов, какое мастерство тебе нужно и инструменты, какие твои ролевые интересы, какое твоё место в большой команде и полномочия по распоряжению ресурсами большой команды, какой подсистемой целевой системы твоей большой команды или подсистемой одного из многочисленных создателей в графе создателей целевой системы ты занимаешься.

Тут нет никаких рецептов, всё определяется текущей ситуацией, никаких алгоритмов на эту тему нет — но есть набор объектов мета-мета-модели, которые задают список важных объектов проекта, о которых вам надо подумать и дальше договориться в масштабах как большой команды всего проекта по созданию целевой системы (например, механических часов), так и вашего частного проекта (например, проекта создания и развития стрелок для механических часов).

Команда проекта может быть и на пару тысяч человек сотрудников предприятия, а может состоять и из пары человек, и даже иногда из одного человека. Хотя в случае одного человека думать системно — это может казаться перебором, но поглядите на множество внешних проектных ролей, поглядите на множество создателей::системы (например, оргсистемы-создатели: ваши контракторы-подрядчики, поставщики инструментов и оборудования, провайдеры всевозможных сервисов), и вы не будете считать, что вы такой уж одинокий в проекте якобы «на одного», даже если вы один будете исполнять все многочисленные инженерные и менеджерские внутренние проектные роли, выполнять все нужные для успеха проекта методы работы. А с учётом внешних проектных ролей мышление в проекте всё равно будет коллективное, а не «личное», с внешними проектными ролями придётся договариваться и ещё договаривать их между собой.

Разделение на внешние проектные роли и команду может быть даже более дробным: внутренние проектные роли предприятия (юрлица) как «большой команды» и команда оргзвена (отдельного проекта или подразделения внутри предприятия) как «малой команды». Внутренние проектные роли предприятия как большой команды (например, финансисты, юристы, операционные менеджеры предприятия) заинтересованы в успехе целевой системы, но активно преследуют совсем иные интересы, нежели малая команда проекта для её «нашей системы». Если у вас в команде появятся лишние $1000 в проекте — вы куда их потратите? Это непростой вопрос:

• Улучшите на эту сумму целевую систему, не увеличивая её стоимости — т.е. подарите клиенту?

• Улучшите ресурсы команды — наймёте более квалифицированных людей, закупите более дорогое оборудование?

• Отдадите на дивиденды владельцам предприятия? Потратите на нужды «малой команды»?

Интересы всех ролей разные, причём эти интересы могут быть к разным системам — и действия по преследованию этих интересов поэтому оказываются разными, часто очень изобретательными, неожиданными для окружающих. Лучше бы вам всем в проекте договориться перед тем, как эти действия начнутся, или начнётся активная реализация самых неожиданных стратегий самых неожиданных агентов. Но для этого надо понимать, что «договориться в проекте» — это договориться по поводу улучшений в отношении выпуска целевой системы. Если ваша связь с целевой системой непонятна, то вы чужак, доверия к вам нет, договорённости с вами имеют слабую силу — и будут немедленно нарушены, если выяснится, что для успеха проекта в целом (успешности целевой системы) надо заниматься чем-нибудь другим.

Обычно много желающих сделать заведомо провальный проект, ибо исполнители ролей в этом проекте хотят получить зарплату, а результат самого проекта их мало волнует. Актёры с удовольствием сыграют свои роли в пустом зале: то, что за этот спектакль театр не получит деньги, их мало волнует (дирекция всё равно заплатит), а то, что зрителей нет, так ещё лучше: можно халтурить в исполнении ролей! То же происходит с заведомо провальными проектами. Системное мышление помогает осознать, что проект в части успешности целевой системы провальный, а затем настаивает на этическом рассмотрении ситуации. «Наш проект» может быть не провальный! Но этично его не делать, если он не ведёт к успеху целевой системы.

Нужно коллективно/группой договориться, что считать целевой системой, какие цели преследует проект, в чём состоят возможности проекта. И ещё нужно понять, какой именно коллектив/группа договаривается о том, чтобы создать и развивать целевую систему, это ведь тоже часто сходу непонятно. Но сначала нужно таки разобраться, что там за целевая система, а потом уже с «мы»: если непонятно, что мы делаем, то непонятно, кто вовлечён в это делание, кто такие «мы», кто с каким мастерством (и даже с каким уровнем мастерства, это ведь тоже важно) в проекте потребуется, а кто просто пришёл покушать/попилить ресурсы, а не вести целевую систему к успеху, и не вносит никакого вклада, или даже приносит вред.

Каждые пять минут менять то, что ты/вы называешь/называете целевой системой — это неправильно. Релятивизм (когда всё на свете считается субъективным и относительным, зыбким и неопределённым — заведомо отсутствует точка отсчёта, любой ученик пятого класса уважается в его мнении по поводу строительства атомной электростанции, любой дикарь уважается в его выборе целевой системы, да ещё и каждые пять минут все они меняют своё мнение, ни с кем не договариваясь) в мышлении не поможет. Договорённость по поводу целевой системы должна достигаться из каких-то принципов, а не произвольно, и на достаточно долгое время — желательно не менять целевую систему во время всего проекта, хотя понимание того, что это за целевая система, может уточняться постоянно. Конечно, в бизнесе рассматривается и вариант pivot/вираж, когда стартап меняет целевую систему. Но не обольщайтесь: во время этого «пивота» все понимают, какой новой системой они будут заниматься. И не все «мы» в этих проектах переживают вираж.

Моделирование: целевая система и ваша система

Заполните табличку для проектов создания трёх систем, в которых вы принимаете или принимали участие.

Признаки целевой системы

Целевая система выявляется/discover ситуативно, о ней договариваются командно, нет никакого алгоритма или «типовых ситуаций». Тем не менее, есть эвристики (правила, которые срабатывают часто, но не всегда⁷), которые помогают найти целевую систему какого-то коллективного проекта среди многочисленных самых разных систем в самых разных вариантах системных разбиений. Да, в системном мире царит вроде как хаос из совокупности самых разных субъективных мнений, но человек склонен упорядочивать и хаос, находить в нём паттерны — символ хаоса совсем не случайно выглядит весьма структурированно:

Надёжного алгоритма выявления целевой системы нет, вы просто будете делать много догадок и затем критиковать их, чтобы принять всерьёз ту догадку, которая пережила критику. Принять всерьёз — это действовать так, как будто эта догадка и есть верная. И так действовать, пока не появится догадка получше — тогда быстро бросать старую догадку и переходить на новую, действовать в реальном мире, опираясь на эту новую догадку. Есть множество приёмов мышления, которые помогут быстрее формулировать, а затем оценивать догадки по поводу того, что же в вашем проекте будет целевой системой.

Слово «выявление» (discovery) тут использовано не случайно: считается, что целевая система есть, она задана типом мета-мета-модели «целевая система»::система и её нужно только найти/выявить своим вниманием, определить её границы — возможно, поговорив при этом с большим количеством самых разных исполнителей самых разных ролей. Нас тут не смущает, что речь идёт о будущем — в пространстве-времени эта система уже существует, только в будущем отрезке времени, не прямо сейчас, это не мешает описывать целевую систему и её роль в надсистеме уже сегодня. Не смущает и то, что «поговорить со всеми» — это необязательно узнать их мнение, можно и наоборот — договориться с ними, что они согласны с вашим мнением о целевой системе. Вообще, неважно, кто именно высказал хорошую догадку о том, какова целевая система в вашем проекте. Это можете быть вы, это может быть какой-то AI, это может быть какой-то участник проекта. Главное, чтобы догадка была высказана, а потом она пережила критику.

Концепция использования как описание функциональности «чёрного ящика» системы в надсистеме — её не «выдумывают», не «разрабатывают», её как раз выявляют, договариваются по поводу того, что там будет с функциональностью системы, причём обязательно это документируют. Неправильно использовать вместо «документируют» термин «фиксируют», т.е. закрепляют описание. Концепция использования — это догадка, она будет уточняться и корректироваться до самого конца проекта, в модели системы как «чёрного ящика» всё время будут вноситься изменения, ничего «фиксированного» нет!

Договориться по поводу целевой системы, чтобы потом по отношению к ней договариваться обо всех других важных системах, в том числе о «нашей системе» — это подготовить концепцию использования, в которой описать целевую систему как вписанный в надсистему «чёрный ящик», удовлетворяющий интересы внешних проектных ролей. Основное в концепции использования — это сценарии использования, то есть поведение целевой системы в разных ситуациях, которые предъявляет ей окружение. А уж как целевая система будет устроена — это потом, это будет уже концепция системы. В концепции использования становится понятным, что в мире относится к целевой системе, а что попадает в её окружение в момент использования. Решения о том, как будет устроена система (концепция системы) и как будет устроено её создание и развитие (решения по составу и структуре графа создателей) логически принимаются потом, хотя обычно все они разрабатываются параллельно: концепция использования учитывает пределы возможного (чтобы не оказалось, что это концепция какой-нибудь скатерти-самобранки или ковра-самолёта, которые непонятно как сделать и непонятно кто будет изготавливать), но всё-таки вопрос ставится как «сначала опишем, что система должна делать, то есть какие объекты в окружающем мире в какое состояние приводить, а затем — из чего её делать и как она должна быть устроена, затем — какими методами её делать, и только затем — у кого есть мастерство и инструменты для поддержки таких методов, которыми систему можно сделать».

Например, вы хотите поручить каким-то другим людям-подрядчикам создать какую-то систему в вашем проекте (инструмент создателя в вашем графе создателей целевой системы или просто подсистему целевой системы), чтобы не делать её самостоятельно, то есть хотите купить уже готовую систему или попросить разработать и сделать систему «под заказ». Вы формулируете и документируете, что именно хотите купить у подрядчика, это и есть формулируете концепции использования этой заказываемой системы (раньше на основании этой концепции делались требования, в них часто отфильтровывалась и искажалась информация концепции использования — тот самый «испорченный телефон»). Для вас это будет система-инструмент создателя в графе создателей вашей целевой системы или просто подсистема целевой системы (или даже всё это не целевой системы, а вашей системы), а вот для подрядчика — это будет его целевая система! И он должен будет разобраться не в «изготавливаемой им системе» (время изготовления), а в «используемой вами системе» (время использования, и ровно это вы в своей концепции использования системы для подрядчика и прописываете).

На основании концепции использования вы делаете закупку. Сегодня обычно это не разовая и окончательная закупка, но предполагающая сопровождение — постоянные улучшения системы после момента её создания, продажи и начала эксплуатации. То есть предполагается, что вы не продукт покупаете, а работы сервиса по улучшению продукта, мир становится не продукт-ориентированным, как раньше, а сервис-ориентированным.

Целевая система находится в физическом мире, это точно не какое-то описание — хотя если вы типография или художественная мастерская, то вашей целевой системой вполне может книга или картина, но вас тогда не будет волновать описанное в книге или картине (документированное описание), но только «документ», а уж что там за описание — это проблемы авторов и читателей, не ваши. Но если вы не типография, и вас интересуют работы с содержанием информации (о чём документ: книга, картина), а не носителем информации (из какой бумаги), то сразу смотрите на содержание, а не на носитель информации — систему надо искать в том, что описано, система не ваше описание! Если вы говорите «моя система — проектная документация», то вы курьер, или владелец принтера. Если вы инженер, который занят проектной документацией — то первый же кандидат в рассмотрение будет та система, которая описана в документации.

Если вы делаете какие-то информационные модели, пишете тексты, создаёте базы данных (например, разрабатываете софт), рисуете схемы или чертежи, то это вы обычно делаете только описание системы, воплощённое в физическом мире как документация системы/системная документация, но не как сама система! Описание, даже документированное — не целевая система! Задайте себе вопрос: а что описано в документе, в базе данных, в информационных моделях, отражено на графиках и диаграммах, описано в текстах? Возможно, там описано другое какое-то описание (текст, таблица, диаграмма, описывающие другие тексты, таблицы, диаграммы — объекты ментального/понятийного мира, имеем дело с «описанием описания»), но, возможно, там будет описана ваша целевая система, или хотя бы её подсистема, или создатель из их графа (всё это — системы физического мира).

Уберите внимание к носителю информации (компьютер с софтом, сам софт), обратите внимание на данные этого софта: там наверняка будут подсказки, где искать целевую систему в физическом мире, эти данные описывают какие-то системы. Если данные софта описывают процесс сборки самолёта, то это описание поведения самолётного завода (время создания, описаны операции создателя — сборка::метод самолёта::«предмет метода»), но если у вас самолётный завод, то вы обязательно вспомните о самолёте (это же будет «предмет метода» для сборки) — и дальше вы просто задаёте вопрос о времени использования самолёта: понимаете, что его место не на заводе самолётов, а в небе, чтобы лететь куда-то с грузом и пассажирами. Ради этого «самолёт, который летит с грузом и пассажирами» всё это и делается: завод самолётов, а для завода делается описание процесса/метода сборки самолёта. Целевая система самолёт, завод — создатель в графе создателей самолёта, платят люди-потребители не за завод, а за сервис со стороны авиакомпании, самолёт — инструмент авиакомпании как провайдера сервиса, а для завода — это целевая система (он выпускает инструментарий авиакомпаний, ему платят за это).

Если вы говорите, что «система находится в физическом мире» — и показываете на носитель информации, то вам поверят только, если вы производите сам носитель, а не содержательно занимаетесь информацией на нём! Целевая система «книжка как документ» не у писателя, а у типографии или интернет-магазина электронных книг. А у писателя? Если это инженерный проект, то это было бы воплощение фрагмента мира, описанного в книге. Форма книги тут была бы не важна, а вот принятые по устройству этого фрагмента мира решения — важны. Если это образовательный проект, то можно было бы говорить о том, что создаётся при помощи книги участок мозга ученика (специализированная «мокрая нейронная сеть») как исполнитель какого-то метода работы. Этот участок мозга потом будет проявляться как провайдер сервиса мышления (или выполнения какого-то другого метода работы, с учётом задействования не только вычислителя как части мозга, но и тела, и даже инструментов как датчиков и эффекторов) в какой-то ситуации, для которой и было обучение этой части мозга — и целевая система тут не просто «участок мозга», но «участок мозга в момент его задействования для выполнения метода». Этот участок мозга в его функциональной роли вычислителя для выполнения метода работы мы и назовём «мастерство». А если брать всё мастерство агента, выполняющее все методы, которыми владеет этот агент? Это будет личность агента (и кроме личности там будет ещё и организм/тело). Если у нас в руках учебный курс или руководство, то мы смотрим прежде всего не на их носитель (компьютер датацентра, мозг преподавателя/наставника, книжка), но на содержание курса/руководства/регламента — знания/теории/объяснения/алгоритмы, которые описывают какую-то предметную область. И там два кандидата в системы, которые мы ищем:

• Мастерство, для создания которого этот учебный курс и был создан

• Предмет метода, описанного в курсе (скажем, если курс/руководство/регламент по выращиванию клюквы — то это клюква), а курс мы рассматриваем как справочник по предмету метода — системе. Не все методы работают с системами, часть работает и с описаниями систем или даже описаниями описаний, но часть предметов метода — это таки системы.

Такой мыслительный приём/метод уподобляет проекты по изменению поведения людей через изменение «мозгового софта» проектам по разработке компьютерного софта (можно было бы назвать это «нейролингвистическим программированием», но этот термин уже был занят в середине 70-х годов прошлого века конкретным методом такого программирования, описанным Джоном Гриндером и Ричардом Бэндлером, и тем самым оказался недоступным для общего пользования⁸. И да, Джон Гриндер и Ричард Бэндлер использовали системный подход первого поколения, им в этом помогал один из видных системных мыслителей этого поколения системного подхода — Грегори Бейтсон⁹). Этот приём/метод нередок при моделировании изменений, проходящих с людьми (образовательные проекты, продвижение каких-то продуктов и сервисов, психотерапия и т.д.). И помним, что целевая система определяется на момент её эксплуатации: то есть на тот момент, когда мастерство как соответствующая функциональная часть мозга (реализуемая на сегодня малопонятными конструктивными частями, но вполне материальная!) будет задействовано в выполнении работы с тем методом, которому мозг был научен в ходе обучения/терапии/программирования/кодирования (да, использовалось и слово «кодирование»!) и т.д. Мы уже неоднократно упоминали в нашем руководстве, как думать о системах, которые не изготавливаются из отдельных деталей, а обучаются. Более подробно об этом будет рассказано в руководстве по инженерии личности, а учитывая то, что организация тоже учится работать новыми методами (хотя она условно «собирается» из отдельных людей, AI и их инструментов, но всё равно люди и AI в ней потом научаются работать по новым методам), то и в руководстве по системному менеджменту.

Что будет целевой системой в детском садике Монтессори¹⁰. Ребёнок? А родители тогда что делают/изготавливают (создают и развивают), его же, ребёнка? Детский сад сервис, который выполняет какой метод работы над ребёнком, который не выполняют его родители? Садик — склад для ребёнка, где его хранят в то время, когда родители работают? Эвристика: в детском садике Монтессори идёт учебный процесс, ребёнка учат. Это значит, что целевой системой скорее всего будет какое-то мастерство: функциональная часть мозга, которая будет включаться в определённых жизненных ситуациях, уже за пределами садика. А детский садик будет только провайдером сервиса обучения. Эксплуатация мастерства как вычислителя/части мозга — за пределами садика.

Скажем, ребёнка должны там научить вести себя по методу разумной осторожности (не прятаться всё время за родителей, но и не лезть на рожон в любое доступное ему пекло), читать стихи, не теряться в незнакомой обстановке, быть собранным и не терять внимания. Это означает, что мастерство (то есть подготовленный таким образом вычислитель как часть мозга) должно не просто на выпускном утреннике в знакомой обстановке актового зала учебного заведения выдать чтение стишка с табуретки, но уверенное чтение стишка на каком-нибудь фестивале, где ребёнка поставят на железную бочку, фотовспышки будут со всех сторон, родителей оттеснят куда-нибудь в сторону, но обученный в садике кусочек мозга включится, даст спокойствие, уверенность и прочтение того самого стишка. Это и есть мастерство как результат обучения, вполне материальный объект (реализованный конструктивными частями мозга). И это будет через год после выпуска, мастерство должно быть изготовлено (инженерная терминология! Она позволяет говорить более точно!) так, чтобы через год умение не терялось. Весь персонал детского садика Монтессори должен вот это всё понимать: что результаты их работы надо будет смотреть не в самом детском садике, а за его пределами, возможно, через год. Впрочем, примерно то же относится и к школе, и даже к вузу, хотя в вузе даётся прикладное образование и поэтому можно задавать вопросы о ситуациях, где применяется мастерство, полученное в вузе. Но вот со школой и детским садиком такое рассуждение сложнее: ответ обычно «мы готовим к экзаменам», а экзамены как раз можно рассматривать как часть учебного процесса, а не использование мастерства в жизни (если научили не тому, что надо, то и экзамен можно организовать по тому, что не надо — мастерства в методе, которому учили, не будет, но будет мастерство сдавать экзамены).

Зачем так подробно это расписывать? Теперь вы знаете, какая целевая система в вашем учебном проекте (выполнили творческую/исследовательскую/предпринимательскую работу, ответили на вопрос «чему учить», какому мастерству учить — и ответ более-менее детальный, с перечислением того, что именно должен будет уметь делать выпускник), и только после этого вы должны задавать вопросы к системе создания: какие методы могут создать/изготовить (в нашем случае — обучить) такую функциональную часть мозга? Как должно быть устроено обучение для того метода, которому выбрано учить? Учить ведь математике, выращиванию морковки и рассказыванию стихов на фестивалях нужно разными методами — и только после того, как выяснится, что учить нужно именно этому (например, что детей надо учить именно рассказывать стихи, тратить время их детства именно на это умение)!

И дальше обсуждать уже методы обучения и ситуации этого обучения, каждый раз задаваясь вопросом о том, как это влияет на результат: мастерство, которое будет проявлено вне ситуации обучения. И если школа говорит, что «мы учим детей сдавать ЕГЭ», то можно усомниться, что «мастерство сдачи ЕГЭ» является именно тем мастерством, которому должна учить школа. А после обсуждения вопроса о том, какое же это должно быть мастерство, можно обсуждать методы изготовления этого мастерства: методы изготовления мастерства сдачи ЕГЭ при этом могут оказаться совсем другими, нежели методы изготовления жизненного мастерства как какого-то набора прикладных видов мастерства и фундаментального мастерства мышления, которые могла бы изготавливать школа.

Вот этот ход на то, что целевая система должна рассматриваться не в тот момент, когда она создаётся, а в тот момент, когда она эксплуатируется — он крайне важен и часто тут делаются ошибки. Причёска рассматривается в ситуации, когда идёт встреча с женихом, а не любая причёска на момент нахождения владельца волос в парикмахерской, когда там идёт стрижка и укладка и наблюдаются какие-то промежуточные состояния причёски. Шлиф рассматривается в момент его использования (то есть уже после шлифования и даже не в момент отдачи шлифа клиенту, а в тот момент, когда клиент уже установил деталь со шлифом в свою систему, и она работает). Все методы шлифования подбираются так, чтобы с этим использованием шлифа было всё в порядке. То же самое верно и для обучения людей, и для любых других проектных ситуаций. Вы должны дотянуться мыслью до ситуации использования/эксплуатации целевой системы, а когда договариваетесь про целевую систему со всеми остальными участниками проекта, то надо, чтобы и они признали целевую систему на момент использования, а не на момент её создания или продажи, или даже наладки. Нет, целевая система должна быть представлена в момент её эксплуатации/работы/функционирования/использования.

Целевую систему всегда придётся выявлять в ситуации недостаточной информации и разнообразия мнений на этот счёт. В каждом проекте она будет уникальна, справочника «типовых решений» и магического алгоритма её выявления тут нет, можно только давать примеры — в надежде, что эти примеры не будут восприняты как «делайте именно так», но нейронная сетка всё-таки заметит какие-то паттерны в этих примерах.

Системное мышление задаёт лишь набор типов, для которых надо найти в проекте объекты, чтобы обязательно подумать об этих объектах. Оно просто управляет вниманием в проекте, оно не указывает, как и о чём думать (указывает о чём думать в мета-мета-модели, но чтобы подумать хотя бы об объектах мета-модели, надо отождествить эти объекты с типами мета-мета-модели: выполнить выявление систем, разобраться с отношениями систем. Например, в учебном проекте понять, какое мастерство будет целевой системой — и дальше всех договорить по поводу этого мастерства). Если вам трудно принять решение по поводу целевой системы — это означает, что вы что-то плохо понимаете про ваш проект, и лучше бы вам подумать ещё, а также собрать больше информации, поговорить с исполнителями разных других ролей в проекте.

Документация (бумажная или электронная) — не целевая система, даже если речь идёт о толстой пачке проектной документации для высотного здания или даже если речь идёт об исходном коде компьютерной программы, или даже если речь идёт о каком-то сценарии городского праздника, или даже если речь идёт о какой-то компетентности в чьей-то голове. Возможно, целевая система — это то, что вы описываете на этом носителе. Возможно, вы описываете даже не целевую систему, а систему в окружении целевой системы, или подсистему целевой системы, или систему создания где-то глубоко в графе создателей. Главное тут — не путать системы и описания (даже если описания даны нам как документация). Целевая система — это не описание! Целевая система чаще всего — воплощение того, что описано!

Целевая система — это обычно то, что делает (то есть полномочно меняет сама, а не «влияет на то, что кто-то другой поменяет») команда проекта. Если завод выпускает конфеты, то конфеты — это и есть целевая система (при этом не эшелон конфет в момент заключения контракта, не ящик конфет в момент отгрузки магазину, не упаковка конфет в момент продажи, а вот прямо одна конфета, причём в момент её поедания и переваривания).

Если команда делает описание, по которому потом сделают систему — это непосредственное стратегирование (описываем методы/функции), а затем и планирование (кладём метод на ресурсы, превращаем в работу) изменения физического мира. Это не уговоры кого-то, чтобы он изменил свою систему, не «рекомендации аналитика», который обычно не имеет полномочий реализовать свои рекомендации даже для системы, которой занимается его команда. У команды есть какие-то полномочия по отношению к её системе, а также в силу участия в проекте целевой системы — по отношению к целевой системе. В отношении других систем (систем окружения, в том числе надсистемы, систем в графе создателей) полномочия команды сильно ограничены, влияние много меньше.

Целевая система — это очень часто то, за что команде в конечном итоге (после того, как система окончательно изготовлена и начинает успешно эксплуатироваться) платят деньги. Если команда делает информационную модель велосипеда, то в конечном итоге заплатит деньги потребитель за велосипед. Вот целевой системой тут и будет велосипед, деньги именно за это — информационная модель велосипеда тут просто описание велосипеда (даже если это документ, то есть описание на носителе). Но если команда делает алюминиевую раму велосипеда, и эта рама продаётся только в составе велосипеда (то есть продаётся велосипед, а не отдельно рама), то и рама не будет хорошо выбранной целевой системой. Она будет подсистемой целевой системы. Вместе с тем двигатель самолёта — хороший кандидат в целевые системы. Двигатель обычно (с небольшими модификациями) может поставляться для включения в состав разных моделей самолётов, двигателестроители работают в составе независимых более-менее автономных предприятий, поэтому двигатель — хороший кандидат. Но Роллс-Ройс продаёт авиастроителям не авиадвигатели, а часы работы двигателя, так что и тут возможны варианты: двигатель тут неразрывно связан с системами его обслуживания, и двигатель тут может быть только подсистемой.

Целевая система-продукт часто пересекает границу предприятия, идёт её «поставка» (delivery, при этом обычно в delivery включают и ввод в эксплуатацию, а не просто «логистику доставки на место»). Подсистемы обычно границу предприятия сами по себе не пересекают, сами по себе не разворачиваются и не вводятся в эксплуатацию, это с ними происходит только в составе целевой системы.

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

Если вы обнаружили, что целевой системой у вас является какой-то процесс/метод, то подумайте дважды или трижды, какая система осуществляет это поведение. Если отдых, то вашей целевой системой, скорее всего будет отдыхающий (причём созданный, то есть отдохнувший). Если жизнь — то живой агент, её проживший и не жалеющий о процессе жизни. Если танец (помним о многозначности слова! Тут это — перформанс, танцевание), то зритель, который воспринял этот танец, а иногда и сам агент-танцор, который «зритель себя», это ведь всё ролевые рассмотрения, один агент может играть в ходе перформанса две роли — и танцора, и зрителя. Мероприятие (фестиваль, перформанс, совещание — какие-то события с некоторой протяжённостью во времени и понятным составом участников) ещё можно представить системой, там можно ткнуть пальцем в составляющие этого мероприятия, собрать их в одном месте и одном времени — и затем использовать. А вот метод — это не мероприятие, а чистой воды поведение, его не надо делать системой, вы не сможете ни с кем договориться, вас не будут понимать, вы не сможете «изготовить метод». Хотя разработать описание метода — почему бы и нет, но дальше изготавливать по этому описанию вы сможете только мастерство агента и инструментарий этого агента, а потом агент встанет в роль и задействует метод в своих работах. А вот «изготовить мероприятие» — сможете, участники проекта будут вас как-то понимать.

Если у вас какой-то «рабочий процесс» (сервис/метод), то скорее всего интересует результат, предмет метода. Часто этим предметом метода будет система, «наша» или даже «целевая». Следите за типами: целевая система не стрижка::процесс/метод, а причёска (стрижка — один из процессов получения причёски, другой — укладка), не шлифовка::процесс, а шлиф (физический объект, на который легко указать в пространстве-времени, причём на момент его работы, а не изготовления), не доставка::процесс, а доставка как коробочка в руках клиента в месте назначения. У танцевания нельзя просто показать его материальный результат как достижение ожидаемых состояний предметов этого метода (хотя зритель в состоянии «доволен» или «заинтересован» и танцор в состоянии «без травм» — это вполне себе может быть результат), а вот у «рабочего процесса» или чего-то подобного результат (предмет какого-то метода в каком-то заранее оговорённом состоянии) обычно можно указать, вот и опишите этот результат в материальном мире — это более вероятный кандидат на целевую систему.

Целевая система — точно не процесс, но она наверняка как-то себя ведёт в ходе функционирования/работы, то есть меняет состояния чего-то вовне себя. Если нашли какой-то глагол, важный для описания результатов (приведения каких-то объектов в ожидаемые состояния — самолёт летает, компьютер вычисляет, мастер задействует своё мастерство), задайте вопросы по этому глаголу: 1. кто себя так ведёт? и 2. для какого результата, какой объект будет приведён в какое состояние? Получите сразу двух кандидатов в целевую систему.

Ответы хорошо бы получить «в ролях»/функциональных объектах, а если речь идёт об агентах, то одним агентом могут выполняться множество ролей. Один агент может сыграть роль многих систем. Все эти рассмотрения множества ролей агентов — первый шаг к рассмотрению возможности разделения труда, что важно для инженерии систем создания. Но для начала нам надо не столько заниматься ролями, методами этих ролей, разделением труда, сколько искать целевую систему. Если я причёсываю себя, то я в роли парикмахера и клиента одновременно. Но можно и разделить труд: отдать роль парикмахера агенту, который умеет причёсывать меня лучше, чем я сам. А результат? Причёска, целевая система! С неё и надо начинать.

Если договориться о результате проекта (какая система в каком состоянии должна оказаться), то тогда можно говорить и о разных рабочих процессах, к этому результату ведущих, разных сервисах разных создателей, которые помогут этот результат (целевую систему) получить.

Частые ошибки в выявлении целевой системы

Признаков целевой системы не так много, но всё равно агенты (люди, AI и даже целые их организации) делают ошибки, выявляя целевые системы своих проектов. Проблема в том, что системное мышление не подсказывает, что является правильным выбором целевой системы и не подсказывает, что будет в окружении целевой системы. Но польза системного мышления в том, что системное мышление указывает на то, что это важнейший объект в проекте — и заставляет выбрать, не даёт от этого выбора уйти! Как это понимать? Примерно так же, как вы заходите в огромный продовольственный магазин с пониманием, что надо купить «еды»: в магазине тысячи и тысячи продуктов, которые все подходят под понятие «еды» — но какая именно еда нужна вам в данный момент времени? Тип «еда» — это всё что угодно, что можно съесть. Но вам вот прямо сейчас что именно надо съесть? Три банки горчицы? Или сдобную булочку? Копчёную скумбрию? Гречку-ядрицу в расфасовке по 1кг пакетик, и потом есть даже без варки, потолочь в муку — и съесть сырой? Если вы не перейдёте на описание отдельных видов продуктов и не будете понимать, что потом делать с купленными конкретными продуктами (с каждым продуктом — что-то делать разными методами! Что-то кусать и жевать, что-то сначала подвергать «кулинарной обработке» разных видов, что-то пить), задача купить «еды» не будет решена. Вам надо определиться, что именно покупать, общий тип «еда» не подойдёт. Но это точно будет не табуретка, не автомобиль, не забор, ибо это всё — не типа «еда».

С системным мышлением примерно так же: для типа мета-мета-модели «целевая система» вам надо найти тип мета-модели для системы, который должен быть много конкретней, чем просто «целевая система», принадлежать уже к какой-то предметной области. Но это не должны быть объекты не типа «целевая система».

Мы уже писали о многих ошибках выявления систем, которые вы хотите объявить принадлежащими типу «целевая система моего проекта по созданию и развитию этой целевой системы», но повторим ещё раз, чтобы под рукой был маленький чеклист того, из-за чего студенты вуза уходят на пересдачу предмета «Системное мышление» (а если три раза не пересдадут — вылетают из вуза, как не готовые учиться, и прецеденты такого были!), а в рабочих проектах на пересдачу проекта уходят целые команды, и даже очень большие команды, и тоже вылетают в случае нескольких пересдач, в рабочих проектах не поощряют такого:

• Вы выдаёте описание системы за систему. Программисты считают, что их система — исходный код, а не программа в момент её выполнения (когда все переменные программы хранят состояние программы!), и уж точно не служба предприятия (оргзвено: подразделение, рабочая группа проекта), которая выдаёт результат, требуемый от программы, и без этой службы программа этот результат выдать не способна. Но исходный код — это описание, это информация, это не физический объект, который может хранить состояние мира в момент его использования и менять состояние мира вокруг. Проектировщики и конструкторы считают, что это проектная и конструкторская документация (неважно, в электронной или бумажной форме). То же самое: «документация» — это носитель информации, а сама информация — это не система. Сценарист считает, что это сценарий спектакля или фильма, а не сам спектакль или фильм в момент его просмотра зрителями. Хореограф считает, что это его тщательно продуманный набор движений, который он показывает танцорам (сам хореограф, демонстрирующий этот набор движений, и есть «документ описания», видеофильм, записи в какой-то нотации хореографы делают крайне редко), а не тот перформанс/«танцевальная композиция», который потом станцуют артисты-танцоры, хотя и с тем, что перформанс тоже целевая система, но его описание — оно «главнее». Модельер данных считает, что его целевая система — это модель данных, а не данные, структурированные в соответствии с моделью (например, база данных, собранных по модели/схеме данных), да и тут не делается последнего шага: целевая система обычно описывается этими данными, она не сами данные! Всё это, увы, более чем типичные ошибки. Мысль о целевой системе нужно доводить до момента изменения реальности в ходе эксплуатации системы, до воплощений, а не до описаний изменения реальности! Описать — это не сделать, не изменить мир! При этом недостаточно даже использовать «проектирование для изготовления» (design for manufacturing), хотя и это тоже нужно, тоже важно. Проектирование должно быть прежде всего озабочено эксплуатацией, изготовление тут только промежуточная стадия. Описание чего-то, удобного для изготовления — это не изготовленное физическое что-то, что приносит свою пользу в момент эксплуатации! Нельзя считать, что «воплощением занимается другой человек, организация, инструмент, а я готовлю описание». Нет, готовите вы описание только для того, чтобы потом оно было воплощено. Вот этот воплощённый объект — это и будет ваша система или целевая система, даже если не вы лично своими руками её изготавливаете. Вы принимаете участие в коллективном проекте по изготовлению какой-то системы. И вот эта система — ваша (и всех остальных) целевая система. Описания — это не система. Но если вы работаете каким-то методом создания описаний, то это описание вполне может быть предметом метода. Некоторые предметы метода — системы, но не все. Часть из этих предметов метода вполне могут быть описаниями, методы работы задействуются для самых разных объектов.

• Создатель/«система создания»/инструмент/«провайдер сервиса», как целевая система. Это типичная ошибка менеджеров: принять организацию, создающую целевую систему, за саму целевую систему (и при этом ещё добавить «это моя целевая система» — добавочная путаница между «наша/моя система» и «целевая система всего проекта»). Ошибка ведёт к процветанию организации на короткий период, пока не кончатся деньги инвестора. Если такому менеджеру поручить построить авиазавод, то он построит авиазавод, который будет восхитительно работать и все рабочие там будут сыты и ухожены — но самолёты этого авиазавода летать не будут, ибо завод будет строиться как целевая система, центром внимания всего проекта и его участников будет именно завод. Выпускаемые заводом самолёты не будут в центре внимания этого менеджера и менеджер не будет выделять достаточно ресурсов для выпуска качественных самолётов, он будет озабочен качественной заводской жизнью, а самолёты для него будут лишь цифирками «выпуска продукции». Типичный и обычный результат такого подхода — денег на компьютеры для финансовой службы менеджером выделяется больше, чем на компьютеры для инженерных расчётов целевой системы. Справедливости ради нужно отметить, что инженеры часто делают обратную ошибку: не замечают систем создания, без которых целевая система невозможна (то есть у них системное мышление ещё первого поколения, до важности обсуждения создателей и методов их работы они в мышлении не дошли), но об этом в нашем руководстве мы будем говорить позже.

• Одинаковые имена целевой системы и её части (или целевой системы и надсистемы), скорее всего нужно уточнить какое-то из использованных имён, обозвав иначе неполную систему (скажем, «дом состоит из коробки/строительной части дома, коммуникаций, отделки» говорить можно, а «дом состоит из дома, коммуникаций и отделки» говорить нельзя. «Ячейка состоит из корпуса и прокладки» говорить можно, а «ячейка состоит из ячейки и прокладки» — нельзя).

• Одинаковые имена для самых разных систем. Помним, что «командировка» — это могут быть 1. Удалённо делаемое дело, включающее деловую поездку к месту выполнения дела. 2. Деловая поездка как всё, что происходит в этой поездке. 3. Оформляемая часть деловой поездки как только то из деловой поездки, что можно провести по бухгалтерскому учёту (скажем, поездку на поезде — можно, но если пришлось ехать на такси — вот это уже нельзя, в оформляемой части деловой поездки этой поездки на такси не будет, а вот в деловой поездке — будет). Кто-то считает «мы продаём смартфоны» как «продаём смартфон с блоком питания», а кто-то — «продаём смартфон без блока питания». Термин «смартфон» тут будет обозначать разные системы (с блоком питания и без) с разной ценой, разным весом, разным поведением в момент зарядки.

• Слишком высокий системный уровень (отсылка «на деревню дедушке Константину Макарычу»): игнорирование ближайшей надсистемы при определении целевой системы. Хвост у стада, кирпич в доме, целевая система «лампочка» неожиданно работает не в комнате, а в «умном доме». Маскируется словами «используется везде» (отсылка к каким угодно надсистемам), или совершенно неопределённым адресом. «— Где используется ваш сверлильный станок? — В машиностроении!», «— Какие танцы вы будете принимать к постановке? — Любые!». Если видите в качестве надсистем названия отраслей, министерств, стран (это огромнейшие надсистемы, слишком крупные!) — бойтесь таких надсистем. Бойтесь слов с кванторами всеобщности и утерей специфики предметной области («любой», «каждый», «всякий», «универсальный», «многоцелевой» и т.п.). «Изготовлено в Китае», «используется в Сербии» — это очень плохие отсылки.

• Сверхобобщение (указывается какой-то надкласс вместо конкретного класса систем). Ошибка — вместо «стиральной машины» или «трансформаторной подстанции» говорить и писать «оборудование», вместо горчицы и жареной курицы говорить и писать «еда». Если вы понимаете, что сказанули (да, не «сказали», а «сказанули») термин из учебника, который относится и к системе из вашего проекта, и к тысячам других систем, которые на систему из вашего проекта ни разу не похожи — это ошибка. «Моей целевой системой является оборудование» — за такую общую фразу надо увольнять сразу, это чистая правда, но бесполезная правда, демонстрация неумения мыслить. Рассказывать об отношениях в мета-мета-модели не надо, это уже рассказано в наших руководствах. Расскажите об отношениях объектов вашего проекта, вашей предметной области! Если в вашей речи и документах не появляется терминов вашей узкой предметной области — вы просто не мыслите, не владеете операцией присвоения типа. Сказать, что «наше предприятие выпускает изделия» — это ничего не сказать!

• Релятивизм (ошибка всех тех, кто не уверен в принадлежности к какой-то команде). При релятивизме что угодно определяется «целевой системой», игнорируя наличие своей команды, своего собственного оргзвена, у которого может быть какая-то «наша система», совсем не целевая. Системное мышление в этом случае перестаёт служить целям координации коллективной/групповой деятельности. Если вы соглашаетесь, что «любая система в нашем проекте может быть целевой» — то это плохое понимание рекурсивного системного рассмотрения (по поводу любой системы можно провести системное рассуждение). Если у вас проект по созданию целевой системы, то укажите, для какой целевой системы (и это должно быть указание на работающую/функционирующую уже целевую систему, время её использования) в проекте объединяются все остальные системы! Да, целевая система — тоже система, но все остальные системы проекта — они собираются в проекте именно для её создания и развития. И надо договориться, для какой именно системы всё собрано, не удастся просто соглашаться, что «все системы важны, давайте всем подряд заниматься». Нет, заниматься надо не всем подряд, а тем, что ведёт к успешности целевой системы — одной для проекта.

• Целевая система как все самые разные виды систем всех самых разных проектов, которыми занимается агент (чаще всего — крупное предприятие, у которого много видов продукции). Это очень частая ошибка топ-менеджера, к которому попало очень много проектов. Это очень похоже на ситуацию сверхобобщения. Если к вам попал проект по изготовлению домашней электромясорубки (одна целевая система) и новогодних фейерверков (другая целевая система) просто на основании того, что какой-то собственник купил две компании, или по другим каким-то причинам, не пытайтесь изобразить их как целевую систему. Так и оставляйте их двумя разными целевыми системами! Не сваливайтесь в ошибку сверхобобщения, ибо закончится тем, что вы обзовёте якобы целевую систему «оборудованием» — и дальше всё будет плохо, потому как что хорошо из вариантов методов работы для электромясорубок, не будет хорошо для фейерверков и наоборот, за малым исключением. Выделяйте из вашего всеохватного графа создателей его части для проектов создания разных систем, честно называйте эти системы как отдельные — и потом уже обсуждайте, выгодно ли (и кому именно выгодно) иметь большую общую часть графа создателей разных целевых систем, или не очень выгодно и лучше бы избавиться от части проектов, потому как легко попасть в ситуацию jack of all trades, master of none («занимался всем, мастер ни в чём»). Всё-таки сначала надо определить, какую систему ты делаешь, а затем трезво оценить, можешь ли ты эту систему делать — или тебя просто взяли «на слабо» и поручили заведомо проигрышное дело, а ты взялся.

• Игнорирование первичности основной функции/метода работы системы. То есть система выявляется не по её основному действию в окружении (метод/функция::поведение, которым она меняет объекты своего окружения в составе надсистемы в момент эксплуатации), а по каким-то иным соображениям. Например, вы пытаетесь сказать, что какая-то группа активов::«физические предметы», принадлежащая одному собственнику — это ваша целевая система. Отношения часть-целое вроде как есть, «актив в составе группы активов», но взаимодействия в такой группе и взаимодействия с системным окружением нет, новых свойств от объединения активов в группу не появляется, то есть — не система, нет системного эффекта. Например, «информационная система предприятия» очень часто определяется именно через отношение принадлежности к предприятию, а не по основной функции этой информационной системы, и это ошибка. Сказать, что «информационная система предприятия информирует» — это ничего не сказать про её роль/функцию/назначение в надсистеме (скорее всего, этой надсистемой тут будет предприятие в целом!). Это слишком общая характеристика. Пример с собакой обычно все понимают в части соблюдения этого принципа: нужно говорить «сторожевая собака», а не «домашнее животное Василия» (отношение собственности) или «дворовой зверь» (сверхобобщение и отсутствие роли в надсистеме). Но вот метод «сторожит» (а не «красиво выглядит», как у пуделя) — это явное указание на то, что можно ожидать от собаки. Указывайте на то, что можно ожидать от системы, а не называйте любым словом. Для какой-то инфраструктурной или программной системы часто упускается эта необходимая первичность рассмотрения функциональности целевой системы, «что она умеет», протягивание мысли к эксплуатационному времени (что она умеет изменить в окружении), а не ко времени создания системы или даже выходящими за рамки времени проекта отношениям владения.

• Пропущенная система. Отдел работы с инвалидами составляет для них учебную программу, эта учебная программа передаётся в учебную часть вуза, учебная часть вуза посылает преподавателей преподавать инвалидам по спецпрограмме (ибо они часто не в силах идти по общей программе). Целевая система тут, похоже, обученная функциональная часть мозга инвалида (назовём её «мастерство»), которая будет включаться в тех ситуациях, для которых инвалида учат. Но кто учит инвалида, какая система создаёт его мастерство? Бригада преподавателей, которую посылает к инвалиду учебная часть! Вот это оргзвено и есть провайдер обучения как сервиса создания мастерства («станок», инструментарий учебной части/деканата, но можно рассматривать учебную часть/деканат как организатора/создателя для этого преподского оргзвена, это уже не так важно). Сообразить, что группа преподавателей практически неотличима от бригады программистов, которые программируют какое-то приложение — очень трудно, ибо посылаемые отдельно учебной частью преподаватели из общего пула вузовских преподавателей не воспринимаются как оргзвено. И напрасно: вы пропустили существование важного предмета обсуждения, пропустили систему. Она тут не целевая (целевая — это мастерство), но без её обсуждения нормального графа создателей не получишь.

• Флоты, пулы, агентуры, клиентуры. Ещё часто пропускают какой-нибудь «флот»::«активные транспортные средства — электровозы, тягачи» или «пул»::«пассивные системы — вагоны, тележки» как отдельную систему со множеством других систем как её части. И даже агентура как какое-то множество агентов и «клиентура» как множество всех клиентов. Взаимодействие частей такой системы тут неочевидно, но оно устроено хитрым образом — через совместную обработку, совместное описание, совместную конкуренцию за ресурсы, совместное создание (общий граф создателей). Более того, есть эмерджентные характеристики (например, для клиентуры важен её рост, этой характеристики нет у отдельных клиентов, а вот суммарное число клиентов характеризует клиентуру в целом и может интересовать рост клиентуры, скорость роста клиентуры, ускорение роста клиентуры — и создание и развитие клиентуры создаёт не только отдельных клиентов как подсистемы клиентуры, но и клиентуру в целом, которая и может быть одной из систем в проекте, хотя целевая система обычно — это то, что или приобретается клиентурой у нас как производимый нами продукт/изделие, или принадлежит клиентуре, если у нас сервис и клиентуре надо выполнить для своих предметов метода работы того метода, в котором у нас есть мастерство и инструменты). Тут очень спорный вопрос, считать ли такие «коллективные системы», как клиентура, полноценными системами системного подхода, но современное системное мышление всё ближе и ближе к так называемому «конструктивному» определению системы — и система определяется не просто как существующая в мире объектов и отношений, но как результат операций по построению такой системы из частей, а описание системы — результат операций по построению описаний агентом-создателем. И если будут новые свойства на каждом системном уровне — то всё ОК, а взаимодействие систем друг с другом рассматривается опосредовано — через агента-создателя, проводящего какие-то операции создания. Эту линию «конструктивизма» в мереологии (учения о частях и целых) проводит Kit Fine¹¹, мы расскажем об этом подходе как о современном тренде в системном подходе в последнем разделе нашего курса.

• Указание на какую-то связанную с целевой системой, вместо той, которая целевая. Например, вы говорите «заказ Уралнатрия» вместо указания системы. Потом выясняется, что заказов у Уралнатрия множество, они меняются, а систему уже сделали и перепродали Сибирькалию в совершенно другой комплектации. Хорошо бы понимать, что «заказ» — это не система, но это может быть указанием на договорённость поставщика и заказчика о сделке. А сама система — это не «заказ». Обычно всё это проявление метонимии: косноязычия людей, когда они вместо одного объекта называют другой объект, связанный какими-то часто не очень определёнными отношениями с тем объектом, который они пытаются назвать. Если вы выявили системой «заказ Уралкалия», то сколько людей поймут, что вы имеете в виду состояние вашей компании и Уралкалия, которые вошли в сделку по изготовлению чего-то неизвестного (слово «заказ» может подразумевать заказ чего угодно — свиней, башенных часов, проходческих комбайнов для солевых шахт, обучения пары тысяч сотрудников китайскому языку — заказ/сделка/договорённость), а сколько человек будут понимать, что это названа целевая система — скажем, тот же проходческий комбайн, который и будет целевой системой, и который поминается в «заказе», причём в заказе будут ещё и деньги, и сроки, и много чего ещё, но вот сама целевая система — это как раз вот этот проходческий комбайн для солевых шахт, считать «заказ» целевой системой — явная ошибка.

• … множество других ошибок, проявляющихся во множестве других ситуаций. Повторимся, что системное мышление просто определяет вам объекты внимания, но само оно не пошаговое/алгоритмичное, не даёт чёткой формулы получения результата. Вам надо догадаться, сделать гипотезу о том, что такое у вас целевая система, а вот набор понятий системного подхода дальше даст материал для критики этой гипотезы. Опровергнуть ваши идеи системное мышление может, а вот сгенерировать идеи — нет. Нет строгой последовательности действий, которые дадут «правильный» ответ. Правильных ответов вообще не бывает, бывают полезные и бесполезные (или даже вредные) ответы на вопросы системного мышления, которые системное мышление признает прошедшими его критику. Вот эти бесполезные и вредные ответы на вопросы, которые системное мышление не признаёт — это и есть ошибки. Какие вопросы? Первый же вопрос системного мышления: что у вас целевая система? На него нельзя не отвечать! И лучше бы не делать частых ошибок.

Например, возьмём сверхобобщение: указание системы так неконкретно, что её невозможно найти среди всех объектов окружающего мира. Можно считать, что называя систему, вы даёте её адрес в понятийном пространстве. Адреса составлены обычно так, чтобы разные уровни адресации позволяли чётко найти объект, объект уникален внутри какого-то уровня адресации, его легко найти — это и есть принцип почтальона (был предложен А.Нечипоренко в ходе одного из наших семинаров в Новосибирске).

Так, адрес пластиковой накладки на ножке стола по сути перечисляет объекты в системном разбиении, позволяющие перейти от внимания ко всей Вселенной к вниманию к этой пластиковой накладке:

• Вселенная,

• комплекс сверхскоплений Рыб-Кита¹²,

• Ланиакея¹³,

• сверхскопление Девы¹⁴,

• местная группа галактик¹⁵,

• Млечный Путь¹⁶,

• Рукав Ориона¹⁷,

• Солнечная система,

• планета Земля,

• Россия,

• Ростов-на-Дону,

• ул. Большая Садовая,

• дом 105,

• аудитория 323,

• первый стол от доски у окна,

• левая ножка стола,

• пластиковая накладка.

Адрес «Вселенная, Солнечная система, Дом 105, пластиковая накладка» — это неправильный адрес целевой системы, неправильное указание на целевую систему, ибо «домов 105» много, непонятно какой именно дом в Солнечной системе вы указываете, а в каждом доме множество пластиковых накладок — непонятно, какую из них вы имеете в виду.

В системном разбиении надсистема должна определяться по возможности близко по уровням отношений «часть-целое» от целевой системы, быть в ближайшем окружении. Тут возможно много разных типов ошибок, они всё те же, но повторим:

• Пропуск уровней. Обычно заявляется слишком далёкий от целевой системы системный уровень, например, вместо целевой системы называется её надсистема, или даже система на несколько системных уровней выше надсистемы. Типичный пример: я делаю автомобиль! После чего следует длинный рассказ о морозоустойчивых аккумуляторах. Почему? — Ну, меня интересуют морозоустойчивые аккумуляторы, они используются в автомобилях. — Могут ли использоваться, например, для гайковёртов? — Да, вполне. — А если гайковёрты в Якутии? Да, это много лучше автомобиля, для моих морозоустойчивых аккумуляторов это отличный рынок! Я занимаюсь гайковёртами! (после некоторых вопросов становится понятным, что и аккумулятор тоже не интересует, речь идёт о морозоустойчивом электролите — он и будет целевой системой! Проект занимается морозоустойчивым электролитом, хотят производить его, а аккумуляторы пусть производят все желающие покупатели электролита!).

• Сверхобобщение. Это в некотором роде нарушение адресации, но отношение не часть-целое, а уровня обобщения/специализации в классификаторе. Например, не «одноместный учебный самолёт», и даже не просто «самолёт», а «летательный аппарат». Что ты создаёшь? Летательный аппарат! А в реальности это игрушечный самолётик на резиновом моторчике. Ну и назови его по обычной роли «быть игрушкой»: «игрушечный самолёт». Верно ли будет «летательный аппарат»? Для математика — верно! Но у нас тут не математика, у нас системное мышление. Нам все названия и результаты размышлений нужны для работы, для создания и развития успешных систем, а не для «логической истинности». Правильный в математике или физике ответ не означает, что он правильный в системном мышлении! Для понимания, что можно сделать с создаваемой системой, имя «игрушечный самолёт» много лучше «летательного аппарата».

• Указание не всей системы, или соседней (в окружении или даже в числе создателей) системы, в надежде, что целевая система будет собеседником определена самостоятельно, умозаключением. По сути, речь идёт о метонимии¹⁸ — один физический объект (или класс таких объектов) заменяется другим (или его классом), находящимся в какой-то связи/отношении с называемой целевой системой. И вместо названия/указания одной системы появляется вдруг название этой другой системы. Связь эта может быть как «часть-целое», так и любой другой. «Я три тарелки съел» — не тарелки, а находящуюся на тарелке еду. «Ведро расплескалось» — не ведро, а вода в ведре. В случае метонимии целевой системой могут назвать что угодно, находящееся в каких-то отношениях с целевой системой: всё, что попадает в сферу внимания. Проверять метонимию нужно, отслеживая, что речь идёт именно об отношениях «часть-целое» и учитывая время рассмотрения (эксплуатация или создание), и уже дальше уточнять, какая система в итоговом системном разбиении целевая, на каком системном уровне мы с ней работаем, каким языком мы о ней говорим.

Не расстраивайтесь, если вы поначалу будете постоянно совершать все эти ошибки, даже зная, что это ошибки (обычно тут помогает наставник, который будет на разборах ситуаций вам на эти ошибки указывать: увы, знание про ошибки не убирает эти ошибки из моделей, для исправления собственных ошибок нужно внешнее «зеркало», изнутри себя ошибки обычно не видны). Профессионализация в каком-то деле — это то, что вы перестаёте делать новичковые ошибки. Конечно, вы будете делать и другие ошибки, но уже не новичковые.

Беглость и безошибочность в системном мышлении (лучше всего — мышлении моделированием, но можно и письмом, что хуже в силу меньших усилий на формализацию, ещё хуже — просто мышление рассуждением вслух, ибо у результатов мышления не будет задействована внешняя по отношению к ненадёжному мозгу память), как и беглость и безошибочность в любом другом деле (игре на музыкальных инструментах, разговоре на иностранном языке и т.д.), приобретается только путём долгих занятий, путём набора опыта работы.

В ходе работы по предусмотренному нашим руководством моделированиям и заданиям по написанию постов вы заполняете множество табличек и пишете множество текстов — и постепенно набираете какой-то опыт системного мышления. Продолжайте создавать таблички, похожие на приведённые в заданиях нашего руководства, модифицировать их, заполнять на материале ваших рабочих проектов — и скоро вы не будете понимать, почему это было поначалу так трудно. Это и есть метанойя, когда вы не можете понять, почему раньше всё казалось сложным, трудным, а сейчас вдруг вы системно мыслите — и даже не замечаете этого! Нейронные сети в биологическом мозге обучаются медленно, но всё-таки обучаются! На какое-то (не до уровня чемпионов, конечно) освоение системого мышления до хорошо заметной в работе квалификации нужно затратить на работу по нашим руководствам примерно год по паре часов в день. Это даже быстрее, чем освоение высшей математики, танцев, карате!

Повторим оценки времени: тут примерно как с походами в тренировочный зал, если вы решили вдруг заняться своей физической подготовкой. За три месяца упорных занятий результаты будут едва заметны, за год — вы разительно будете отличаться от «людей с улицы», за десять лет — можно разговаривать о чемпионстве. То же с танцами. Системное мышление не трудней спорта или танцев, но и не легче. Так что — за три месяца вы поймёте, в чём его суть, за год научитесь бегло использовать, а лет через десять будете одним из лучших в мире, если продолжите им упорно заниматься. Увы, труд наставника по системному мышлению можно автоматизировать, а труд инженера-менеджера по освоению системного мышления автоматизировать нельзя, придётся работать!

Моделирование: проверка на ошибки выявления целевой системы

Вы уже заполняли эту табличку по целевым системам от трёх рабочих проектов, в которых вы участвуете. Выполните моделирование ещё раз, но с учётом материала текущего раздела.

Именование системы

Мало выявить целевую систему, ей надо дать какое-то осмысленное имя, чтобы вас понимали быстро. Если я назвал целевую систему Муркой, то это может быть что-то живое и крупное (вряд ли таракан), и даже речь идёт о самке (кошки или человека — не так важно, но вряд ли это будет самец), при этом я буду подозревать, что это имя экземпляра, но не тип целевой системы. Но вот если я назвал систему #78F3, то мне придётся всем рассказывать — это я назвал тип или экземпляр, а также что это вообще такое: зверь, электронный гаджет, территория, или не система вообще, а только описание системы, например «документ #78F3».

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

Если речь идёт о создателе и его сервисе (методе, работы по которому создатель будет выполнять для экземпляров предметов метода, которые ему будут давать другие создатели), то именовать этот создатель свой предмет метода будет в наиболее общем виде так, как это будет делать владелец заготовки целевой системы, для которой работает заказчик сервиса. А себя этот создатель будет именовать тоже по роли сервис-провайдера. Например, вас интересует сервис маникюра¹⁹ — приведение ногтей в эстетичное состояние. Именовать вы свой сервис будете как «маникюр» (косметическая процедура, поведение провайдера маникюра», создатель «красивых ногтей» будет именовать себя как провайдер сервиса — «маникюрный салон», предмет сервиса тут — «ногти», переводимые из состояния «неухоженные» в «ухоженные», в сленге это будет или «идти на маникюр» (сеанс сервиса) или даже «идти на ногти» (именование не по сервису, а по предмету сервиса, но это всё-таки просторечное).

Так что идёт ли речь о создателе, или какой-то целевой системы — именуем по роли исполнителя функции/сервиса, которыми система меняет своё окружение (функция в надсистеме, сервис для окружения), а не конструкции (то есть не по отсылке ко времени создания, название ссылается на использование!). Указание конструкции иногда важно, но главным образом как уточнение названия по роли исполнителя функции/метода/сервиса/практики и добавляется только как указатель на какие-то архитектурные характеристики — то, что потенциальному потребителю системы (внешняя проектная роль, которая захочет использовать вашу целевую систему либо в составе своего инструментария где-то в графе создателей уже своей целевой системы, либо как подсистему в составе своей целевой системы) покажется важным, чтобы принять решение о том, что ваша система ему подходит. Но:

• Сначала система должна подойти по её роли: назначению/функции, основному методу её работы (первичное рассмотрение системы — как функционального объекта, то есть роли в надсистеме)

• И только потом — по конструкции, которая влияет на архитектурные характеристики (надёжность, ремонтопригодность, экономичность и т.д.).

Иными словами, система именуется как ролевой объект, если вы её используете. Но если вы её производите, то в производимой системе вы тоже пытаетесь предугадать её функцию в ожидаемой вами надсистеме, указать её роль (по типу), хотя иногда допускается добавление уточнений про конструкцию, чтобы в названии отразить архитектурные характеристики (они зависят от конструкции!).

Если у вас в автомобиле коробочка, которая связывает разные электронные устройства (замок зажигания, спидометр и т.д.) с интернетом (какими-то серверами в облаке), то как её назвать? По типу, причём можно в основание типа положить тип-прототип — какой-то иной, хорошо знакомый тип систем, на который ваша система как-то похожа.

В доме устройство, которое связывает разную домашнюю электронику с интернетом называется роутер/router. Отлично, для автомобиля связь автомобильной электроники с интернетом будет делать автомобильный роутер! Всё, тип (маршрутизатор пакетов данных от каких-то локальных устройств в «большой интернет») определён, и вы дальше сэкономите много-много минут объяснений того, что это у вас за целевая система. Основное назначение: маршрутизация/routing::метод «пакетов данных»::предмет метода, уточнение — что эта маршрутизация будет делаться в автомобиле. Провал проекта будет, если вы назовёте этот автомобильный роутер «автомобильной электроникой», «интернет-аппаратурой автомобиля» или чем-нибудь другим, где не просматривается явно функция: что именно там с интернетом, автомобилем, электроникой — если нет глагола, непонятно что делает, нет традиционного имени типа системы, из которого понятно назначение, если в имени суперобобщения типа «электроника» или даже «интернет». Если это «роутер/маршрутизатор, вроде того, что у вас дома соединяет домашние компьютеры и телефоны с интернетом, только для автомобильных компьютеров», то вы за две минуты будете объяснять, чем занимаетесь и команде проекта, и внешним проектным ролям. В каждом разговоре будете экономить минут так пять-десять — на протяжении всего хода проекта. Выявление и точное называние целевой системы для этого и нужно: быстро и надёжно скоординировать коллективную работу по проекту.

По основному назначению/функции/сервису, как ролевой объект именуются не только целевые системы, но и все остальные (надсистема, системы в окружении, подсистемы), т.е. именование системы оказывается именованием её как функционального объекта, роли, «чёрного ящика» заданного назначения, а не прозрачного ящика с известной конструкцией или методом работы, и это именование связывается с поведением, игрой некоторой типовой роли. Вот эта типовая роль и будет именем системы. Так что именование системы зависит от ожидаемого окружения системы. Сервис-провайдера и инструмент тоже стремятся назвать как какое-то обобщение ожидаемой роли и функции его как системы в надсистеме.

Так, микроскоп предназначен для того, чтобы быть в роли инструмента для рассматривания мелких предметов: смотреть::метод микро/мелкие объекты::«предмет метода». Если иногда им заколачивают гвозди, то это не считают его основным назначением, хотя это иногда и будет его поведением/функцией в надсистеме. Это редкое назначение, особенность некоторых вариантов использования. Поэтому микроскоп нельзя называть «микроскоп с возможностью гвоздезабивания» или «молотковый микроскоп». Нет, только по основному назначению. Но если вы берёте микроскоп в вашу систему именно как гвоздезабиватель, то так и назовите!

Название «продавца» и название «покупателя» могут различаться: ожидаемая функция системы и включение в название системы как конструктивного объекта для выпячивания возможной роли в архитектуре клиентской системе обычно делаются продавцом и выражают ожидание возможного использования. Скажем: «водонапорный насос». А вот покупается функциональный объект, и он именуется по актуальному использованию — «насос заполнителя бака третьего контура пожаротушения на пятом этаже». Если покупаете микроскоп (имя, данное производителем производителя!) как гвоздезабиватель (имя, данное потребителем по актуальному использованию!), то не удивляйтесь двум именам.

Именуется при этом класс/тип систем, а не уникальный экземпляр системы. И это очень часто ролевой объект, «исполнитель метода работы с определёнными предметами метода» (сборщик собирает предметы сборки, погрузчик грузит грузы, нарезчик нарезает), но не только. Назначение «ножниц» (что-то резать, это производное от двух «ножей») хорошо известно, так что ножницы назовут, скорее всего, ножницами — но добавят уточнения по предмету метода резания ножницами-инструментом (например, «ножницы по металлу»).

Помним, что сверхобобщение при выборе термина для типа — это большая ошибка. Микроскоп нельзя называть «оптический прибор» (так, телескоп — это тоже оптический прибор, и будет путаница), ножницы лучше бы тоже уточнить — парикмахерские, или по металлу. Уточнить/специализировать — это хорошо, обобщить/генерализовать — плохо. Если вы назвали систему «фрукт», а не «апельсин», не удивляйтесь, если будут страшно ругаться, обнаружив, что вы продали не персик. Ибо персик — это «фрукт», и покупатели будут считать, что «фрукт» исполнит любую роль в этой категории. Если не любую — будут совершенно справедливо ругаться. Так что называйте, как всегда, точно, не обобщайте. Если купили «зверя», ожидая «тигра», то не удивляйтесь, если вам продана «мышь» — тоже зверь, что просили, то и получили!

Самая частая ошибка, которую делают при именовании — это перечисление всей возможной функциональности длинным списком и ещё добавление конструкции. Вместо «автобус» это будет «система посадки, перевозки по автомобильным дорогам, оповещения об остановках и коммуникации водителя и пассажиров, высадки пассажиров и закрывания дверей в целях безопасности, усиленная галогеновыми фарами». Так нельзя: любое длинное перечисление функций в названии недопустимо. И иногда есть уже устоявшееся название, его и нужно использовать — тот же «автобус». Если это тип, то всем и так будет понятно, что делает такая система.

Другая не менее частая ошибка — это указание не на ролевой объект, т.е. на действия/функцию в надсистеме (роль, выполняющая метод: система «сварщик» для выполнения метода «сварка», система «зубодёр», если она выдирает зубы — вот так надо!), а сразу на конструкцию. Конструкция обычно относится к времени изготовления системы, «из чего и как мы эту систему делали». Вместо «ножницы по металлу» будет «система металлическая с винтиком», явная ошибка. Вместо «антистатик для пластмасс» (метод снятия электрического заряда «антистатик» и предмет метода — пластмасса) будет «система введения углеродных трубок в пластмассы» (из чего делали антистатик — из углеродных трубок, назначение трубок умолчано, ошибка раз, а вторая — говорим даже не о самих трубках, а о «системе введения», то есть инструменте-системе с сервисом «введение» для нанотрубок, то есть продаём не антистатик, а вроде как инструмент для введения какого-то непонятного субстрата «нанотрубки» в пластмассы — но зачем?!). Нет, название системы даётся по первичному/обычному/типовому назначению системы, по роли/функциональности в типовой надсистеме для такого сорта системы, какую вы именуете. И не путаем — продаём систему, сервис, инструмент для какого-то метода, что? Имя должно быть точным по типу!

Про нарушение «принципа почтальона» (прежде всего — указание слишком общего ролевого объекта, слишком общего действия/функции) мы уже не раз говорили, но повторим. «Система разрезания» вместо «ножницы по металлу» или «автотранспортное средство» вместо «автобуса», «фрукт» вместо «апельсина». Роль должна быть специфицирована точно, без лишнего обобщения. Вот прямо сейчас попробуйте придумать какую-то абсолютно другую систему, которая отлично подойдёт под имя, которое вы дали вашей целевой системе. Трудно придумывается? У вас хорошее имя! Легко придумывается? Для вашего тигра, которого назвали «зверь», вы легко придумали и мышь, и зебру? Тогда меняйте имя вашей системы на тигра (а то и амурского тигра, чтобы не путать с какими-нибудь другими тиграми).

Нельзя говорить «расчёты», нужно указывать, какие именно расчёты, что именно эти расчёты считают (не «расчёт», а «расчёт среднесрочных рисков» или «расчёт даты готовности заказа», или расчёт прочности — и не просто расчёт прочности, но с указанием предмета этого метода, например, расчёт прочности на разрыв ленты шахтного конвейера).

В названии целевой системы должна чётко угадываться предметная область из системного уровня надсистемы, никаких сверхобобщений до уровня «инженерия вообще», «IT-вообще», «менеджмент вообще».

Особенно отличаются игнорированием предметной области программисты: у них всё «расчёты», «сервисы», «базы данных» без указания на то, что они делают в прикладной предметной области (не в области программирования, а в той области, для которой они программируют!). Нет слов из предметной области, в которой работают эти «расчёты» и «сервисы» — что-то названо не так, налицо сверхобобщение, ибо какая-нибудь «система обработки рисков» может работать, судя по названию, с рисками чего угодно, но в жизни это оказывается глубоко не так: риски в ней могут быть только те, для каких она разработана, но не другие. Уточните, проведите DDD²⁰, слово «domain» (предметная область) для прикладной предметной области там не случайно!

Ещё можно указать на неоправданное использование слова «система» в названиях: «система ножниц по металлу» лучше сразу заменять на «ножницы по металлу». Проверьте, нет ли слова «система» в названии вашей целевой системы — и немедленно его исключите, назовите вместо типа мета-мета-модели («система») именем из предметной области, с которой работает эта система.

Вопросы. Именование системы

Система медленно ползёт по грядкам, берёт овощи спецзахватом, отрезает хвостики и кладёт их в ящик. Ящик запечатывается и маркируется, укладывается на тележку. Как можно было бы назвать эту систему?

--- сельскохозяйственная система ### Нет, это слишком общо —вряд ли эта система занимается всем, чем занимаются в сельском хозяйстве, явно нарушен «принцип почтальона».

--- автоматизированная фермерская система ### Нет, это слишком общо — вряд ли эта система занимается всем тем, чем занимаются фермеры, нарушен «принцип почтальона».

--- агро-робот ### Нет, это слишком общо, функциональность непонятна, в агропромышленности слишком много видов деятельности/методов, чтобы робот делал их все.

--- система сбора овощей ### Нет, хотя, это названо по основной (обычно самой дорогой и труднодостижимой, если их много — и тут это точно не отрезание хвостиков) функции. Но всё-таки можно короче: слово «система» как очень общее название типа лучше из названия исключить.

+++ сборщик овощей ### Да, это названо по основной (и обычно самой дорогой и труднодостижимой — точно не запечатывание и маркировка ящиков) функции. Название лучше, чем «система сбора овощей» — короче на одно слово.

--- система сбора, упаковки, маркировки и погрузки овощей ### Нет, перечислены все функции, а нужно назвать только основную.

--- овощепогрузчик ### Нет, это не основная самая трудная функция. Сбор овощей много трудней их погрузки.

--- овощной робот ### Нет, это слишком общо, непонятно, что делается (функция/поведение) с овощами: переработка в консервы? Нарезка? Выбраковка гнилых овощей, которые уже кем-то собраны?

Система собирает по сети данные о днях рождения людей, отождествляет их с фотографиями, печатает индивидуальные поздравительные открытки и отправляет их обычной почтой. Оплачивает всё это благотворительный фонд, идея состоит в поднятии настроения людям, что должно спасать их от всех болезней. Как фонд мог бы назвать такую целевую систему?

--- система поднятия настроения ### Нет, это указывает лишь на сервис (что система делает с людьми с точки зрения её создателей-инженеров, их лучшее приближение для функции). Хороший кандидат на название, если бы мы не знали, что называет систему фонд, а не её создатели. Для фонда это система спасения от всех болезней, название по её основной функции. И ещё в названии слово «система», от него хорошо бы избавляться.

--- система спасения от всех болезней ### Нет, хотя это основное назначение системы с точки зрения фонда: спасать людей от всех болезней. Но можно короче: от термина «система» как слишком общего типа в названии стоит избавляться

--- система спасения от болезней через улучшение настроения ### Нет, лишнее уточнение про механизм работы. И слово «система» тут лишнее.

--- социальная поздравительная система ### Нет, это только про механизм работы для достижения основного назначения/выполнения основной функции системы с точки зрения фонда — спасения от всех болезней.

--- система сбора и распространения информации ### Нет, не отражена основная функция с точки зрения фонда — делается система не для сбора и распространения информации, а для спасения людей от всех болезней. Ну, и слово «система» тут явно лишнее (можно было бы назвать «сборщик и распространитель информации», хотя это всё ещё неправильный ответ).

--- поздравитель с днём рождения ### Нет, это просто роль исполнителя стратегии, которая была выбрана в качестве метода улучшения настроения. Основное тут — не поздравление с днём рождения, а спасение людей от всех болезней. Метод можно потом в ходе развития поменять (спасать от всех болезней не через улучшение настроения), а вот предмет метода — болезни (состояние: их нет), в названии системы не отражён.

--- система печати и рассылки открыток ### Нет, это указание на довольно низкоуровневые сервисы для достижения основной функции с точки зрения фонда: спасения людей от всех болезней.

+++ спасатель от всех болезней ### Да, это роль системы, названа по роли для основной функции — спасение.

--- благотворительная открыточная система ### Нет, это никак не указывает на то, что же именно делает система, какова её роль. И ещё слово «система», от него надо бы избавиться. Обычно «система самолёт» и «система кошка» не говорят, надо прямо назвать роль.

--- благотворительная система поздравлений с днём рождения ### Нет, это указание на вариант реализации инструмента для сервиса улучшения настроения, задействованного для достижения основной функции с точки зрения фонда: спасения людей от всех болезней. И ещё слово «система» тут явно лишнее.

На поверхность детали наносится напыление из трёх слоёв, дающее повышенную износоустойчивость и коррозионную стойкость детали. Как можно было бы назвать это напыление как систему?

--- трёхслойное напыление ### Нет, пропущена основная роль, указывающая на функцию, то есть «что система делает», а не «что система такое» — повышение износоустойчивости и коррозионной стойкости.

+++ упрочняющее и антикоррозионное покрытие ### Да, именно так: покрытие (роль) упрочняет и защищает от коррозии, это основные функции данного покрытия.

--- система износоустойчивости и коррозионной стойкости ### Нет, хотя функция указана верно, но в качестве роли лучше бы выбрать что-то более конкретное, чем «система», например, «покрытие» (хотя даже конструктивный вариант «напыление» тоже будет лучше, чем общее слово «система», оно «ни о чём»).

--- трёхслойная система износоустойчивости и коррозионной стойкости ### Нет, указание на конструкцию из трёх слоёв тут лишнее.

+++ упрочняющее и антикоррозионное напыление ### Да, отличное название (можно и «покрытие», но напыление дополнительно может указывать на тонкость покрытия, что может быть архитектурно важно).

--- поверхностная наносистема ### Нет, слишком общее название — основная функция не определена, поведение/назначение неясно, да ещё и слово «система», хотя и «нано».

--- улучшающая наносистема ### Нет, слишком общее название — основная функция не определена, поведение/назначение неясно. Ещё и слово «система» очень общее.

--- защитная наносистема ### Нет, слишком общее название — тут хорошо бы указать, от чего защита. И убрать слово «система».

Надсистема: её тоже нужно выявить!

Надсистема (иногда говорят using system, «использующая система») прежде всего должна проверяться на то, что целевая система является в момент эксплуатации (operation, работы, функционирования) неотъемлемой физической частью этой системы, то есть буквально входит в состав (composition) надсистемы. Увы, большинство ошибок происходят именно по невниманию к этому её признаку.

Системное разбиение (system breakdown structure) — это иерархия по отношению состава/сборки/часть-целое, а не по каким-то другим отношениям. На ошибку выделения надсистемы и целевой системы указывают обнаружение между ними отношений вызова подпрограммы, классификации и специализации, принадлежности в части имущества, назначения на роль, создания — ведь есть огромное количество других отношений, кроме предписанного для системного разбиения отношения состава (composition, is_part_of, включения как физической части).

Например, рассмотрим мужчину и женщину. Какая у них надсистема? Да, они как-то взаимодействуют, у них есть какая-то функциональность в составе надсистемы. Какой? В студенческих аудиториях эту загадку решают минут пять, а в более взрослых аудиториях инженеров-менеджеров на это тратят пятнадцать секунд: надсистемой тут является семья (студенты часто говорят «пара», подчёркивая возможность более слабой связи), а женщина и мужчина находятся друг у друга в операционном/эксплуатационном/рабочем окружении, это и есть «в семье».

Загадки выделения надсистемы обычно решаются путём выявления пропущенной, не названной, не выявленной системы в системном разбиении — и выделенной системе надо дать имя (часто имя типа такой системы уже есть, вроде той же «семьи», но просто сразу оно почему-то неочевидно).

Если над целевой системой ещё как-то думают, то надсистемы для неё (их может быть несколько!) обычно плохо различимы, и иногда для них нет устоявшихся названий. Эти «пропущенные» системы приходится выявлять (то есть описывать их роли, функции, границы к их окружению, делая ещё один шаг «наружу» от целевой системы) и как-то называть. Как называть? Точно так же, как любую другую систему, т.е. преимущественно (если нет какого-то явно устоявшегося исторического названия) по роли этой надсистемы в её надсистеме и выполняемой этой ролью функции/методу/сервису, т.е. по роли в над-надсистеме по отношению к целевой и функции/методу/сервису с её предметами сервиса в над-над-системе. Просто рассматриваем сначала роли от границы любой системы вверх по системным уровням, а роли подсистем — потом.

Признаком того, что какая-то часть целевой системы всё-таки относится не к самой целевой системе, а к надсистеме (а команде проекта обычно приходится иметь дело с обеими этими системами) является то, что команда не уполномочена как-то самостоятельно в одностороннем порядке изменять надсистему или даже её описания/модели (концепцию использования, концепцию системы, архитектуру надсистемы). А вот целевую систему и её описания команда изменять может, вполне полномочна делать это самостоятельно!

Снова и снова мы видим, что разница между системами разной природы пролегает не по их свойствам как физических объектов, а по каким-то договорённостям людей: системы систем (SoS, определяются через разную принадлежность автономных систем, входящих в систему систем), службы (принадлежность систем по отношению создания: выполнение операций какого-то метода над чужим предметом метода), и в данном случае — полномочия по изменению конструкции целевой системы и надсистемы, тоже отношения собственности. Даже если у нас служба (server), которая что-то красит, то мы полномочны менять слой краски, но вряд ли полномочны менять ту систему, которую красим и те системы, которые потом смотрят на краску (если это художественная окраска) или воздействуют на краску (если это защитная краска от какой-нибудь агрессивной химической среды).

И тут можно отметить, что ситуация уже не такая жёсткая как ещё десяток лет назад. Раньше не предполагалось, что команда как-то может повлиять на надсистему — она брала её в проект как данное, и должна была просто стыковать свою целевую систему с имеющимся системным окружением. Сегодня это не так: команда проекта не уполномочена изменять системное окружение непосредственно, своим волевым решением. Но команда проекта может влиять на то, чтобы в целях согласования характеристик целевой и надсистемы эта надсистема была всё-таки изменена — самостоятельно её владельцами, или командой проекта по согласованию с владельцами надсистемы. Для этого команда проекта (внутренние проектные роли) активно работает с внешними проектными ролями/стейкхолдерами, влияет на них, и это происходит долго, ибо «непрерывное всё», развитие системы продолжается долго, это не «изготовили и забыли», речь может идти о многолетней совместной эволюции целевой системы и её надсистемы, смене многих версий целевой системы и надсистемы. Всё-таки целевая система — это просто подсистема надсистемы как системы, инженерно они должны быть согласованы, и иногда легче поменять что-то в надсистеме, чем в целевой системе.

При выявлении надсистемы нужно помнить, что в зарубежных текстах иногда надсистему называют «использующей системой», using system.

Это потому, что в её составе инженер использует целевую систему. Это using относится к моменту создания, а не к моменту эксплуатации. Хотя часто так говорить можно и о моменте работы/функционирования системы, речь об окружении, которое «использует», «задействует», «эксплуатирует» систему. Но «часто» — это не всегда. Так, если оговориться, что «женщина использует мужчину», то дальше можно ошибочно по чисто лингвистическому рассуждению сказать, что женщина — это использующая система. И отождествить с надсистемой. То есть мужчина получается в составе женщины (все молекулы мужчины входят в число молекул женщины), что есть нелепость. Поэтому аккуратней со значениями слова «использование», их два:

• Использование целевой системы инженером надсистемы этой целевой системы как части конструкции надсистемы в design-time. Часы::«целевая система» используются дизайнером интерьеров в «интерьере квартиры»::надсистема (окружение часов). Ни о каком «сценарии использования» тут речи быть не может, ибо тут не время использования часов, они ещё не работают, это время проектирования — для них только проектируют среду, в которой они будут работать, их размещают в этой среде. «Использование дизайнером» это совершенно не «использование в ходе эксплуатации».

• Использование кем-то или чем-то в окружении в run-time/operations (нужно дальше разбираться, что это вообще за «использование»). Часы используются жильцом квартиры, чтобы поглядеть время (и вот там речь пойдёт о сценарии использования, use case).

При определении надсистемы важно, чтобы это был ближайший системный уровень (принцип почтальона, адрес должен быть точен — нельзя отсылать в слишком общий объект). Уровень надсистемы должен быть тот, на котором ожидается эмерджентность/системный эффект от работы целевой системы в её составе. «Я делаю цветок, который улучшит мир в целом» — это влажные мечты, профнепригодность. Вам надо найти надсистему, в которой цветок изменит состояние, даст какое-то свойство, которое было бы другим, если бы цветка не было. Вряд ли мир в целом станет другим, но если это ситуация «свидания» (можно её рассмотреть как «мероприятие», как надсистему для цветка), то цветок может улучшить настроение участников свидания. Поэтому если вы делаете цветы, которые будут использованы для свидания — так и скажите. Если для похорон — это, возможно, будут бумажные цветы. Или букетик цветов с чётным числом цветов. Не ошибитесь с надсистемой, она важна!

Верный способ выявить надсистему — это разобраться, с какими агентами (прежде всего, конечно, людьми) приходится разговаривать (помним, что разговариваем в лице этих людей с исполняемыми этими людьми ролями!), чтобы проект состоялся. Они обычно и есть владельцы надсистемы. Скажем, вы делаете «систему перевозки самолётов», используемую во время ремонтов самолёта. Целевая система — отремонтированный самолёт, который опять летает, перевозя грузы и пассажиров (эти грузы и пассажиры будут в надсистеме отремонтированного летающего самолёта в момент эксплуатации). Ваша «система перевозки самолётов» (плохо, что в названии слово «система», но хотя бы так, чем никак), но что для неё надсистема?! Надсистема — авиация страны, министерство промышленности? Нет, принцип почтальона говорит, что это «правда, но бесполезная правда», с равным успехом можно говорить и о «человечестве» как надсистеме, и даже о «всей вселенной»! В данном случае довольно просто выясняется, что «системой перевозки самолётов» интересуются главным образом люди из эксплуатационной службы одного из авиапредприятий.

«Эксплуатационная служба авиапредприятия»::организация (и даже не всё авиапредприятие!) и является надсистемой для системы перевозки самолётов, а целевая система там будет — самолёт, который надо в том числе перевозить. Система перевозки самолётов тут — один из создателей для самолёта, инструмент для эксплуатационной службы, служащий для выполнения работ сервиса перевозки. У команды эксплуатационной службы авиапредприятия (внешние проектные роли по отношению к системе перевозки самолётов) есть потребности — им нужно ремонтировать самолёты, которые не летают. И поэтому у них есть какая-то концепция использования наземной системы перевозки самолётов (заведомо не летающих). Всё, с этого момента (система перевозки самолётов как часть эксплуатационной службы авиапредприятия = система как часть надсистемы) можно начинать обсуждать проект по созданию системы перевозки самолётов. Ход на выявление владельцев надсистемы обычно крайне продуктивен: всё равно с этими владельцами нужно общаться, они важнейшие внешние роли в вашем проекте.

Ещё одна ошибка, когда надсистема и целевая система называются одинаково (мы уже говорили об этой ошибке, но её повторяют снова и снова, поэтому повторим ещё раз, другими словами). Разбиения типа «А состоит из А и Б» недопустимы, может быть только «А состоит из Б и В» — и скорее всего эта ошибка не в том, что само разбиение в жизни какое-то неправильное, а просто неправильно выбраны имена для систем в нём. Например, «ячейка состоит из ячейки и прокладки». Подробное обсуждение показывает, что речь идёт о ячейке, которая состоит из корпуса и прокладки. «Жилая комната состоит из комнаты и интерьера». Подробное обсуждение показывает, что жилая комната состоит из помещения (строительной части, коробки без отделки) и интерьера (в который входят даже приклеенные к стенам помещения обои).

А ещё системное мышление состоит в том, что вы должны разобраться с устройством надсистемы, чтобы понять роль в ней целевой системы. На картинке в этом подразделе, взятом из работ Jan Dietz, это обозначено как reverse engineering для using system (а ontology — это разные описания надсистемы, получаемые путём обратной инженерии, выявления устройства надсистемы). Целевую систему вы будете получать прямой инженерией (но то, что это «прямая инженерия» обычно не говорят, говорят просто «инженерия»): описания целевой системы вы будете выявлять в части использования в надсистеме (концепция использования) и разрабатывать (концепция системы), чтобы целевая система смогла выполнить ожидаемую от неё функцию в надсистеме.

Как делать все эти описания (методы разработки концепции использования и концепции системы), разбирается подробно в руководстве по системной инженерии. В нашем руководстве по системному моделированию только указывается, что вам обязательно нужно понять роль целевой системы в надсистеме и выполняемую этой ролью функцию/метод/сервис, для этого нужно обязательно выявить надсистему и как-то разобраться в её устройстве, и зачем в этом устройстве нужна целевая система.

Если вы не разбираетесь сначала с надсистемой, не разбираетесь с вышестоящим системным уровнем, и только после этого идёте разбираться с подсистемами, то у вас не системное мышление. Ход проектного внимания от целевой системы на надсистему и разбирательство с ближним системным окружением сначала, а с частями целевой системы потом — это главное в системном мышлении.

Системный подход: для всех видов систем, не только для целевой

Системное мышление обладает свойством рекурсивности в его применении: оно похожим образом разворачивается для каждой из систем в обширных и глубоких системных разбиениях. Как-то специально выделять целевую систему среди многочисленных системных уровней какого-то системного разбиения нужно главным образом из-за необходимости помнить, что является коллективной целью, то есть для работы в каких-то командных проектах. Это новинка системного подхода в его втором поколении, деятельностное (субъективное/постпозитивистское, т.е. определяемое намерением какого-то агента что-то изменить в физическом мире) введение целевой системы/system-of-interest. Целевая система всегда выделяется из мира кем-то и для чего-то (то есть где-то используется, а не просто «существует»), это выявление целевой системы не «объективно» и «правильно/истинно».

Тем не менее, понятия системного мышления приложимы ко всем системам, не только к целевой и даже не только к «нашей». Вокруг любой системы можно выстроить иерархию по отношению композиции и построить граф создателей по отношению создания.

Так, свои надсистемы и подсистемы (над- и под- тут всегда отношения композиции, в системных разбиениях эти приставки не используются для указания вида и рода, вариантов) есть и у целевой системы, и у надсистемы, и у подсистем, и у любых других систем окружения и даже систем создания в их обширных графах. Различать описания (ментальный объект) и системную документацию (носитель с описанием), равно как отличать описание системы от воплощения системы нужно для всех систем. Все системы прежде всего называют по их первичному назначению/роли в окружении и выполняемой функции/методу/сервису, очень редко обращаясь к конструкции. Во всех системах подсистемы взаимодействуют, чтобы они проявили эмерджентность/системный эффект, хотя в некоторых системах это взаимодействие устроено хитро — оно происходит через системы-создатели, наблюдающие эмерджентные свойства таких систем, например, клиентура как система взаимодействует с создателем продукта — и такие её характеристики, как ёмкость рынка, относятся ко всей клиентуре, а не к отдельным клиентам.

Систем какого-то вида может быть в проекте много, необязательно одна. Например, надсистем у одной целевой системы может быть много. Целевая система вполне может входить в состав множества надсистем, у которых может быть у каждой своя группа внешних проектных ролей, занятых своими проектами, озабоченных своими разными потребностями для каждой из многочисленных надсистем. И систем создания у одной целевой системы также может быть множество.

Скажем, одна компания проектирует здание, другая его строит, третья эксплуатирует, и эта же третья сносит, четвёртая строит заново, «восстанавливает исторический облик» — каждая компания будет отдельной системой в общем проекте создания и развития здания. Есть эмерджентность/системный эффект, возникающий от того, что все эти компании работают в каком-то смысле совместно (и часто эта совместность оговаривается в договорах между этими компаниями), и можно сказать, что всё это не отдельные системы создания, а подсистемы одной системы создания. Но так говорить — это совсем необязательно, так обычно не делают. Мы говорим чаще всего о множестве создателей в графе создателей, а не об одном создателе, внутри которого рассматриваем граф уже из подсистем этой объемлющей единственной системы создания, да ещё там эти подсистемы не просто совместно работают, а друг друга создают.

И мы рассматриваем обычно именно графы создателей, а не просто линейные последовательности-цепочки создателей, связанных отношением создания. Один создатель может создать и развивать несколько разных систем, в том числе несколько разных создателей, а одну систему, в том числе создателя, могут создавать несколько разных её создателей, предоставляющих для этого разные свои сервисы.

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

Напомним тут и частую ошибку менеджеров: попытка выделить типовую целевую систему, которой они занимаются в самых разных непохожих друг на друга проектах. При этом возникают серьёзные осложнения: поскольку надсистемы оказываются у этих систем совсем разные, невозможно обобщить разные потребности самых разных внешних проектных ролей самых разных проектов создания самых разных систем так, как будто это всё внешние проектные роли с их набором потребностей для одной сверхобобщённой целевой системы. Нет, проекты для разных видов целевых систем, которые будут использоваться в разном окружении и работать там, предоставляя разные сервисы/функции/методы для этого окружения, нужно разделять, не пытаться их искусственно объединить в мышлении. Если нет эмерджентности от объединения (новые свойства в момент использования! А не в момент создания), то и не надо объединять какие-то части в искусственно создаваемую «систему».

Если менеджеру разными путями попало десять проектов, то не нужно делать вид, что это один большой проект и есть системный эффект от объединения этих десяти проектов в один, этих десяти целевых систем в одну: мы уже говорили тут много раз, что отношения владения/собственности, отношения влияния и распоряжения ресурсами — это не отношения композиции/«часть-целое».

Наличие нескольких разных системных разбиений (как минимум, наличие в рассмотрении для якобы одной целевой системы различных надсистем с их различными внешними проектными ролями) в рассмотрении должно настораживать: скорее всего, речь идёт не об одном проекте, а о нескольких — и вы просто должны понимать, что в жизни одновременно проходит множество проектов, и эти проекты как-то влияют друг на друга.

Речь не идёт о том, что вы находите системные разбиения разные по их виду: функциональное, конструктивное, размещения, по источникам финансирования и т.д. Речь идёт о том, что получается несколько вариантов разных функциональных или конструктивных разбиений, одного типа — и трудно их объединить в одно (хотя, конечно, все эти разбиения входят в разбиение «надсистемы всех надсистем», Вселенной, но нас волнует как всегда не теоретическое/формальное объединение, а объединение для удобства задействования каких-то методов работы, практическое/деятельностное объединение).

Скажем, вы занимаетесь покраской сепулек и монтажом фенечек. Не пытайтесь объединить эти проекты, определить «сепуле-фенечковую систему». Вам придётся отдельно заниматься покраской сепулек, разбираться с их надсистемами, иметь для этого каких-то специалистов-маляров (или красильщиков, специфика сепулек в этом плане важна!) в нужных для покраски целевых сепулек создателях/оргзвеньях/предприятиях, иметь в этих создателях как провайдерах покраски сепулек ещё и инструменты покраски. И отдельно надо будет заниматься фенечками и их монтажом, разбираться с их надсистемами, иметь отдельный проект с отдельными специалистами-монтажниками фенечек, отдельными инструментами монтажа. Если у этих проектов один начальник, или даже ими занимается одна и та же команда, системы в этих проектах будут разные, ничего хорошего от объединения этих проектов в мышлении (путём выдумывания сепуле-фенечковой системы) не будет.

Не смешивайте эти системы, не смешивайте эти проекты. Работайте с ними отдельно. Скорее всего в этих проектах будут совсем разные ситуации, они потребуют разных инженерных, менеджерских, творческих решений, разного моделирования, взаимодействия с разными внешними проектными ролями. Каждый раз, когда происходит обобщение или объединение проектов и систем, нужно задавать вопрос: какие вопросы станет легче решать при этом обобщении или объединении? Вполне возможно, что никакие — и лучше разворачивать системное мышление индивидуально в разных проектах, не пытаться из них сделать «суперпроект».

Итого: чтобы найти свою целевую систему среди чужих в системном разбиении нужно задаваться вопросами не только про неё, но и ответить на множество сопутствующих вопросов. Вопросы для себя, любимого:

• Что лично твоя целевая система?

• Что целевая система твоего клиента?

• Что целевая система твоей команды?

• Что ты можешь изменить своим решением, а на что только влияешь?

• Что может изменить своим решением твой клиент (там разные подроли! И у них могут быть разные мнения по поводу решения!), а на что только влиять?

• Какую систему ты называешь целевой для себя, когда думаешь? Твой клиент? Твоя команда?

Вопросы для себя, как члена команды:

• Когда вы (кто входит в состав этого «вы»? где границы этого «вы», определяющие кто и что там снаружи, а кто и что внутри?) общаетесь совместно с клиентом, командой, какую систему ты будешь называть целевой — свою собственную, или клиента, или команды? Помним при этом поговорку театралов: «как было на репетиции, так будет и на спектакле». Лучше бы в разных разговорах вы одни и те же системы называли одинаково.

• Команда чья — твоя, или твоего клиента? Команда твоя внутри компании «против всех и клиента», или вся компания как команда «против клиента», и нет твоей «команды против компании»?

• Когда в проекте разные люди говорят «мы» — кто входит в состав этого «мы»? Кто в этом «мы» окончательно определяет (не имеет полномочия утверждать чей-то выбор, а реально сам думает и определяет!) выбор целевой системы, определяет её границы с окружением? Кто озабочен надсистемой, то есть чьи потребности удовлетворяем?

Предписанных ответов тут нет, алгоритмов мышления на эти темы нет, но системное мышление предлагает задуматься над ответами на эти вопросы и как-то определиться. Это вопросы второго поколения системного мышления: важны не только отношения часть-целое в системном разбиении, в котором находится целевая система, но и системы-создатели, о них обязательно надо думать.

При этом обязательно нужно много общаться (системное мышление — коллективное мышление!) а также действовать, работать в проекте, принимать инженерные решения, а не только «понимать» как «наблюдатель/аналитик», не «просто думать». Надо провести какие-то переговоры с самыми разными внешними и внутренними проектными ролями, с членами команды и внешними людьми, каждый из которых может иметь какой-то особенный интерес, надо провести действия, которые ведут к достижению договорённостей по этим интересам, а также надо поменять ситуацию так, чтобы система стала успешной — эти интересы удовлетворились. Системное мышление — про договорённости (и, конечно, последующее их исполнение, воплощение в жизнь). Вам нужно достичь договорённостей в проекте, а системное мышление подсказывает, по каким вопросам важно эти договорённости достичь. Первая из них — это договориться о целевой системе, определить её границы, её роль и функции/сервисы в надсистеме.

Только после рассмотрения организационной ситуации вы можете принять решение: что считать целевой системой, а что считать вашей системой (необязательно эти системы совпадут!).

Последнее дело тут представлять себя «объективным» системным мыслителем на белом коне «над схваткой». Нет, вы должны чётко отдавать себе отчёт — какая ваша собственная проектная роль, или набор проектных ролей, насколько профессионально можете сыграть вашу роль, насколько велика вероятность, что вы сделаете в этой роли новичковые ошибки, насколько плохо сработаете из-за отсутствия мастерства и/или инструментария для используемых вами методов работы в проекте (не надо говорить, что вы не используете никаких методов! Если работаете, то используете — другое дело, что не задумывались, какие это методы, не думали, как их поменять).

Системное мышление тут поможет, но оно не содержит «объективных ответов». Системное мышление поможет только в том, что позволит больше времени провести в размышлениях о важном, не даст об этом важном забыть: оно поможет в управлении вниманием в большом проекте. И это, возможно (но не гарантированно!), убережёт от ошибок в сложных ситуациях, не даст увязнуть в неважных мелочах, поможет объединить труд в условиях глубокого разделения труда по самым разным проектным ролям, раскиданным по самым разным исполнителям этих ролей.

В мышлении вы должны чуть ли не буквально следовать системной мантре. Мы не будем тут её повторять, мы надеемся, что вы её сейчас уже сами сможете воспроизвести по памяти.

Вопросы. Системы создания

Программист Петя не может работать без ВКонтакте. Если он не напишет трех постов за день, у него наступает синдром абстиненции. ВКонтакте является:

--- Целевой системой программиста Пети ### Нет, Петя, как видно из задачи, не разрабатывает софт самого ВКонтакте — у него какая-то другая целевая система, над которой он работает.

--- Системой создания Пети как программиста ### Нет, ВКонтакте не разрабатывает Петю, не готовит его как программиста.

+++ Системой в окружении Пети ### Да, Петя взаимодействует с находящимся в его окружении ВКонтакте в тот момент, когда Петя работает. ВКонтакте тут как заправочная станция для автомобиля: находится в окружении автомобиля, автомобиль с ней взаимодействует, она не часть автомобиля, но автомобиль без этого взаимодействия не работает. И тут Петя не программист, а просто Петя.

--- Надсистемой программиста Пети ### Нет, Петя не часть ВКонтакте.

Программист Петя работает над новой компьютерной игрой. Каждую неделю он пишет отчёт о ходе своих работ и подаёт заполненную ведомость затраченного им времени (таймшит) руководителю проекта Васе.

--- Отчёт документирует целевую систему, таймшит документирует систему создания ### Нет, отчёт написан тоже о работе, а не о самой игре. Так что отчёт документирует систему создания, как и таймшит.

--- Отчёт документирует систему создания, таймшит документирует целевую систему ### Нет, таймшит — это тоже о работе по созданию игры, а не о самой игре. Так что таймшит документирует систему создания, как и отчёт.

+++ Отчёт и таймшит документируют систему создания ### Да, и то, и другое — о работе, то есть о поведении программиста Пети как системы создания и развития новой компьютерной игры как целевой системы, которую пишет Петя.

--- Ни один из этих ответов не верен ### Нет, правильный ответ в списке есть: и отчёт, и таймшит документируют систему создания.

Руководитель проекта Вася работает над компьютерной игрой. Каждую неделю он пишет отчёт о ходе работ команды и посылает заполненную ведомость затраченного командой времени (таймшит) заказчику Гене.

--- Отчёт документирует целевую систему, таймшит документирует систему создания ### Нет, отчёт написан тоже о работе по созданию игры, а не о самой создаваемой игре. То есть отчёт документирует систему создания, как и таймшит.

--- Отчёт документирует систему создания, таймшит документирует целевую систему ### Нет, таймшит — это тоже о работе по созданию игры, а не о самой игре. Так что таймшит документирует систему создания, как и отчёт.

+++ Отчёт и таймшит документируют систему создания ### Да, и то, и другое — о работе по созданию целевой системы (компьютерной игры), то есть о создателе.

--- Ни один из этих ответов не верен ### Нет, правильный ответ в списке есть: отчёт и таймшит документируют создателя (они оба про работу по созданию системы, а не эксплуатации).

Застройщик сдал жилищный комплекс «Угорские триалы» без отделки и без разведённых по квартирам инженерных коммуникаций. Покупатель квартиры Иванов нанял бригаду отделочников, которые живут в квартире и делают ремонт. Семья Ивановых по отношению к квартире является:

+++ Создатель ### Да, ибо в момент создания квартиры они организуют бригаду отделочников. Иванов-наниматель-бригады определённо причастен к доделке квартиры (это неважно, что в другой своей роли он потом там будет жить).

--- Надсистема ### Нет, квартира не часть семьи (но часть домохозяйства как системы, состоящей из семьи, квартиры, интерьера и домашней утвари).

+++ Система в окружении ### Да, ибо в момент эксплуатации квартиры семья Ивановых и квартира будут входить в одну надсистему — «домохозяйство».

Застройщик сдал жилищный комплекс «Угорские триалы» без отделки и без разведённых по квартирам инженерных коммуникаций. Покупатель квартиры Иванов нанял бригаду отделочников, которые живут в квартире и делают ремонт. Бригада по отношению к квартире является:

+++ Создателем ### Да, раз бригада-как-ремонтник создаёт квартиру, ведёт её жизненный цикл. Тут два проекта, создания и проживания. Бригада-как-ремонтник в проекте создания квартиры.

--- Надсистемой ### Нет, квартира не часть бригады.

+++ Операционным окружением ### Да, пока бригада-как-жилец живёт в квартире и ведёт в ней хозяйство — то есть пока квартира эксплуатируется, а бригада взаимодействует с квартирой в ходе эксплуатации (operations). Это для Ивановых квартира не готова и не эксплуатируется. Для бригады-как-жильца квартира вполне готова и эксплуатируется как жильё. Тут просто два разных проекта: создания и проживания. Бригада-как-жилец тут в проекте проживания в квартире.

Застройщик сдал жилищный комплекс «Угорские триалы» без отделки и без разведённых по квартирам инженерных коммуникаций. Покупатель квартиры Иванов нанял бригаду отделочников, которые живут в квартире и делают ремонт. Ребёнок семьи Ивановых по отношению к квартире является:

--- Надсистемой ### Нет, квартира не часть ребёнка.

+++ Исполнителем проектной роли ### Да, ребёнок — это вполне определённая роль со вполне определёнными интересами (например, обычно ему нужна в квартире отдельная «детская» комната).

--- Надсистемой или исполнителем проектной роли, в зависимости от возраста ребёнка ### Нет, квартира не может быть частью ребёнка, независимо от возраста.

--- Надсистемой или исполнителем проектной роли, в зависимости от отношения к детям в семье покупателя ### Нет, квартира не может быть частью ребёнка, независимо от отношения к детям в семье покупателя.

+++ Системой в окружении ### Да, в ходе эксплуатации квартиры в составе домохозяйства квартира взаимодействует с ребёнком.

--- Ни один из этих ответов не верен ### Нет, правильные ответы в списке есть — ребёнок одновременно рассматривается как проектная роль и как система в окружении квартиры.

Задания: вы — сервис-провайдер

Поставьте отметки о выполнении:

1. Написан пост, в котором вами изложена системная мантра, конкретизировав все типы мета-мета-модели в этой мантре типами из вашего рабочего проекта. Вы проверили по тексту изложения системной мантры в одном из мест нашего руководства, что ничего в этой мантре не пропустили.

2. Написан пост по итогам прохождения материала и занятий моделированием в текущем разделе руководства. В посте отражено, что вы изменили в своей работе после принятия наставлений раздела всерьёз.

3. Написан пост про себя как сервис-провайдера. В посте перечислено, какие сервисы вы предоставляете окружающему вас миру, каковы предметы этих сервисов.

4. Написан пост о том, как далеко вы находитесь от целевой системы в вашем проекте в графе создателей, насколько трудно сохранять нацеленность вашего проекта на успех целевой системы. В каждом переходе по отношению создания («создатель-1 создаёт и/или развивает создателя-2») в графе создателей от целевой системы и по отношениям часть-целое в системном разбиении есть соблазн забыть, для чего существует весь этот граф создателей и все эти подсистемы. Опрошены ваши коллеги по проекту про их понимание ситуации, их нацеленность на успех целевой системы, на рост выпуска, к материалу поста добавлено их мнение.

5. Имена систем, которыми вы заняты в вашем рабочем проекте (как минимум, те имена, которые зависят именно от вас), поправлены во всех документах. Написан пост, как вам это помогло в коммуникации с другими участниками вашего рабочего проекта.