Анатолий Левенчук – Системное мышление 2024. Том 2 (страница 25)

В стандартах классической системной инженерии предпочитают о подобных системах говорить enabling system (например, в серии стандартов, основанных на ISO 15288:2023), но вот David Deutsch и Chiara Marletto предложили говорить о таких системах constructor (одно из словарных значений как раз «создатель»): основное тут то, что подобного сорта система поддерживает свою идентичность в ходе каких-то однородных изменений, производимых создателем в окружающей среде. Например, молекула катализатора производит множество актов катализа, оставаясь неизменной (enable chemical reaction, слово «enable» в английском языке тут хорошо подходит, поэтому enabling system в английском языке не вызывает вопросов). Или станок производит множество деталей. Или преподаватель обучает/«изготавливает» множество студентов. Или фирма рубит в лесу множество деревьев и изготавливает из них множество досок. Или кошка рожает множество котят, а самореплицирующийся робот производит/изготавливает множество себе подобных «роботят» (эти эксперименты уже идут). 48 49

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

Ещё раньше системы создания называли просто системами жизненного цикла, иногда даже сразу предприятиями (enterprise), ибо проектами создания чаще всего занимаются предприятия. Сейчас создатели упоминаются как системы, участвующие в проектах создания и развития систем в отличие от проектов, занимающихся эксплуатацией систем. «Создание» – это по факту однократное (хотя там внутри может быть множество попыток с разными прототипами, просто эти прототипы не попадают в целевое окружение, они ещё могут не иметь минимальной нужной функциональности) выполнение работ по выпуску системы как MVP (минимальный жизнеспособный продукт, minimal viable product), а «развитие» – это отсылка к длительному/многократному практикованию метода изменения конфигурации системы с целью улучшения её приспособленности/fit к «эволюционной нише», то есть использованию в каких-то надсистемах. Поэтому «создание» – это чаще всего выпуск MVP, а «развитие» – это выпуск множества версий системы после того, как она создана, то есть выпущена версия MVP. 50

Создатель – это не только развитый интеллектуально агент (человек, робот) или даже коллективный агент (предприятие). Формально это может быть и просто какой-то станок, который вытачивает целевую деталь – эта деталь потом станет подсистемой работающей целевой системы. Станок не участвует в эксплуатации целевой системы, он не входит в её эксплуатационное/операционное окружение, не рассматривается вообще во время эксплуатации. И даже метод работы станка для получения ожидаемых (а не абы каких) результатов работы обычно так не называется, чаще говорят «функция». Зато он участвует в создании системы – так что этот станок будет создателем/constructor/enabling system/системой создания. И, конечно, станок будет входить в какое-то предприятие, но предприятие будет для этого станка далёкой над-над-над-надсистемой, через много системных уровней (например, системные уровни станок-сектор-отдел-служба-предприятие). А если рассмотреть станок-2, принимающий участие в создании станка-1, который принимает участие в создании целевой системы, то эта цепочка будет называться . В цепочках создания могут быть и люди, и предприятия, и AI. И из этих цепочек создаются сложные Например, цепочкой создания, в которой основное отношение – создания/enabling, а не часть-целое/композиции графы создания.

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

• учебный курс по продажам и

• Преподавателя для «менеджеров по продажам»/продавцов.

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

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

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

Важно, что целевая система определяется для множества ролей, для большого коллектива. Об этом подробней будет говориться в следующих разделах. А как называется какая-то система, которая прямо сейчас находится в центре нашего внимания, но не целевая? Если мы эту назовём целевой, то нас никто не поймёт, будут считать (справедливо), что мы тянем одеяло на себя. Например, (в том числе вариант «мне и мне», или даже «нас тут пять ролей в команде из троих человек») поручили разработать винтик для большого и сложного станка. Да, целевой системой является отгружаемый клиенту станок, который войдёт в остальное оборудование завода клиента как системное окружение, но мы-то в центре внимания вот прямо сейчас в разговоре держим этот винтик – и до системного уровня окружения станка на заводе клиента нам как до Луны, слишком высоко! Что, нам считать станок над-над-надсистемой для этого винтика::система? Да, конечно. Считать винтик целевой системой? Нет, конечно. Целевая система уже есть, станок, это на каком-то среднем масштабе времени, жизненного цикла всего проекта станка, требующего кооперации и договаривания многих людей. Целевая система для этого и была введена как тип: это исходная точка для договаривания многих ролей, часто многих ролей, исполняемых командами агентов. нашу систему/system-in-hand нам для всей команды

Для таких ситуаций рассмотрения отдельными агентами из больших систем создания, состоящих из множества цепочек создания и появляется вид системы, который называется термином (engineered system в классической системной инженерии, managed system в системном менеджменте, MySystem, OurSystem, система в руках/system in hand). «Наша система» обозначает систему в частном/преходящем/вре́менном фокусе внимания в системном разбиении целевой системы или длинной цепочке создания. Скажем, «целевая система – самолёт, наша система – пятый винтик в топливном насосе двигателя целевого самолёта», или «целевая система – самолёт, наша система – уникальный станок::создатель для нарезки „высокочастотного кабеля авионики“::подсистема этого самолёта», или «целевая система – процветающее трудолюбивое общество Остазии, но нашей системой сегодня является общество Евразии и Океании, которое мы всячески ослабляем и дестабилизируем». наша система

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

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