Kitabı oku: «Методология 2023», sayfa 2

Зачем изучать методологию

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

Аргументы против изучения методологии:

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

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

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

Аргументы за изучение методологии:

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

• Большинство людей, которые явно занялись методологией в инженерных и менеджерских проектах, были поставлены перед задачей научить какую-то новую команду работать каким-то методом, которым они владели неосознанно. Они не знали, чему именно нужно учить людей: «что такое метод», как о нём рассказывать. Такая задача (научить новому способу работы/way of working какую-то команду, адаптировав этот способ работы к новым условиям) появляется перед людьми чаще, чем можно подумать. Задача переноса и адаптации практик/метода/деятельности появляется практически в каждом проекте. Правильно было бы сэкономить время на изобретение велосипеда: дать людям в этой ситуации знания по методологии как таковой, а не только по конкретной технологии/методу/практике. Выучить один раз (наш курс!), а потом использовать во всех проектах.

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

Приложения методологии уже начинают изучать и на производстве, и в вузах, и не только неявно (то есть знакомством с разными Body of Knowledge как формой представления знаний о методах работы и неявным пониманием, что они по большому счёту устроены все примерно одинаково), но и явно через изучение методологических стандартов (обычно посвящённых какой-то записи способа работы, это OMG Essence, уже упоминавшийся ISO 24774:2014 и многие другие, обычно применяющиеся для описания «рабочих процессов», «процессов разработки», «видов жизненного цикла»). Эти стандарты стремительно отстают от жизни, и нужно иметь более общее знание о том, как устроены такие стандарты, чтобы замечать отставание и не следовать таким стандартам слепо.

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

Методология и системное мышление

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

Безмасштабная методология готова обсуждать и то, каким образом создателями могут выступать сообщества, общества и человечество (в них нет «поручений работ»), но это пока проработано крайне слабо – уже понятно, что для продуктивного создания комфортной/малорисковой среды обитания подходит рыночная экономика и нужно вводить понятия собственности (включая собственность на собственное тело, но и на рабочие продукты) и свободы обмена результатами труда, выходить на праксиологию. Вот, например, праксиология в варианте Murray Rothbard¹⁷ от 1951 года (и нельзя сказать, чтобы человечество сильно продвинулось в построении праксиологии):

⠀⠀

1. Теория изолированного агента (экономика Робинзона

Крузо)

2. Теория добровольного межличностного обмена

(каталлактика, или рыночная экономика)

⠀⠀⠀2.1. Бартер

⠀⠀⠀2.2. Со средствами для обмена

⠀⠀⠀⠀⠀⠀2.2.1. Свободный рынок

⠀⠀⠀⠀⠀⠀2.2.2. Эффекты насильственного вмешательства

⠀⠀⠀⠀⠀⠀в рынок

⠀⠀⠀⠀⠀⠀2.2.3. Эффекты насильственного запрета рынка

⠀⠀⠀⠀⠀⠀ (социализм)

3. Теория войны – враждебная деятельность

4. Теория игр (например, работы von Neumann

and Morgenstern)

5. Неизвестное

⠀

⠀

Как при этом должны быть устроены сообщества, общества и человечество в целом политически и как там должно быть устроено право, основанное на праксиологии как общей теории деятельности – это большой вопрос. Наш курс методологии не будет касаться в текущей версии практик/деятельности/труда сообществ, обществ и человечества, равно как будет мало говорить о «методе работы станка» или «методе работы робота», хотя в этом случае всё будет проще и понятней, разве что станок и робот не могут принимать решений о методе своей работы, это за них делают люди и организации людей, в состав которых входят и станки, и роботы. Но сейчас с развитием машинного интеллекта возможен и другой вариант рассмотрения: какой-нибудь отдел может быть представлен как компьютер, в состав которого входят люди – и по мере развития постепенно люди замещаются компьютерами, это и есть тренд «автоматизация всего», концепция киборга (cybernetic organism) как образа агента будущего заменяется концепцией гиброта (hybrot – hybrid robot¹⁸).

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

2. Создание и развитие: не жизненный, не цикл

Биологический жизненный цикл

Поскольку системный подход поначалу развивался на примерах сложных биологических систем, то часть его терминологии осталась с тех времён. Учёные-биологи хотели найти подходы к обсуждению таких сложных объектов, как заливной луг со всеми его взаимосвязанными сотнями видов растений, животных и сменой времён года – а слов для этого обсуждения не было. Они эти слова придумали, например «жизненный цикл». Вот жизненный цикл печёночного сосальщика¹⁹:

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

В инженерии/деятельности/практике как создании систем самого разного масштаба всё не так:

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

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

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

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

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

Жизненный цикл системы 1.0: работы, меняющие состояния целевой системы

Поначалу жизненный цикл (life cycle) просто обозначал отрезок времени, во время которого происходили проводимые системами создания работы с целевой системой, при этом по аналогии с биологическим циклом последовательно проходящие работы относили к разным стадиям (stages), иногда называемым фазами (phase) жизненного цикла – отрезкам времени, в которых система была в каком-то состоянии. Никакой эволюции, никаких гипотез, только выполнение требований. Хотя прототипы могли рассматриваться, но это были «последовательные приближения к окончательному варианту», никакого «бесконечного развития», «непрерывного всего», а «достижение цели»: результата работ.

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

Назовём это понимание «жизненным циклом v1.0»²⁰, оно разрабатывалось где-то в 70-х годах прошлого века, и не только в системной инженерии, но и в менеджменте, который в те времена считался более-менее «психологической» особой дисциплиной, а не просто изводом системной инженерии для организационных систем. В системном подходе уже тогда признавали непосредственно выходящими из него не только системную инженерию, но и operations research/исследование операций²¹ – исследование работ/operations с целью принятия лучших решений по ускорению их прохождения. Исследование операций скоро перестало быть «аналитикой», то есть только исследованиями, и в его синтетической/управленческой ипостаси стало operations management (операционное управление, акцент не только на понимании и отчётах, но и на действиях на основе этих исследований – собственно управлении, изменении ситуации в части ускорения прохождения потока работ через производящие эти работы ресурсы).

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

Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 1979 года, это Harold Kerzner «Project Management: A Systems Approach to Planning, Scheduling, and Controlling». То есть управление проектами в момент его появления было применением системного подхода к планированию, построению графика работ и контролю выполнения работ. Это похоже на то, как понималась в те времена и классическая «железная» системная инженерия: применение системного подхода к инженерной работе.

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

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

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

Анастасия с её молотком в роли плотника как оргзвено, материальные и наличные гвозди, молоток и доски – ресурсы, без доступности которых выполнение работы/сервиса оргзвена Анастасии невозможно.

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

За забивку гвоздей у нас ответственна Анастасия в должности «плотник» (не путать с оргролью «плотник»), и обычно она забивает 180 гвоздей за час. Обсуждаемая работа начинается в полдень 3 мартобря 2029 года, и планируемая её продолжительность – десять минут. За это время Анастасия как оргзвено «плотник» должна забить 20 гвоздей в четыре места на досках.

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

Обсуждение работ обычно является предметом операционного менеджмента и затрагивает логистический предмет интереса: времени прохождения потока работ. Интересует тут не столько содержание работы (это обсуждается как метод/практика/способ работы/way of working), а как задействовать для этой работы имеющиеся ресурсы, чтобы получить оптимальное время прохождения потока работ (не всегда минимальное, ибо иногда важней равномерность задействования ресурсов, чем именно минимальное время выполнения, требующее обычно очень неравномерной загрузки ресурсов). В операционном менеджменте интересуются фактами работы в отрыве от способов работы. Область интересов операционного менеджмента включает такие важные характеристики, как время согласования выделения ресурсов на работы, время задействования ресурсов на работы, цены задействования этих ресурсов (неважно, как и что они делают, с этим разбираются в других практиках другие трудовые роли, операционному менеджеру важно только сколько ресурсы работают и сколько они будут стоить), и времени самой работы без погружения в способы её выполнения. Жизненный цикл 1.0 как последовательность крупных работ-стадий тем самым отражает модульное/конструктивное/продуктное представление о работах систем создания. Проект – это работы оргзвена как группы организованных (то есть с понятными полномочиями по распоряжению трудом, материалами и прочими ресурсами) агентов биологических и не очень, с каким-то оборудованием и материалами, полномочиями по проведению работ (то есть проект – это даже не работы оргзвена, а работы оргвозможности/capability). Проект имеет целью его работ (хотя тут более корректно говорить о цели оргзвена или даже оргвозможности, «цель работ» тут – метонимия²³) создание и развитие какой-то системы. Дальше мы будем считать, что если речь идёт об оргзвене, то оно уже достигло состояния оргвозможности – все умения, ресурсы и полномочия по распоряжению ими оргзвеном уже получены.

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

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

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

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

Обратите внимание, что по факту жизненный цикл ничего не говорит о целевой системе и её состояниях. Он говорит про то, что делают системы создания: работают-то они, а не целевая система. Целевая система пассивна, это предмет работ, в современном операционном менеджменте работы над каким-то изменяемым предметом работ называют case/дело (от «судебного дела», медицинской «истории болезни», case file – это папка «Дело №__»). В кейсе/деле забивания гвоздей целевая система (в момент эксплуатации!) – это забитый гвоздь. Кейсом будут все работы для этого, а сам кейс будет назван по его предмету – «гвоздь» (предмет этих работ). Описывает это вариант операционного менеджмента, известный как case management в его разных вариантах, например adaptive/dynamic/advanced case management²⁴, который в последнее время перестал быть в силу общей распространённости отдельной компактно излагаемой дисциплиной, а поддержка со стороны программного обеспечения перешла в системы с облегчённым программированием, универсальные моделеры, LowCode²⁵). Очень часто «проектом» называют и более-менее крупный кейс. Значение слова «проект» окончательно оторвалось от классического «проектного управления».

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

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

• Как на функциональные объекты, и видит их как набор оргролей, которые выполняют практики/работают по методу.

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

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

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