Читать книгу Методология 2022 - Анатолий Левенчук - Страница 8

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

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

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

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

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

Конечно, использование системного подхода в менеджменте не ограничивается сегодня только операционным управлением. Инженерия предприятий (и тут множество названий: enterprise engineering, business engineering, organizational engineering) тоже относится к менеджменту (но не операционному, а организационному – речь идёт не об управлении работами предприятия, а об управлении работами по созданию предприятия: Operations time для предприятия противопоставляется его Development time, и как всегда стоит задача их объединения, DevOps), и она похожа на традиционную инженерную работу, хотя и с особенностями, в том числе терминологическими: инженерия архитектурных требований в ней – это стратегирование, инженерия системной архитектуры – это инженерия архитектуры предприятия, управление конфигурацией в ходе operations/эксплуатации организационной системы – это операционный учёт, основная практика в «изготовлении» предприятия – лидерство как «катализирование сотрудничества», ибо предприятие/организацию/команду/коллектив невозможно «собрать из частей», то есть «собрать из людей и оборудования» так, как это делается с традиционными инженерными системами типа часов или ракет и т. д.

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

Работы – это конкретные процессы, в которых участвуют ресурсы для этих работ. Анастасия забивает гвозди молотком в доски. Забивание гвоздей – это и есть работа, которую она выполняет. Работы чаще всего называются не по их цели, а по их текущему содержанию – не «скрепление досок», что может предполагать и клеевое соединение, и гвоздевое, а именно «забивание гвоздей», хотя тут есть множество и других вариантов. Но в целом работы – это оказываемые ресурсами акты сервиса, т.е. поведение систем создания по изменению внешних по отношению к ним систем. Анастасия с её молотком в роли плотника как оргзвено, материальные и наличные гвозди, молоток и доски – ресурсы, без доступности которых выполнение работы/сервиса оргзвена Анастасии невозможно.

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

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

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

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

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

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

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

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

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

• Как на конструктивные объекты, и видит их как оргзвенья, выполняющие работы

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

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

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

Вот примерный жизненный цикл гвоздя, работы «кейса гвоздя»:

• Обнаружение потребности в гвоздевом соединении (гвоздь запланирован – но так пишут реже, ведь это указание на работу, а не на гвоздь! Состояние «гвоздь запланирован» тут указывает на результат выполнения инженерами сервиса по формированию сводно-заказной спецификации, которая попала в службу закупок. Писать «гвоздь запланирован», упоминая смену состояния гвоздя как объекта кейса правильней, потому как легче проконтролировать результат работы, но так при документировании жизненного цикла в первом поколении представлений об этом цикле писали редко. Хотя именно так принято описывать основной результат работы в качестве имени работы в методологии управления проектами PRINCE217, это хорошая практика!)

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

• Выдача в монтаж (или гвоздь доступен в месте забивки – указание на работу по выдаче гвоздя в монтаж. Дальше мы просто не будем писать эти разъяснения, идея тут понятна)

• Нацеливание гвоздя (гвоздь нацелен)

• Вколачивание гвоздя (гвоздь вбит)

• Проверка крепости соединения («гвоздь держит крепко», но объект поменялся. Теперь это «соединение». Куколка стала бабочкой! Другой объект, по-другому называем)

• Эксплуатация соединения (соединение держит и стабильно при нагрузках)

• Вытаскивание гвоздя (гвоздь вытащен)

• Ликвидация гвоздя (гвоздь выкинут – жизненный цикл всегда идёт до исчезновения объекта работ).

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