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

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

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

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

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

Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 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). Проект имеет целью его работ (хотя тут более корректно говорить о цели оргзвена или даже оргвозможности, «цель работ» тут --- метонимия^[4]) создание и развитие какой-то системы. Дальше мы будем считать, что если речь идёт об оргзвене, то оно уже достигло состояния оргвозможности --- все умения, ресурсы и полномочия по распоряжению ими оргзвеном уже получены.

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

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

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

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

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

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

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

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

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

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

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

• Обнаружение потребности в гвоздевом соединении (гвоздь запланирован --- но так пишут реже, ведь это указание на работу, а не на гвоздь! Состояние «гвоздь запланирован» тут указывает на результат выполнения инженерами сервиса по формированию сводно-заказной спецификации, которая попала в службу закупок. Писать «гвоздь запланирован», упоминая смену состояния гвоздя как объекта кейса правильней, потому как легче проконтролировать результат работы, но так при документировании жизненного цикла в первом поколении представлений об этом цикле писали редко. Хотя именно так принято описывать основной результат работы в качестве имени работы в методологии управления проектами PRINCE2^[7], это хорошая практика именования. Помним, что «большой кейс называют проектом», а уж связь кейс-менеджмента и проектного менеджмента будет рассказана подробней в курсе «Системный менеджмент»).
• Закупка (или гвоздь закуплен --- помним, что в жизненном цикле 1.0 волнуют работы, а не состояния гвоздя! Состояния гвоздя волнуют тогда, когда обсуждаем целевую систему и прохождение ей различных состояний в ходе жизненного цикла --- то есть прохождение различных состояний в ходе работ с целевой системой. Состояние «гвоздь закуплен» тут указывает на результат выполнения сервиса по закупке гвоздя, а работа с гвоздём --- «закупка», её и указывали, и даже слово «гвоздь» забывали указать, сокращали даже «закупка гвоздя» до просто «закупка». Менеджеры любят обобщать, когда пишут о работах, их не волнует содержание работы и специфика этой работы).
• Выдача в монтаж (или гвоздь доступен в месте забивки --- указание на работу по выдаче гвоздя в монтаж. Дальше мы просто не будем писать эти разъяснения, идея тут понятна).
• Нацеливание гвоздя (гвоздь нацелен).
• Вколачивание гвоздя (гвоздь вбит).
• Проверка крепости соединения («гвоздь держит крепко», но объект поменялся. Теперь это «соединение». Куколка стала бабочкой! Другой объект, по-другому называем).
• Эксплуатация соединения (соединение держит и стабильно при нагрузках)
• Вытаскивание гвоздя (гвоздь вытащен).
• Ликвидация гвоздя (гвоздь выкинут --- жизненный цикл всегда идёт до исчезновения объекта работ).

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

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