В инженерии/деятельности/практике как создании систем самого разного масштаба всё не так:
целевые системы сами не растут и не проходят метаморфозы, их придумывают, проектируют, изготавливают, эксплуатируют, модернизируют, выводят из эксплуатации системы создания, то есть люди с их средствами производства. Это означает, что в самих системах никакой жизни нет, жизненный цикл оказывается не жизненным, системы создания ведут целевую систему по её циклу, а не она сама продвигается по своим состояниям.
Целевые системы не несут яиц, не живородят, не размножаются вегетативно. Это означает, что жизненный цикл не замыкается, не повторяется. То есть это не цикл.
Жизненный цикл оказался для неживых систем не жизненным и не циклом, но сам термин остался, причём он постепенно менял своё значение. Проблема в том, что многие из этих «исторических» значений используются до сих пор, наряду с современными значениями, и это создаёт путаницу при обсуждении проектов по созданию и модернизации самых разных систем.
Более того, даже для живых систем (бактерии в биореакторе, стадо коров на ферме, поле генно-модифицированной пшеницы, гектар леса) также применяется мышление про создателя (биоинженера, фермера, агронома, лесника) и его целевую систему и то, как создатель создаёт свою целевую систему. Никто сегодня не предполагает, что есть жизненный цикл коровы, который она проходит самостоятельно без фермера, поколение за поколением живя в лесу. И лес за ним присматривает лесник, если мы изменяем лес к лучшему.
Жизненный цикл по факту означает происходящее с одним организмом, то есть не включает обсуждение мутаций. Если включить в рассмотрение другой масштаб времени, эволюции, на котором обезьяны превратились в людей, а динозавры в птиц, то это уже не будут называть «жизненным циклом», а назовут эволюцией/развитием. Техно-эволюция/техно-развитие носит другую природу, нежели дарвиновская эволюция: основные знания об устройстве как целевой системы, так и создателя находятся не в самих этих системах (геном: совокупность наследственного материала), а в системах-создателях (мемом: совокупность материала с «проектной документацией», хотя тут тоже можно делить дальше на меметическую эволюцию человеческой культуры, где мемом хранится в книгах, мозгах и материальной культуре в форме «шаблонов вещей», и техническую эволюцию, где мемом именно в проектной документации, текстах технических стандартов, учебников инженерии). Мы редко будем рассматривать развитие живых систем в ходе дарвиновской эволюции, но часто будем рассматривать развитие систем в ходе техно-эволюции. Поэтому мы будем сокращать: не говорить «техно-развитие», а говорить просто «развитие», но в случае эволюции мы всё-таки будем частный случай техно-эволюции на основе проектируемого мемома называть именно техно-эволюцией, чтобы не путать её с дарвиновской биологической эволюцией на основе мутирующего генома.
Жизненный цикл системы 1.0: работы, меняющие состояния целевой системы
Поначалу жизненный цикл (life cycle) просто обозначал отрезок времени, во время которого происходили проводимые системами создания работы с целевой системой, при этом по аналогии с биологическим циклом последовательно проходящие работы относили к разным стадиям (stages), иногда называемым фазами (phase) жизненного цикла отрезкам времени, в которых система была в каком-то состоянии. Никакой эволюции, никаких гипотез, только выполнение требований. Хотя прототипы могли рассматриваться, но это были «последовательные приближения к окончательному варианту», никакого «бесконечного развития», «непрерывного всего», а «достижение цели»: результата работ.
Жизненным циклом чайника называли отрезок времени, в течение которого с ним проводились работы (чайник ведь сам себя не сделает, это не биология все работы с ним должны провести какие-то внешние по отношению к нему системы создания). Эти системы создания должны решить сделать чайник (а не кофейник), задокументировать требования, затем (последовательность важна! Сначала требования, потом проектирование это будут «стадии») запроектировать чайник (выбрать внешний вид и материалы), сделать чайник (согласно проекту закупить материалы и изготовить), затем использовать для заварки чая (эксплуатировать), затем разбить и выкинуть. Вот всё это время прохождения работ создателя с чайником как целевой системой и называли «жизненным циклом»::«отрезок времени», а сами работы в их самом верхнеуровневом разбиении: принятие решения о чайнике, проектирование чайника, изготовление чайника, эксплуатацию чайника, ликвидацию чайника называли «стадиями/фазами жизненного цикла»::работы. Обратите внимание на разницу в типах объектов: жизненный цикл это отрезок времени (измеряется в часах), а стадии это работы, когда кто-то что-то с чем-то делает, меняет мир. Работы это динамический объект/изменение/поведение, а не отрезок времени существования этого объекта, то есть отрезок времени, пока идут изменения. Жизненный цикл был «двадцать лет», делился на «сформулировать требования к забору», «спроектировать забор», «построить забор» (и вот уже прошло два года), «следить, чтобы забор был в рабочем состоянии» (восемнадцать лет), «разобрать забор и выкинуть строительный мусор» (последние две недели из двадцати лет жизненного цикла).
Назовём это понимание «жизненным циклом v1.0»20, оно разрабатывалось где-то в 70-х годах прошлого века, и не только в системной инженерии, но и в менеджменте, который в те времена считался более-менее «психологической» особой дисциплиной, а не просто изводом системной инженерии для организационных систем. В системном подходе уже тогда признавали непосредственно выходящими из него не только системную инженерию, но и operations research/исследование операций21 исследование работ/operations с целью принятия лучших решений по ускорению их прохождения. Исследование операций скоро перестало быть «аналитикой», то есть только исследованиями, и в его синтетической/управленческой ипостаси стало operations management (операционное управление, акцент не только на понимании и отчётах, но и на действиях на основе этих исследований собственно управлении, изменении ситуации в части ускорения прохождения потока работ через производящие эти работы ресурсы).
Дальше это направление управления работами/операционное управление/операционный менеджмент на базе каких-то представлений тогдашнего системного подхода развилось в классическое проектное управление/project management, как его понимают сегодня в менеджменте (хотя к нему кроме собственно управления операциями добавилась сегодня ещё и организация команды проекта, это подробней объясняется в курсе системного менеджмента22). Мы же считаем операционный менеджмент эксплуатационной (то есть происходящей с уже созданной системой) инженерией организационной системы.
Одна из самых популярных книжек по проектному управлению, вышедшая первым изданием ещё в июне 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). Проект имеет целью его работ (хотя тут более корректно говорить о цели оргзвена или даже оргвозможности, «цель работ» тут метонимия23) создание и развитие какой-то системы. Дальше мы будем считать, что если речь идёт об оргзвене, то оно уже достигло состояния оргвозможности все умения, ресурсы и полномочия по распоряжению ими оргзвеном уже получены.
Терминологически проект иногда означает работы оргзвена проекта (рабочей группы проекта, проектной организации терминология тут самая разная), а иногда и само оргзвено, то есть проект как организация проекта. В жизни встречаются оба значения термина, и надо их как-то различать: путать рабочую группу проекта (чаще всего она меняется медленно) и работы этой группы (которые легко будут перепланированы) не стоит. «Проект изменил цвет забора с красного на синий» можно понимать и как «работы изменили цвет забора» и как «команда изменила своими работами цвет забора», так что просто надо быть внимательными к контексту иногда эти онтологические различия неважны, иногда важны. Но вот письмо работам направить нельзя, а письмо команде можно. Поэтому «я написал проекту письмо» тут уже будет онтологический дребезг.
Мы в курсе будем тоже использовать оба значения, но чаще проектом мы будем считать оргзвено со всеми приданными ему ресурсами и полномочиями (то есть оргвозможность). Проект::организация в этом понимании ведёт работы, и «создать проект», «организовать проект» это означает создать организацию, которая будет дальше выполнять работы проекта как сервисы этой организации.
Чтобы собрать какую-то нужную нам (целевую, думаем о времени эксплуатации/использования) конструкцию из досок, нам нужно создать проект/project/создателя::оргзвено. Этот проект (создатель, думаем о времени создания конструкции из досок как целевой системы) состоит из модулей Анастасии-с-ответственностью, молотка, 20 гвоздей, четырёх досок. Нам нужно ещё запланировать эти все ресурсы на 20 минут, иначе работы не случится. Это всё менеджерские работы: проекты создают менеджеры (создатели организаций).
Нам нужно всё это откуда-то взять, а результат работы (скреплённые доски) куда-то отдать тоже задача не инженерная, а менеджерская (логистическая, т.е. на перемещение ресурсов от одного места их обработки к другому). Операционного менеджера (роль, выполняющая практику/труд операционного менеджмента) интересует только логистика, «как собрать работу из её частей-вещей/ресурсов». Не интересует «каким способом происходит работа, почему она даст результат», как вообще нужно забивать гвозди, и почему нужно скреплять доски гвоздями, а не склеивать их, или вообще приматывать их друг ко другу верёвками, и не интересует, как сделать гвоздевое соединение прочным. А раз так, то по работам бесполезно обсуждать, как же именно эти работы в их взаимодействии будут двигать систему по её состояниям в жизненном цикле. Обсуждение работ не связано с функциональностью/ролями этих работ, оно связано с планированием ресурсов и контролем выполнения плана: минимизацией времени прохождения потока работ, это типовое предпочтение операционного менеджера. Для обсуждения «как работать» нужно обсуждать не работы, а практики!