Обратите внимание, что по факту жизненный цикл ничего не говорит о целевой системе и её состояниях. Он говорит про то, что делают системы создания: работают-то они, а не целевая система. Целевая система пассивна, это предмет работ, в современном операционном менеджменте работы над каким-то изменяемым предметом работ называют case/дело (от «судебного дела», медицинской «истории болезни», case file это папка «Дело __»). В кейсе/деле забивания гвоздей целевая система (в момент эксплуатации!) это забитый гвоздь. Кейсом будут все работы для этого, а сам кейс будет назван по его предмету «гвоздь» (предмет этих работ). Описывает это вариант операционного менеджмента, известный как case management в его разных вариантах, например adaptive/dynamic/advanced case management24, который в последнее время перестал быть в силу общей распространённости отдельной компактно излагаемой дисциплиной, а поддержка со стороны программного обеспечения перешла в системы с облегчённым программированием, универсальные моделеры, LowCode25). Очень часто «проектом» называют и более-менее крупный кейс. Значение слова «проект» окончательно оторвалось от классического «проектного управления».
Это только в биологическом жизненном цикле в дикой природе любое яйцо или гусеница создают сами себя! Помним, что создателями/«системами создания»/«enabling systems»/constructors в системном мышлении называют не системы, которые делают снабжение/заправку/подкормку в ходе эксплуатации (это обычно делает окружение, системы времени эксплуатации), а системы, которые во время создания, модификации и ликвидации системы ведут/двигают её по жизненному циклу, а затем повторяют это много раз в ходе развития/эволюции системы.
Методология использует системное мышление и смотрит на такие системы создания, как проекты/оргзвенья/предприятия/команды/коллективы/организации, точно так же, как смотрит на любые другие системы:
Как на функциональные объекты, и видит их как набор оргролей, которые выполняют практики/работают по методу.
Как на конструктивные объекты, и видит их как оргзвенья, в ходе их использования «выполняющие работы»/«предоставляющие сервис» (а уж по какому методу там работает этот конструктивный объект дело десятое. Конструктивное представление стремится абстрагироваться от метода получения результата работы).
Рассуждения про то, что создателями могут быть сообщества, общества и человечество пока формулируются не так строго. Так что мы в последующих главах ограничимся создателями-людьми и их организованными (понятно кто распоряжается трудом и другими ресурсами) группами, то есть создателями-организациями/оргзвеньями. И не забывайте, что в связи с развитием машинного/искусственного интеллекта (AI) и появлением безмасштабного мышления на фоне тренда тотальной автоматизации появляется ещё и альтернативное понимание: оргзвенья представляются «полуавтоматом», то есть компьютером (возможно, с датчиками и исполнительными устройствами), который обслуживается людьми. Это всё симметричное представление человек и компьютер, которые вместе выполняют сервис S на интерфейсе I могут рассматриваться как «станок и его оператор», а могут рассматриваться и как «оператор с его станком».
Конечно, формально создателем/системой создания может быть и не оргзвено, а только его часть станок, обрабатывающий деталь целевой системы. Но если этот станок будет плохо работать для вашей детали, вы тут же вспомните, что этот станок входит в состав оргзвена: уговаривать сам станок и требовать от него переделки детали вы не будете, вы просто найдёте тех людей, кто полномочен распоряжаться этим станком, и будете разбираться с ними. Если речь идёт о системах создания, то мы ни на секунду не забываем, что главное в них люди, и работы выполняют люди, а хоть и с помощью технологий (оборудования, материалов). Экземпляры сервисов, выполняемых оргзвеньями это и есть работы. Симметрично, если мы обсуждаем «оргзвено из людей» надо помнить, что люди никогда не работают голыми руками, а в последнее время и «голой головой», поэтому забыть включить в состав оргзвена станок это большая ошибка. Общее правило тут простое: если думаешь про людей, не забудь про их станки, если думаешь про станки не забудь про людей. В этом плане современное производство это всегда «полуавтомат», но тренд в нём повышать уровень автоматизации.
Итак, Анастасия, предоставляющая сервис забивки гвоздей, берёт свой молоток и забивает выданный ей гвоздь 143 в доску #26, то есть выполняет работу. Жизненный цикл гвоздя в представлениях прошлого века (первое поколение, 1.0) состоит уже не из состояний гвоздя («лежит в коробке», «взят в руки», «нацелен», «забивается», «забит»), а происходящих с ним работ, которые, конечно, можно описывать и как конечные состояния гвоздя, но всё-таки это работы систем создания, сам гвоздь при этом ничего не делает, он пассивен. В не жизненном не цикле принят аналог «аристотелевской физики», где палец давит на стол, а стол не давит на палец. Работают системы создания, а гвоздь в ответ не работает, он пассивный объект для систем создания, он просто меняет состояния по мере выполнения с ним работ. И системное мышление даже в этой первой версии представления жизненного цикла как цепочки работ отслеживает, чтобы речь шла о полном жизненном цикле, а не только его кусочке в моменте нанесения по гвоздю ударов Анастасией. Работы самой Анастасии это только часть работ! Вот примерный жизненный цикл гвоздя как стадии/работы (это же «кейс гвоздя», только он будет рассказываться как «прохождение гвоздём состояний», а практики работ по переводу гвоздя из состояния в состояние будут подбираться, исходя из ситуации):
Обнаружение потребности в гвоздевом соединении (гвоздь запланирован но так пишут реже, ведь это указание на работу, а не на гвоздь! Состояние «гвоздь запланирован» тут указывает на результат выполнения инженерами сервиса по формированию сводно-заказной спецификации, которая попала в службу закупок. Писать «гвоздь запланирован», упоминая смену состояния гвоздя как объекта кейса правильней, потому как легче проконтролировать результат работы, но так при документировании жизненного цикла в первом поколении представлений об этом цикле писали редко. Хотя именно так принято описывать основной результат работы в качестве имени работы в методологии управления проектами PRINCE226, это хорошая практика именования. Помним, что «большой кейс называют проектом», а уж связь кейс-менеджмента и проектного менеджмента будет рассказана подробней в курсе «Системный менеджмент»).
Закупка (или гвоздь закуплен помним, что в жизненном цикле 1.0 волнуют работы, а не состояния гвоздя! Состояния гвоздя волнуют тогда, когда обсуждаем целевую систему и прохождение ей различных состояний в ходе жизненного цикла то есть прохождение различных состояний в ходе работ с целевой системой. Состояние «гвоздь закуплен» тут указывает на результат выполнения сервиса по закупке гвоздя, а работа с гвоздём «закупка», её и указывали, и даже слово «гвоздь» забывали указать, сокращали даже «закупка гвоздя» до просто «закупка». Менеджеры любят обобщать, когда пишут о работах, их не волнует содержание работы и специфика этой работы).
Выдача в монтаж (или гвоздь доступен в месте забивки указание на работу по выдаче гвоздя в монтаж. Дальше мы просто не будем писать эти разъяснения, идея тут понятна).
Нацеливание гвоздя (гвоздь нацелен).
Вколачивание гвоздя (гвоздь вбит).
Проверка крепости соединения («гвоздь держит крепко», но объект поменялся. Теперь это «соединение». Куколка стала бабочкой! Другой объект, по-другому называем).
Эксплуатация соединения (соединение держит и стабильно при нагрузках)
Вытаскивание гвоздя (гвоздь вытащен).
Ликвидация гвоздя (гвоздь выкинут жизненный цикл всегда идёт до исчезновения объекта работ).
Жизненный цикл это всегда, даже в первых его версиях, работы создателей от появления идеи целевой системы до уничтожения целевой системы (включая эксплуатацию: мы считаем, что её тоже ведут создатели, хотя в момент эксплуатации система уже создана. И ликвидация/вывод из эксплуатации ведётся создателями, хотя это обратное созданию действие). Дальше к жизненному циклу в момент появления третьего поколения системного подхода с его временем эволюции/развития добавляют ещё и развитие. То есть в ходе развития проходит множество жизненных циклов систем и отдельных фич этих систем.
Методология удерживает внимание участников проекта/создателей не только на текущих операциях с целевой системой, но на всех от момента появления идеи, до уничтожения системы, а также на множестве этих операций в ходе развития/эволюции системы, а не только однократного замысливания-проектирования-изготовления-использования-ликвидации. Всегда удерживаем во внимании команды или даже коллектива (команды команд) проекта то, что было с целевой системой раньше, что происходит сейчас, что будет происходить потом, а также удерживаем во внимании создателей (команды или коллектива) то, что происходит с самими создателями в цепочке создания, и не ограничиваемся одной версией системы, помним о развитии.
Выполнение работ оргзвеньями
Ведение жизненного цикла (принудительное изменение снаружи целевой системы её состояний в ходе её замысливания, создания, эксплуатации, ликвидации, т.е. «жизни неживого») делается оргзвеньями людьми с материалами и оборудованием, находящимися в распоряжении этих организованных людей. Чаще всего оргзвенья сами не инициируют работы. В коллективной деятельности одни оргзвенья имеют полномочия просить сделать работу у других оргзвеньев, у которых есть обязанности такие просьбы выполнять это и есть организация. Если вы попросите в пиццерии пиццу, то вам выполнят работы по её приготовлению и это само по себе факт замечательный. Попробуйте попросить в пиццерии приготовить вам летние босоножки, и посмотрите, что будет после этой просьбы.
Организовывание сотрудничества в части выполнения просьб о работе и есть предмет одной из практик системного менеджмента: практики оргразвития/organizational development/организационного управления/organizational management (подпрактики оргпроектирования и лидерства): кто кого (оргзвенья) о чём (работы/сервисы) имеет право попросить так, что просьбы вызывают их выполнение, а не удивление, вопросы и сопротивление вместо сотрудничества.
Речь тут продолжает идти не о том, как и почему выполняются работы с содержательной точки зрения (то есть системах создания как функциональных частях), а о логистике работ: как сделать так, чтобы кто-то как ресурс эту работу выполнил (сервисах систем создания как конструктивных частях/модулях/оргзвеньях). Системное мышление позволяет рассуждать про системы создания и системы окружения целевой системы с использованием одних и тех же понятий. Понятия/типы, организующие внимание в мышлении для всех видов систем (целевых, окружения, создателей в цепочках) одни и те же, хотя терминология/слова для этих понятий могут различаться. В этой компактности сила фундаментальных дисциплин, в том числе методологии, обсуждающей способы работ по созданию систем.
Каждая работа проходит следующий цикл взаимодействия оргзвеньев (это подробно обсуждается в подходе к архитектурному описанию предприятий DEMO27 и курсе «Системный менеджмент»):
Работа затребована оргзвеном-инициатором, часто в виде её появления в каком-то плане (с заданной последовательностью выполнения работ, а если план-график, то и указанными сроками выполнения) или бэклоге (backlog, набор работ к выполнению но без указания строгой последовательности их выполнения, в том числе сроков): координационный акт, речь идёт об информационном мире поручений-согласований-обещаний оргзвеньев, но не о реальной физической работе по изменению мира или даже работе по изменению описаний системы.
Работа принята оргзвеном-исполнителем к исполнению, это тоже координационный акт.
Работа выполняется оргзвеном-исполнителем. Это производственный акт (production act), реальное выполнение работы. Именно это учитывается в жизненном цикле целевой системы, над которой выполняется работа. В жизненном цикле обсуждаются только производственные акты, а не координационные акты! Учёт координационных актов и требуемых на них трат ресурсов и задержек времени на «согласование» и «выдачу поручения» (иногда нужно год интенсивно работать, чтобы получить разрешение на пятиминутную реальную работу) ещё ждёт адекватного отражения в методологии. Пока же это рассматривается в дисциплине рациональности как «рациональное принятие решений» на базе теории принятия решений28.
Работа предъявлена к приёмке оргзвеном-исполнителем, это координационный акт.
Работа принята оргзвеном-инициатором работы, координационный акт.
Деление на координационные и производственные акты важно, чтобы делать правильные оценки времени: от момента затребования работы до момента принятия работы на координационные акты легко может уходить до 60% времени, и только 40% времени на проведение самой работы, в случае знаниевых работ это может быть и 80% на 20% в среднем (ибо работы по «обоснованиям решений» очень трудоёмки сами по себе). Поэтому жизненный цикл гвоздя может занимать в разы больше времени, чем время выполнения самих работ, затрагивающих физический гвоздь, как производственных актов. Трудность в осуществлении координационных актов (решений о проведении работ, при этом нужно понимать, что принятие этих решений требует не только коллективной чисто мыслительной/вычислительной работы, но и каких-то действий, экспериментов, получения дополнительной информации то есть траты ресурсов) часто называют в организациях «отсутствие политической воли»: все материальные возможности для ведения работ есть, но работы не ведутся, ибо решения об их проведении полномочными оргзвеньями не принимаются! Иногда это и впрямь не хватает собранности, иногда это нежелание вкладывать ресурсы в условиях жесточайшей неопределённости, а снятие неопределённости может тоже требовать ресурсов, которые тоже не будет «политической воли» вкладывать!
Как планировать работы по полному времени координации+производства работ, или только по актуальному времени потребления ресурсов? Разные школы управления работами (проектного управления, управления процессами, управления программами, управления кейсами) отвечают на этот вопрос по-разному. Управление работами как раз занимается планированием работ и контролем выполнения работ как единиц поведения оргмодулей/ оргзвеньев/конструктивных оргединиц без обсуждения того, как правильно выполнять работы так, чтобы они меняли целевую систему в нужном направлении (т.е. без обсуждения оргролей и их функций/практик жизненного цикла).