Целевая система зависит от того, кто её ищет
Обычное дело, когда на каком-нибудь заводе топ-менеджеры признают, что 50% сотрудников не знают, что выпускает предприятие — у них перед глазами только какие-то части каких-то систем времени создания, а вот что там из этого становится инструментами создания целевой системы, а что — самой целевой системой, за какие характеристики целевой системы платятся деньги, как связана их работа с этими деньгами, как вообще выглядит целевая система в момент эксплуатации — это неведомо. Это плохо, ибо это означает, что многие люди принимают неоптимальные решения: они буквально не знают, что надо сделать, чтобы целевые системы становились лучше. Надо сделать вес детали поменьше, или прочность повыше, или цену поменьше, или класс обработки поточнее при заданном бюджете — что важнее? Это зависит от того, куда эту деталь планируется поставить. А если ты не знаешь? Решение будет «какое-нибудь», и так будут приниматься «как-нибудь» сотни и тысячи решений. По поводу целевой системы обязательно надо договориться.
Вы менеджер системы создания, хотите поднять производительность труда, поднять скорость выпуска продукта. Если это сервис, то там тоже надо поднимать скорость выпуска продукта, но продукт этот «на давальческом сырье» — вы просто меняете состояние не вашего материала, а материала чьей-то чужой системы. Но это и будет целевая система: то, что вы изменяете вашим проектом в целом, вашим мастерством и инструментарием на выходе большого графа создателей. Проект определится масштабом коллективных договорённостей в вашей организации. Так как определить скорость выпуска продукта, нельзя же её поднимать, не зная, что это? Выпуск — это количество экземпляров целевых систем, которые изготавливает проект системы-создателя (то есть количество экземпляров готовых систем на выходе всего графа создателей целевой системы). Скорость выпуска — это выпуск за небольшую единицу времени. Скорость — это название первой производной по времени от какой-то величины, а производные определяются по отношению к «дельтам» как малым величинам. Так что следим, чтобы это не было «систем в год», цельтесь в минимальную единицу измерения — секунды, дни, но не месяцы и годы, ибо вы слишком поздно будете знать ваши результаты, чтобы что-то менять как операционный менеджер.
Если неизвестно, что такое «целевая система» (класс/тип продукта/изделия**)** и сколько вы их выпускаете за период времени**—** неизвестна скорость выпуска. Если скорость выпуска (проход/throughput, но нас волнует не денежное выражение, а натуральное выражение) неизвестна, то нельзя сказать, как какое-то организационное изменение, которое вы затеяли, на неё влияет. Надо договориться, что же является целевой системой, все расчёты выпуска дальше вести для неё, а не для какой-то другой системы.
Первое, что должно интересовать менеджера — это целевая система, а не граф её создателей, за который менеджер формально ответственен. Менеджера не должно сначала интересовать предприятие::создатель::система. Ибо если не знаешь, что должен создавать, то никакое решение по поводу создателя не будет осмысленным. Сначала «что надо создать» — потом думаем о том, «каким методом будем создавать», потом «кто будет создавать, умеет ли он такое делать».
Надо ли нам увеличить число сварщиков, чтобы ускорить выпуск продукции? Ответ на этот вопрос будет понятным, только если мы пробежимся по системной мантре:
- Что делает целевая система в системном окружении.
- Из чего её надо делать, чтобы она могла это делать.
- Каким методом надо систему делать, нужны ли там вообще роли сварщиков для этих методов.
- Какой там граф создателей, который будет создавать и развивать систему, какими методами мы будем делать создателей. Какие границы «мы» в исходном вопросе? Где «мы» на этом графе? Нужны ли там роли сварщиков для создания и развития систем в графе создателей?
- И только тут можно будет прикинуть, надо ли увеличивать число сварщиков по методу критической цепи[1] или какому-то другому методу принятия решений в операционном менеджменте.
Это очень тонкий момент: вам надо не целевую систему строить такую, какую может сделать ваша организация, а организацию (создателя) делать такого, какой сможет выпустить целевую систему. А целевая система должна быть такой, чтобы она была успешной. Если вы плохой повар и будете печь пирожки уж как сумеете (но шикарно организуете предприятие, будете печь плохие пирожки быстро и дёшево), то заниматься вы будете этим только пока деньги инвестора не кончатся. Вам придётся-таки разобраться с целевой системой:
- Какие пирожки должны быть, чтобы они были кому-то нужны (сегодня говорят ещё жёстче — не «кому-то нужны», а «снимали чью-то боль», то есть очень и очень нужны, а не просто «могли бы пригодиться»).
- Какое мастерство и какие инструменты должны у вас быть, чтобы выпускать хорошие пирожки.
- И только после этого можно заняться предприятием, до этого момента надо разбираться с пирожками.
- И пока вы будете заниматься предприятием, надо не забывать заниматься пирожками: они могут успеть перестать быть нужными или может оказаться, что нужны немножко другие пирожки, для которых нужно будет перестроить граф создателей (вместо пирожков с вишней начать выпускать пирожки с мясом — и там всё по линии приготовления начинки в графе создателей придётся переделывать).
Это крайне важно: в мышлении целевая система должна быть сначала, а предприятие-создатель (и даже весь граф создателей) потом. Менеджер, который объявляет целевой системой свою организацию**—** ошибается, ибо он теряет возможность договорить всех в рамках всего проекта**, в рамках всего графа создателей.** Как минимум, он может не договориться с клиентами, мнение клиентов по поводу его восхитительного предприятия будет негативным, поскольку клиентов волнует целевая система и не волнует предприятие. Поэтому лучше бы целевая система у менеджера и клиентов была одной и той же. Ещё ведь есть и инженеры-технари (они будут называться по-разному: садовники, учителя, конструкторы радиоэлектроники), но и с ними у менеджера хорошо бы, чтобы была общая цель. У менеджера булочной целевая система — булочки, а не булочная! А булочная? Она у менеджера — создатель целевой, её создадим и будем развивать как одну из систем в графе создателей. Но сначала — определимся, булочки там или бульдозеры. И договорим всех, что булочки, а не бульдозеры. Договорим всех — это сильнее, чем «договоримся со всеми», ибо если вы договоритесь с A и B, и они потом передоговорятся между собой, то ваша договорённость с ними нарушится. Если вы договорите не только себя с A и B, но и их между собой, то и ваши договорённости будут стабильней. По поводу целевой системы надо договорить всех в проекте, чтобы не было того, что половина людей в графе создания делает булочки, а вторая половина — бульдозеры, а информационные системы (включая AI) там поддерживают создание вертолётов (поэтому бульдозеры ещё хоть как-то получаются, а булочки — никак, и мало вообще понятно, что происходит и почему). Спросите, что именно (вот буквально: комплектация, характеристики, состояние в ходе работы) выпускает и с какой скоростью ваш проект — вы будете удивлены разнообразием ответа. Но каждый отвечающий будет уверен, что все остальные прекрасно понимают, что там за целевая система и какая скорость её выпуска! При этом понимаю, конечно, ровно так же, как они сами. Ваша задача — заранее знать, что понимание у всех разное, а дальше договорить всех по поводу этой целевой системы.
Целевая система определяется субъективно, «система в глазах смотрящего», поэтому вопрос определения «системы, которую вы хотите сделать» начинается с внимания к тому, кто такие «вы»: сколько вас, какие у вас интересы. Системное мышление — это мышление коллективной/групповой деятельности, с его помощью большие команды договариваются в проектах с целевыми системами на миллионы индивидуальных деталей каждый экземпляр, с сотнями и тысячами предприятий в графе создателей таких огромных систем. В разделении труда задание общей для проекта целевой системы важно, чтобы удержать внимание разных агентов в самых разных ролях на их общем важном (целевой системе!), чтобы без потери этого внимания к системному целому позволить заботиться о деталях подсистем отдельным членам каждой команды.
Что делать, если вы директор по развитию огромного холдинга, в котором сотня проектов по созданию и развитию сотни разных видов целевых систем, обширнейшая номенклатура продуктов и сервисов? Для начала надо понять, что разобраться разом со всеми этими целевыми системами не получится. Надо будет всё равно разбираться с каждой системой, не переобобщая. Иначе у вас получится какое-нибудь «оборудование» или «мастерство» — и невозможно будет осмысленно на этом уровне общности обсуждать хоть что-нибудь. Для начала надо разобраться с каждой целевой системой в каждом проекте, и только потом поглядеть на их общую систему-создателя, из частей которой будут составлены организации-создатели каждой из целевых систем — и обсудить, насколько общи получаются в своих частях графы создателей, насколько конкурируют за ресурсы проекты создания и развития отдельных целевых систем (и ещё проекты создания и развития систем из графа создателей, они ведь тоже берут ресурсы!).
Всё равно надо начинать с целевых систем, только не обобщая: брать проекты по одному. А если махнуть рукой и делать «просто холдинг»? Не получится! Если не знать, чем именно занимается холдинг, какая его стратегия (какими методами мы будем учить холдинг работать, какие целевые системы будут успешными, если действовать этими методами) — ничего не получится, кроме дикой путаницы и разбазаривания ресурсов на недоделанные проекты. Не надо лениться, надо разбираться с отдельными целевыми системами отдельных проектов, хотя и в этом деле можно задействовать разделение труда.
Д****ля выявления целевой системы нет строгих правил, алгоритма, последовательности мыслительных шагов, порядка опроса каких-то людей, типологии случаев/cases (это предпринимательская/творческая/исследовательская задача! Нет алгоритма предпринимательства/творчества/исследования, есть только порождение догадок и отвод их критикой!). Так или иначе в решении по поводу выбора целевой системы будут участвовать самые разные агенты в самых разных ролях, пытающиеся удовлетворить самые разные интересы самыми разными методами работы, причём речь идёт не только о членах команды создателей целевой системы, но и о внешних ролях. Если у вас проект, который вы можете сделать в одиночку, то вам не потребуется развёрнутого системного мышления, хватит его обрывков. Но если проект сложный и работает группа, то в принятии решений заведомо будет сложный переговорный процесс и о целевой системе придётся договариваться по ходу дела.
Обычно целевую систему нельзя определить, сидя на своём рабочем месте и размышляя: требуется не только читать самые разные документы и хорошо знать свою предметную область, но встречаться и разговаривать со многими людьми**, а иногда и делать эксперименты, в том числе реализовывать макеты, прототипы****.**Иногда даже говорят, что пока не вылез из рабочего кресла и не пошёл общаться с разными агентами, системного мышления не происходит — ты ничего не будешь знать про целевую систему, ничего не будешь знать о том, по поводу чего все договорились, и договорились ли.
Не нужно путать:
- «нашу систему» (MySystem, OurSystem, engineered system «мою» личную, или «нашей маленькой команды») и
- целевую систему, которая общая для многих команд, и по поводу которой эти команды договариваются.
Без целевой системы нельзя разобраться и с «нашей системой»: для неё прежде всего должно быть понятно, где она находится: в подсистемах ли какого-то уровня целевой, в надсистемах целевой, в системах графа создателей. Если не разобраться, каким образом наша система даёт вклад в создание целевой системы — наша система не будет успешной, вы не сможете объяснить, почему команда-создатель вашей системы имеет какие-то вопросы к другим командам, создающим какие-то другие системы. А если есть целевая система — с кем бы вы ни разговаривали в проекте, вы члены одной команды создателей!
Да, если сделать «нашу систему» удовлетворяющей именно нашим командным интересам (или даже интересам непосредственного заказчика нашей системы — внешней проектной роли нашего подпроекта создания целевой системы) — мы будем счастливы, наши интересы учтены, и даже интересы заказчика нашей системы учтены, но успех всего проекта создания целевой системы в целом определяется главным образом успехом для внешних ролей проекта целевой системы, а не успехом для ролей нашей маленькой команды и даже внешних ролей нашей маленькой команды!
«Нашу систему» мы, конечно, сделаем, и потребуем оплаты за наш труд. Но деньги обычно платят за целевую систему: нет связи нашей системы с целевой — не будет денег за работу, проект нашей системы можно сразу не делать, а если мы ухитрились как-то договориться об оплате, то эту оплату найдут способ не сделать: если наша система никак не помогает создавать и развивать целевую систему, то как вообще можно за неё платить из денег общего проекта?
Похожее рассуждение будет и в тех случаях, когда речь идёт не об оплате деньгами, а преследовании каких-то других целей. Например, если делаешь какой-то политический проект и выполняешь в нём какую-то небольшую часть, инвестируя собственный трудовой ресурс и ожидая от реализации нашей системы и в конечном итоге целевой системы неденежных результатов.
Ка****ждый проект уникален своей целевой системой и методами её создания. Уникален не только вид целевой системы, уникальны и с****оздатели в их графе, уникальны методы работы создателей и степень мастерства создателей в этих методах. Каждая ситуация в работе по каким-то методам с каким-то типом систем уникальна, так что ничего нельзя будет запомнить и применить потом в том виде, в котором запомнили — в одну реку нельзя войти дважды, одну и ту же систему нельзя сделать дважды одинаковым способом.
Даже если вы (как команда!) подряд второй раз делаете что-то очень похожее, то у вас по сравнению с первым разом появляется опыт, вы лучше знаете риски, чем это было в первый раз**, имеете больше информации****—** и вы уже на основании этого опыта может****е принять совсем другие решения**, по-другому организовать работу****, не повторить тех ошибок, которые были допущены в первый раз****.** Создание системы может****задействовать какие-то одни методы работы, но развитие системы может подразумевать замену методов работы**.** Скажем, первый раз вы забивали гвозди микроскопом, но вот второй раз вы это вряд ли уже будете делать — вы учтёте неудачный опыт первого раза.
«Запомните метод, как мы это делали и всегда так делайте» — это не про системное мышление, системное мышление привлекает внимание к важным в мышлении объектам, но самого мышления не отменяет, и прежде всего мышления о системах в их окружении, а затем методах работы по созданию этих систем. Доставать голову из кармана и думать придётся в каждом проекте, для каждого создаваемого инкремента функциональности системы при развитии системы: системное мышление помогает ставить вопросы, но искать на них ответы, беседовать с самыми разными людьми, принимать решения после этих бесед всё равно придётся. Системное мышление даёт типы объектов для вашего мышления, но оно не мыслит за вас: что делать дальше с этими объектами — это всё одно остаётся вашему прикладному мастерству и вашему фундаментальному мастерству мышления (интеллекту, это его вопрос: что делать, когда неизвестно, что делать — каким методом работать, когда метод неизвестен).
И ещё раз напомним, что рассуждения по поводу достижения коллективных договорённостей по поводу целевой системы, «выявления системы» (как и все остальные рассуждения по проектированию системы) обычно делаются «в классах/типах», с типами систем, а не с индивидуальными системами-экземплярами/индивидами. Да, вы работаете в уникальной ситуации, но как бы ни были уникальны проекты и системы, всё равно делается попытка максимум знания перетаскивать из проекта в проект, накапливать знание, повторно использовать знания, акцентировать работу с паттернами, а не с индивидами. Даже если вы делаете что-то типа Эйфелевой башни, всё равно работать вы будете с типами, индивиды появятся только при изготовлении и сборке конструктивов разных системных уровней целевой системы.
Все системы в глазах самых разных смотрящих, так что потребуется
- самому делать догадки по поводу целевой системы (придумывать эти догадки самостоятельно, или беседовать с разными людьми, если вы недавно пришли в уже давно ведущийся проект). Это вы «выявите целевую систему» для себя самого, но это ещё не значит, что эта целевая система стала целевой системой всего проекта. Поэтому
- дальше вам надо договориться с командой и внешними проектными ролями про целевую систему (а если вы организатор проекта, то не договориться с ними, а договорить их всех между собой — и заодно с вами), и про надсистему с системами в ближнем и дальнем окружении. Это будет рассмотрение целевой системы как «чёрного ящика», создание концепции использования.
- И только после этого обсудить подсистемы (целевая система как «прозрачный ящик», функциональная декомпозиция) и из чего их делать (концепция системы — какими конструктивами-аффордансами будете воплощать подсистемы).
- обсудить методы создания целевой системы, то есть способы изготовления, сборки, испытаний, пуска в эксплуатацию целевой системы, общий метод создания и развития (систему надо будет не только создать как MVP, но и развивать, выпускать много версий, может быть даже выпускать каждую версию мелкой серией или даже налаживать крупносерийное производство).
- И только после того, как методы создания целевой системы стали известны, можно обсудить, какие роли нужны для поддержки этих методов создания,
- и дальше уже обсуждать самые разные системы создания (включая команду как одну из систем создания!) по всему их графу, учитывая мастерство этих создателей в необходимых методах работы, а также наличие инструментария для этих методов,
- и ещё помнить при этом про «нашу систему» во всём множестве этих систем проекта.
Конечно, это мы опять в краткой форме изложили мантру системного мышления. Нужно только ровно так и рассуждать, во всех проектах, это и есть норма системного мышления: не только читать о том, что так надо делать, а брать — и делать. Не надо только читать, что обычно люди чистят зубы и принимают душ. Надо ещё и чистить зубы (хотя не хочется) и принимать душ (хотя лень). Вот с системным мышлением так же: лень, а надо. Вздыхайте — и думайте по системной мантре, пока не привыкнете делать это «на автомате», всё время, во всех проектах, подпроектах, разговорах с друзьями про их проекты, задаваясь этими вопросами при участии в беседах. Вот это — системное мышление!
Конечно, каждый участник проекта (а взаимосвязанных проектов тут может много обнаружиться, так что и участники других проектов тоже) имеет по поводу целевой системы проекта своё мнение, отличное от других. И участники проекта могут ещё и менять это своё мнение по поводу того, что является целевой системой проекта — прямо по ходу достижения между ними самых разных договорённостей (договорённости-то именно про это: про изменение мнений, было одно мнение — договорились о чём-то, это означает, что кто-то начальное мнение поменял).
Что делать в такой ситуации, когда мнения расходятся?! Непрерывно договариваться, проверять сохранение договорённостей**—** и продолжать договариваться всё время проекта, а не только в начальный его момент**.А если вы организатор—** ещё и непрерывно договаривать всех вокруг себя.
Вы к этому быстро придёте, когда поймёте, что любые ваши договорки будут нарушаться, если их участники в момент достижения ваших договорённостей ещё не договорились между собой. А потом они договорятся — и их договорённость окажется сильней договорённостей с вами, а когда вы договоритесь с ними по-новой, они опять передоговорятся — и опять ваши собственные договорённости с ними не устоят. Поэтому лучше бы вам самому их договорить — и достичь коллективной договорённости, она будет более стабильной.
Системы создаются коллективно, в этих коллективах договариваются. Системное мышление помогает определить, по поводу чего договариваться. Прежде всего**—** по поводу того, что именно мы делаем: какая система является целевой, т.е. успешность какой системы будет ключевой для проекта. Нет договорённости по поводу целевой системы**—** коллективно не знаем, что делать, каждый делает что-то по своим представлениям**. Д**обра** в такой ситуации не будет.**
Легко не распознать эту ситуацию, когда в речи и документах лишние генерализации. Если мы делаем «обувь», то это не означает, что договорились. Я считаю, что это женские босоножки 36 размера, соседи посчитали, что это мужские зимние ботинки — и разработали для них шнурки. Да, всё это «обувь», но при встрече этих уже разработанных шнурков с уже разработанным верхом босоножек у обеих команд будет сюрприз. А если подмётку «обуви» поручили делать третьей команде, то можно только догадываться, что им придёт в голову — валенки? Есть только один способ: специализировать в договорённостях целевую систему по максимуму и гарантировать, что результат договорённости по поводу целевой системы известен всем командам.
Почему так сложно определить систему? Потому как в культуре может ещё не существовать понимания удобного системного уровня, на котором определяется система.
Скажем, вы пытаетесь предложить новый способ создания стены из крупных блоков, но строят в этот момент только здания из кирпича (а понятия «стена» нет, только кирпичи). Мы приводили этот пример, когда говорили о системном мышлении, которое помогает бороться со сложностью: осмысленных операций с кирпичом в здании нет, но понятие «стена» может быть ещё не сформировано, поэтому с ним и не работают! Идея определить стену как систему, да ещё и дать её альтернативную конструкцию может быть очень, очень свежей!
Один из реальных кейсов: требовалось создать систему транспортировки самолётов с одного из аэродромов до завода-изготовителя, это нужно было для ремонта. Для этого где-то нужно было увеличить проём ворот, где-то добавить крепления на вагоне, где-то соорудить дополнительный пандус. Но все эти задачи решались как отдельные проекты, «по мере возникновения», у них не было общего финансирования (и деньги выделялись не сразу все, а на каждый проект отдельно, и нужно каждый раз было устно объяснять, зачем нужно потратить ту или иную сумму и выполнить ту или иную работу, общего списка работ не было). Не было понимания, что это всё нужно сделать, чтобы появилась «система транспортировки самолёта как целевая», не было в языке названия этой «системы транспортировки самолёта», не было проекта, не было менеджера проекта, был только человек, который был озабочен организацией транспортировки самолёта (хотя и проекта формально не было, и в голове этого человека не было «системы транспортировки самолёта», только где-то было желание ворота расширить, где-то крепление на прицепе переделать — но это не воспринималось как какие-то операции с «системой транспортировки самолёта»). Как только было осознано, что речь идёт просто о разных частях системы транспортировки самолёта, и если не сделать хоть один из этих проектов, то самолёты не будут проходить путь от аэродрома до завода, не будут ремонтироваться — всё волшебно наладилось, был назначен менеджер проекта, выделено финансирование, нашлись внешние проектные роли. При этом целевой системой был именно самолёт в точке окончания транспортировки, а система транспортировки — «наша система», создатель «самолёта в точке назначения».
В человеческом движении уровень мышц и костей — это совсем не тот уровень, на котором мы можем говорить о том, как строить движения тела, в теле только мышц выделяют более семисот. Понятно, что при движении человек не управляет сотнями мышц, он удерживает во внимании другие объекты. А тело в целом — это слишком высокий системный уровень, двигаем-то частями тела, да ещё и воспринимаемыми изнутри. Пришлось найти пропущенный ранее системный уровень: мышечные «ленты**»** (часто говорят о «линиях», о «струнах», ленты мы говорим, чтобы легче было разговаривать о скрутках этих лент, а ещё «мышечность» их условна — там участвуют и мышцы, и связки, и фасции, и сухожилия, так что «опорно-двигательные ленты» было бы вернее), соразмерные человеческому телу, воспринимаемые изнутри как такой специальный функциональный орган, конструкцию которого выполняют в разных позах разные кости, мышцы, фасции, сухожилия. Этот функциональный орган присутствует в сознании движенца как один объект, с которым и работают. Объяснения того, как двигаться, становятся короче точно так же, как в случае присутствия стены между уровнями кирпичей и дома, присутствия транспортной системы между отдельными хитрыми приспособлениями на пути самолёта и «системы ремонта самолётов»::надсистема.
В одном из проектов менеджеры-основатели фирмы/предприниматели собирали по чуть-чуть железнодорожным транспортом отдельные фракции отходов нефтеперегонки в прибрежные огромные хранилища. Потом сливали эти фракции одной большой порцией/лотом (порция для торговли, для сделки, для обработки) в танкер, отправляли на завод (мелкие партии сырья завод не принимал), и там перерабатывали в весьма дорогой продукт. Какая была их целевая система? В чём был секрет их бизнеса? Они создавали лот (ибо меньше лота определённой величины заводы исходную фракцию нефти не принимали в переработку). Как только «лот» был осознан как целевая система, фирма запустила ещё несколько проектов по той же схеме. Без этого всё предприятие выглядело как случайная стратегическая/предпринимательская/визионерская находка, разовый проект. Конечно, лот упоминался во всех разговорах — целевые системы часто присутствуют в речи. Но дело двинулось только после того, как было осознано, что именно лот — целевая система, а не десяток других систем, которые мелькали в обсуждениях.
Целевая система в начале проекта находится вне внимания. Её упоминают обычно в первые пять минут разговора, иногда даже называют, но людям в голову не приходит, что они ищут именно её. Но когда эта система находится (на неё обращают внимание, именуют и вводят в проект явно как целевую систему, по поводу которой все договариваются), жизнь становится много, много проще.
Ещё раз: никаких алгоритмов, рецептов, лайфхаков по определению целевой системы нет, это исследовательские догадки/«предпринимательские гипотезы»/негарантированное визионерство, творчество, что «по алгоритму», «по рецепту», «по лайфхаку», «по процедуре» или ещё как-то «по правилам» невозможно. Наоборот, вместо помощи в догадках системное мышление даёт множество способов критики предлагаемых догадок по поводу того, что будет целевой системой в проекте, и реализовывать нужно (понимая, что это всё только гипотеза/догадка) лучшую из выдержавших критику. Это подробно рассматривается в рамках методов исследований (на базе лучших объяснительных теорий того, как они устроены, сегодня это развитие идей попперианской эволюционной эпистемологии) и рациональности (на базе лучших сегодняшних объяснительных теорий о том, как строить действия в условиях неопределённого будущего).
Тем самым вы должны высказывать на базе вашей интуиции (возможно, коллективной! Хорошо организованные совместные рассуждения многих агентов, да ещё поддержанные компьютерным моделированием!) догадки/гипотезы о целевой системе и далее разворачивать от этих догадок системы создания и критиковать эти догадки, прогоняя их через многочисленные эвристики, которые приведены в наших руководствах по рациональной работе, системному мышлению, методологии, системной инженерии, руководствах по прикладным инженериям (например, по инженерии личности, системному менеджменту). Вспоминаем чеклист для проверки догадок по поводу систем из предыдущего раздела. Этот чеклист можно продолжать и продолжать, используя все подсказки по критике и поиску ошибок в договорённостях по поводу систем из нашего руководства.
Целевая система добавит ещё несколько пунктов. Например, несоблюдение вот этого пункта делает проект «дохлым»:
- совокупная стоимость владения системой должна быть меньше оценки пользы от её использования/эксплуатации**.**
Но если всё это оказалось соблюдено, то вы (вероятно! Это прогноз/гипотеза/догадка! Гарантировать ничего нельзя!) нашли целевую систему — и поэтому должны взять эту догадку всерьёз, то есть строить проект создания и развития системы исходя из этой догадки.