6. Практика управления работами (операционный менеджмент)

Практика управления проектами

Управление работами (операционный менеджмент, логистическое рассмотрение) противопоставляется управлению жизненным циклом как разбирательству с практиками — и подробно разбиралось в курсе «Методология». Там, в частности, было рассказано, что управление жизненным циклом сначала было неотличимо от «грубого управления работами» (где «грубого» — это деление на несколько больших стадий, или этапов, понимаемых как одноуровнево представленные работы системы создания, но обычно не мельче), а дальше появилось управление жизненным циклом 2.0, в котором на первый план вышли практики в их неразрывной связи с работами, которые реализовывали эти практики. И там же рассказывалась история появления в системном движении не только системной инженерии, но и управления проектами. Но дальше «Методология» сосредотачивалась на раскрытии понятия практики, а что происходит в проекте с работами, не обсуждалось. Это и есть водораздел: в управлении жизненным циклом рассматриваются подробно на много уровней декомпозиции практики, но вот работы — только самого верхнего уровня (фазы/стадии — и то в условиях «непрерывного всего» это уже сомнительное рассмотрение работ), а в управлении работами/операционном менеджменте практики рассматриваются главным образом самого управления работами/операционного менеджмента, а работы дробятся на достаточное число уровней.

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

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

Само проектное управление в его классическом виде всех поколений исходит из трёх посылок, и если их нет, то его попросту нельзя использовать, потому как не будет работать, практики окажутся неприменимы:

• Есть нормы производительности труда, то есть можно как-то планировать продолжительность работ (скажем, в строительстве кирпичных домов для кирпича есть норма, сколько каменщик укладывает кирпичей в час — и на эту оценку можно как-то опираться).

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

• Заранее известна последовательность работ (up front plan), в том числе это означает, что заранее известен состав системы (ибо план получают из того, что для каждой части системы планируют работы по её проектированию, изготовлению, логистике к месту сборки/монтажа, сборке/монтажу, испытаниям).

Если внимательно приглядеться, то это всё будет работать или на заводском машиностроительном производстве/manufacturing под заказ (без работы конструкторского бюро! Только производство!), или на стройке на стадии именно «строительство» (но не стадии проектирования). Везде, где есть хоть какие-то неопределённости (скажем, в умственной работе не установишь норму на решение проблем, типа «полторы проблемы в сутки», или в условиях выдвижения и критики гипотез не скажешь заранее последовательность их выдвижения и критики, включая экспериментальные проверки, то есть нет «плана работ по изобретению системы»), классическое проектное управление не работает.

Само это классическое проектное управление прошло несколько поколений, сейчас мы наблюдаем четвёртое (которое по большому счёту уже не очень классическое именно «проектное управление», смысл понятия поменялся):

Первое поколение говорило только то, что есть отдельные работы, которые хитро связаны друг с другом (представляются какой-то сетью/network), и их нужно как-то выполнить ограниченным ресурсом за минимальное время — представить график. Метод получил русскоязычное название «сетевое планирование» (основной объект там — «сетевой график»¹, отражающий зависимость работ друг от друга), по-английски получил распространение как Program (Project) Evaluation and Review Technique, или PERT². Суть этой техники в том, что находился критический путь/critical path как собранная от начала работ до конца проекта самая длинная цепочка работ, которые нельзя начинать раньше, чем закончится предыдущая работа по цепочке. Если сократить длительность работ в этой цепочке (скажем, не допускать пауз при переходе от одной работы в цепочке к другой работе), это автоматически уменьшало время работ по проекту, или хотя бы давало какую-то предсказуемость времени ожидаемого окончания работ.

Второе поколение родилось, когда появилось понятие процесса как повторяемого паттерна работ (по факту речь шла о практиках). Процесс считался реализацией какой-то практики, и всё стали изображать как базовые единицы-процессы. Процессы рассматривались как commodities³ (базовые товары на товарно-сырьевой бирже, типа зерна или нефти: качественные различия мало волнуют, поставщики мало волнуют, одна партия легко заменяется другой партией). Проект же во втором поколении рассматривался как нечто уникальное, составленное из более-менее похожих процессов. Скажем, процессы «открытие проекта», «планирование работ», «ведение работ» не уникальны (они определяются практикой проектного управления, которая будет одинакова, где бы она ни применялась — хоть в проектах выращивания арбузов, хоть в проектах производства кремниевых микросхем). Но вот сами работы, которые по ним ведутся, в совокупности уникальные — это и будет «проект». Появилось множество самых разных практик второго поколения управления проектами как отдельной дисциплины: Project Management body of Knowledge (PMBoK)⁴ от PMI (Project Management Institute), PRojects IN Controlled Environments (PRINCE2)⁵ и многие другие.

Проблем с этим вторым поколением было две:

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

• Запланировать заранее работы вообще невозможно, ибо в жизнь врывается «непрерывное всё». В жизни это называлось agile. То есть ты вроде как должен планировать, но в первый момент проекта абсолютно непонятно, что же именно планировать, а за изменение планов тебя бьют — но оно же неминуемо! Поэтому жизнь происходила одним образом, а отчётность по проектам была абсолютно другой, «глянцевой». Планы составлялись бессодержательные, типа «первый этап», «второй этап», «третий этап», а что там за работы в них были и почему они столько стоят и столько длятся — это обсуждать было невозможно.

Ответом было появление систем проектного управления третьего поколения, где «проект» оказывался более-менее элементарной работой (хотя и сложно устроенной), а на передний план выходило понятие программы проектов⁶ как совокупности всех проектов, возможно ещё не начатых. Можно долго обсуждать, чем портфель проектов как совокупность всех проектов отличается от программы⁷, но понятие портфеля проектов попросту отсылает к отдельным проектам, лежащим в портфеле (оно вполне присутствовало и в первом поколении проектного управления). А вот программа работ особо напирала на то, что очередные проекты в программе появляются по мере осознания в них необходимости, а уже появившиеся проекты пересекаются по ресурсам, параллельны по времени, а также все могут быть оптимизированы под понятный результат программы. И, конечно, все эти рассуждения сильно затуманивались тем, что во втором поколении проектного управления менеджмент весь в целом и менеджмент проекта по факту отождествлялись: если взять руководителя проекта и директора фирмы, то сразу и не поймёшь, чем они различаются — оба должны вроде как быть лидерами, организовать вверенные им коллективы, вести переговоры с контрагентами, следить за финансами и т.д. Суть «управления работами» оказалась существенно размыта в общеменеджерских рассуждениях.

В третьем поколении классического проектного подхода была сделана попытка преодоления замеченных проблем. Основным объектом проектного управления стал не проект, а программа проектов (производственная программа, программа развития и т.д.), частями которой стали проекты. Управление проектами (уже объявленными) осуществлялось в рамках перераспределения ресурсов во всём текущем портфеле проектов (то есть уже известных проектов), но смысл «программности» был в том, что по мере осознания того, что нужно делать для достижения целей программы, формулировались и запускались новые проекты программами. Это получило название управления программами, в котором с одной стороны нужно вовремя запускать новые проекты::работы, чтобы двигаться к объявленным целям программы (выполнять миссию достижения видения, где отдельные шаги ещё не известны и будут определяться по мере продвижения в выполнении миссии), а с другой стороны, как можно быстрее выполнять на ограниченном множестве ресурсов те проекты::работы, которые уже известны на данный момент. Так сказать, оптимизировать известное, пытаясь оптимизировать ещё и неизвестное. К этому классу методик проектного управления третьего поколения относились популярное в Японии Program and Project Management (P2M)⁸, проектное управление из теории ограничений (TOC)⁹.

Основное, что было выявлено в ходе всех этих попыток сформулировать проектное управление:

Важнейшим является управление потоками работ через какие-то рабочие станции. Ресурсами тут будут сырьё и промежуточные материалы, но и сами рабочие станции. Задача проектного управляющего в том, чтобы убирать ограничения в производительности. Логисты (в supply chain), проектные управляющие — это всё одно и то же в части моделирования происходящего, ключевой объект — поток/flow, который течёт по сети рабочих станций/ресурсов.

Рассматривать приходится сразу все потоки работ, ибо оптимизировать один поток работ (проект) так, чтобы не ухудшить при этом протекание всех потоков работ (производственную программу) невозможно. «Оптимизировать» тут сводится к выполнению чисто арифметической задачи: какие работы в какой последовательности поручать выполнять рабочим станциям. Арифметика решает всё, и она контринтуитивна. В каждой производственной сети есть ограничение на общее время выполнения работ, и оно зависит не только от последовательности работ (первое и второе поколение проектного подхода — в них упор делался на метод критического пути/critical path), но и от наличия ресурсов, которые доступны (метод критического ресурсного пути/critical resource path/критической цепи/critical chain). В случае, когда для многих проектов у нас одни и те же ресурсы (множество проектов идёт через одних и тех же людей), практически бесполезно стало говорить о критических путях — ибо всё уже решали не длительности работ, а доступность ресурсов, которые разрывались по разным проектам.

Самое контринтуитивное тут — это понять, что арифметика решает всё. Без рационального понимания того, что порядок выполнения работ на множестве ресурсов крайне важен, невозможно управлять проектами.

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

Если бы было три Васи, то все работы закончились бы на тридцатый день. Но Вася один. У нас есть самые разные варианты того, как загрузить Васю работой.

Первый вариант «бесчеловечный», основан на чистой арифметике: Васе говорим, что он не имеет права заниматься ничем другим, пока не сделает работу MX для одного проекта, потом для другого, потом для третьего. Относимся к Васе как к станку! Дальше никаких чудес: первый клиент получает результаты через тридцать дней, второй через сорок, третий через пятьдесят дней. Это обсуждается обычно в управлении процессами, и там в основе теория массового обслуживания/теория очередей¹⁰ и исследование операций¹¹. Упор на то, что работа MX признаётся одинаковой, и всё это описывается как процесс MX с тремя экземплярами работ. Дальше математика потока работ через ресурс Васю. Проблемы появляются в тот момент, когда выясняется, что кроме одинаковых работ у Васи есть куча самых разных других работ, которые все разные у разных исполнителей. Процессное управление тут говорит «если всё такое неодинаковое, то это к проектному управлению, но наш одинаковый кусок у Васи мы бы обрабатывали именно так, относясь к Васе как к станку». В теории массового обслуживания это абсолютно нормально, там есть расхожий анекдот про общность постановки задачи в самых разных ситуациях процессного управления: «к городу подлетает эскадрилья бомбардировщиков, становясь в очередь на обслуживание зенитной батареей».

Второй вариант начинается как раз с замечанием, что «если у вас всё уникальное, то используйте управление проектами». Управление проектами заболело теориями, что весь менеджмент (включая организационное развитие, лидерство и сейчас даже обсуждается вопрос, что практика ведения переговоров — вот буквально всё, чем занимаются люди на работе) это предмет проектного управления. Поэтому Вася для современных проектных управляющих — это не ресурс. Ему поручают одновременно все проекты, и предупреждают, что строго спросят за все три. Типовая ситуация многозадачности: Вася понимает, что ему и впрямь нужно будет отчитываться за все три проекта. И он в первый день делает по 1/3 дневной нормы от каждого проекта. Через три дня у Васи выполнено работ по каждому проекту на 1 день (чудес не бывает!), всего Вася трудился три дня, все работы готовы на 10%. Директор звонит и интересуется, приступил ли Вася к работе. Вася отвечает, что «да, движение по всем проектам». На рисунке работа Васи показана как сплошная зелёная линия «занимается проектом». Но в реальности каждая из этих линий будет пунктирна: один такт работы по проекту, два такта работы нет (ибо идёт работа Васи по двум другим проектам). На двадцатый день после попадания всех трёх работ к Васе директор не выдерживает (его поджимают клиенты!) и звонит Васе. Вася честно говорит, что все три проекта существенно продвинулись, на две трети всё готово! Помним, что в предыдущем варианте Васи-станка первый клиент к этому моменту (тридцатый день) получил результат своего проекта, а работа по второму как раз у Васи закончилась. А в этом случае «много проектов, и за все спрос» вроде как Вася не простаивал, третий клиент всё одно ничего не получил, но и первый клиент не получил. В последний тридцатый день Вася как «человек с порученными ему работами многих проектов» отдаёт работы дальше по цепочке, и все три клиента остаются несчастливы, хотя в случае васи-как-станка два клиента счастливы в этот момент, а остальные только несчастливы. Тем самым случай реализует «справедливость» как равномерное распределение несчастья: третий клиент получал работу в первом случае на пятидесятый день (ему не везло одному), а в случае Васи, нагруженного многими проектами с обязательством «продвигаться по всем» все три клиента оказываются «справедливо» в одинаковом положении, они несчастливы в равной степени, счастливых нет. И при этом мы ещё считаем, что время переключения Васи с работы на работу равно нулю! В жизни это никогда не ноль, это время переключения добавляется к каждому такту каждой работы!

Есть ли пути улучшения этой ситуации? Да, есть. Нужно только заметить, что «одинаковая работа» всё-таки занимает обычно разное время, но чаще всего ровно столько, сколько запланировано (бывает, что позже, но никогда не раньше). Если учесть статистику опозданий и запланировать работу с риском неокончания её в этот укороченный срок, то можно запланировать половину времени на работу, а половину времени поместить в «буфер неокончания в запланированное время» в конце проекта. Если спросить Васю, сколько он будет делать MX, то Вася ответит 10 дней — ибо считает, что это будет с вероятностью 99%. И он таки потратит все десять дней! Но если ему дать на работу 8 дней, то он её завершит с вероятностью, скажем, 90% именно в этот срок — просто он для надёжности добавляет дни в своей оценке). Если сделать это «укорочение плана исходя из оценки 90% вероятности» с каждой работой, то можно рассчитывать на тот же эффект, который используется в страховых компаниях: проблемы будут не у всех работ, поэтому в реальности буфер можно делать меньшей длины. На диаграмме показано, что вот этот вариант с буферизацией за счёт учёта разницы во времени актуального выполнения работ по сравнению с запланированным может сэкономить ещё пять дней даже при использовании всего буфера проекта — и первый клиент получит результат через двадцать пять дней, а не через тридцать дней. Но буфер совсем не обязательно будет использован весь, поэтому в реальности результат может быть получен и на двадцатый день!

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

Практики управления процессами и управления кейсами

В начале 21 века позиции проектного управления были существенно подвинуты сторонниками процессного управления, которое главным образом развивалось в среде «автоматизаторов» (айтишников). Увы, из этой истории тоже ничего хорошего не получилось. Вот пример описания простейшего «процесса» похода к доктору, который выписывает рецепт к врачу, это выдержка из стандарта Business Process Model and Notation (BPMN) 2.0¹²:

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

Итого: управление процессами для целей операционного менеджмента «не пошло», оно помогало айтишникам что-то автоматизировать, но для работы с людьми по части управления порядком загрузки ресурсов (а мы только что убедились, что этот порядок важен для минимизации сроков выполнения проектов, «чистая арифметика» важна) оказывалось не очень пригодно. По факту «процесс» стало синонимом слову «практика» (труд, деятельность), а «работа» по этой практике — это «экземпляр процесса». С экземплярами процесса предмет (дисциплина из учебников) процессного управления не работал, отсылая к предметам дисциплин теории массового обслуживания/теории очередей и исследования операций. Но для «процесса заключения договора» в софте процессного управления всегда можно было найти, что происходит с каждым конкретным договором. Учебники управления (организационными) процессами/business-process management не рассказывали про то, что и как делать с «экземплярами», но софт работу с экземплярами поддерживал. Так что «управление процессами» по факту оказалось инженерной (про содержание работ, про практики), а не менеджерской (про логистику, про работы) практикой.

Засилье процессного подхода кончилось в одночасье:

• Всё процессное автоматизируется и перестаёт называться «процессом» (и даже «автоматизацией»: при автоматизации часто меняется суть работы, одна практика заменяется совсем другой, управлять нужно уже совсем другим набором работ)

• «Процессом» называют всё что ни попадя, но кроме названия там уже мало что остаётся от классической пошаговости¹⁴. Это только кажется, что у людей в головах именно «процессы». В головах у них «практики», BoK вместо «пошаговых расписаний». Процессом также часто называют и вид жизненного цикла в целом (agile process, engineering process).

• Упор на рабочие продукты (case management, issue tracking), облегчает договорённости — это отсылка к 4D, об этом мы расскажем чуть подробней ниже.

• Практики мы описываем не как огромные методологии, в которых чётко прописаны длинные сценарии, а как отдельные короткие элементы практик, из которых можно по обстоятельствам собирать длинные цепочки — гранулярность обеспечивает ситуационная инженерия методов, которая рассказывает нам, из каких элементов состоят практики (всё это крутится вокруг альф, изменения состояния альф и т.д.). Акцент поэтому оказался не на собственно «процессах» как длинных цепочках (иногда это «маршруты» и обсуждается маршрутизация/routing, иногда это обсуждается как «сценарии», иногда как поток работ/workflow, то есть работы, идущие/flow через людей и компьютеры), а на инструментарии описания коротеньких процессов из их элементарных частей.

• Декларативность (правила пред- и постусловий, а не указание последовательности), то есть длинные описания сценариев не существуют. Просто из какой-то библиотеки элементов кейсов последовательность работ собирается путём подбора нужных по предусловиям. Появился OMG CMMN (Case Management Model and Notation)¹⁵ в дополнение к процедурному BPMN 2.0 как поддерживающий это язык, но он не получил распространения, декларативное программирование очень удобно для разных описаний, но очень тяжело в понимании (в классическом программировании «все хотят писать декларативно¹⁶ — функционально или на логическом языке, но получается всё равно императивно» — с составлением длинных цепочек работ то же самое, «все хотят описывать их функционально или логически, но получается императивно», в процессном управлении приняты императивные описания «шагов программы/шагов работ»). Так же не получил большого распространения механизм декларативного описания организационных норм/business rules¹⁷, не стали популярными реализующие его стандарты OMG SBVR¹⁸ и привязанный к стандартам описания процессов OMG CMMN (декларативный) и OMG BPMN (императивный) стандарт описания принятия решений в ходе выполнения работ OMG DMN¹⁹.

А что там с практиками в проектном управлении, как там работают с «одинаковым» в предметной области? Там ровно наоборот: всё про работы и их уникальную логистику в части «экземпляров» применения практик, и намеренный уход от любого обсуждения «типовых работ» (хотя понятие «процесс» как практика используется, начиная со второго поколения — но только для процессов проектного управления, а не для процессов самого проекта, ибо «какие такие процессы? У нас всё уникально, у нас экземпляры!». В процессном управлении невозможно поставить даты выполнения работ, а проектном управлении невозможно завести работу без даты. Но поскольку практики и связанные с ними работы таки существуют, софт (но не учебники!) проектного управления поддерживает «шаблоны проектов». И даже если простейший софт (например, MS Project) не поддерживает, то мало кто начинает работу над планированием нового проекта с пустого разбиения работ. По нормам проектного управления разбиение работ обязано содержать даты начала каждой работы и ресурсы на её выполнение, поэтому невозможно иметь разбиение работ без привязки ко времени (такое описание будет, скорее, описанием практики, «описание процесса::практика работы::работа»), но в жизни просто берут предыдущее описание проекта с проставленными датами начала и конца работ, и чуть-чуть редактируют состав работ (или даже не редактируют), а вместо старых дат ставят новые. Так что «шаблона проекта» вроде бы нет (каждый проект уникален!), но по факту он есть.

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

В ответ на все эти сложности и в проектном, и в процессном управлении родился ещё один подход, который по факту стал центральным/mainstream (пару раз поменяв при этом название): управление кейсами/ведение дел/case management. Сам этот подход появился из лечебных дел/case и судебных дел/case и тесно связан в его понимании как «папки Дело №___» или «папки истории болезни» (папка дела/case file).

Внимание для всех практик и работ в управлении кейсами удерживалось тем, что какой-то объект (предмет дела/кейса), который нужно было перевести из начального в конечное состояние становился точкой сборки. Это как vision в стратегировании определяет разные варианты mission и допускает разные работы по его получению, это как программа проектов должна достичь целей программы, а уж проекты в её составе могут быть самыми разными для достижения целей. Тем самым постулировалось, что «прибыть из точки А в точку Б можно огромным числом способов, работы могут быть разными, а вот закончиться они должны одинаково: прибытием в точку Б». При этом цель задавалась как vision (состояние мира), но сам кейс был mission, и тип кейса — даже не «практика», а «работа» (кейсы уникальны, если не уникальны, то это «шаблоны»). Запомнили: кейс::работа, «шаблон кейса»::практика.

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

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

Софт для такого отслеживания/tracking называется трекерами. Каждый кейс может быть назван проблемой/issue, поэтому софт этот — issue trackers (bug tracker, incident tracker и т.д.). Главное, что в трекере up front планирование вроде как не поддерживается отсутствует (непонятно, когда что будет делаться), но зато поддерживается up front «шаблонирование», в том числе если понятна грубо цепочка/маршрут, по которому должны будут пройти работы какого-то типа (работы по какой-то практике), то это можно заранее тоже записать в шаблоне. Но можно и без шаблона — записать просто для учёта/отслеживания. Помним, что очередной кандидат на пятое обязательное описание — это WBS, work breakdown structure (по факту это описание работ создателя). Это вот то же самое: попытка описать конфигурацию текущих работ, отследить возможный «развал конфигурации» (работы не имеют предмета работ, работы идут с игнорированием SoTA практики работ, работы идут по пять штук одинаковых над одним предметом работ, все ресурсы/исполнители назначены не на самые нужные работы и т.д.), но в case management разрешается планирование работы делать прямо перед её выполнением.

Тем самым issue trackers работ обычно идут в связке с репозиторием версий предмета кейсов (помним, что у каждой работы есть её основной предмет), но issues появляются там или up front (например, я заранее знаю, что ошибки будут, и делаю шаблон работ по исправлению ошибки, то есть прописываю практику, по которой будет порождена работа в момент появления экземпляра ошибки), или вот прямо после понимания, что какая-то работа должна быть сделана в ситуации, которую никто не предполагал (кейс «убрать царапину неизвестного происхождения, которая появилась на корпусе прибора вчера ночью»). Кейс таким образом проходит самые разные состояния, например: issue («непонятно, что делать и с чем, но vision есть — чтобы на корпусе не было царапины»), далее это становится task::«работа из проектного управления, которая понятно по какой практике делается, и понятно когда и кем» (mission — закрасить царапину и заполировать, делает Женя как самое срочное дело), но затем ещё и обязательно notice (мир изменился, и всех заинтересованных в его изменении надо оповестить об этом — этот шаг нельзя пропускать).

Итак, к программам проектного управления (диаграмма Гантта на экране и часами идущее «планирование» перед «выполнением плана работ») добавились программы процессного управления (заполнение формочек параметров экземпляра процесса по заранее подготовленным моделям процессов, если речь идёт о людях, но это может быть и полностью автоматизировано — тогда ничего заполнять не надо, но «процесс идёт хорошо, экземпляры процесса порождаются автоматически»), добавилось управление кейсами, где и практики (шаблоны кейсов) и работы (сами кейсы), и возможно upfront планирование, и возможно планирование работ, ведущихся «открывающимися обстоятельствами дела» и дальше не столько планирование и отслеживание выполнения плана, сколько отслеживание/tracking хода работ (ибо плана-то нет, разве что «шаблоны», где они осознанны и документированы).

Управление программами тем самым — это такое управление кейсами, где работа-проект планируется непосредственно перед её выполнением, но для неё не говорится о практике (шаблоне), ибо вроде как для проектов не должно быть какой-то повторяемости. Управление кейсами оказалось всеохватным, при этом чтобы как-то отстроиться от чисто медицинских «историй болезни» и судебных «дел», это всеохватное управление кейсами начало себя называть как динамическое/dynamic управление кейсами, адаптивное/adaptive управление кейсами (самое популярное), были и другие модификаторы названия.

В реальности в каждом большом проекте можно встретить какие-то его части, которые были сделаны согласно требованиям какой-то из школ управления. Хорошим примером тут был случай зимней олимпиады 2014 года в Сочи, где в управлении было примерно 5000 кейсов от строительства (внутри эти кейсы велись программами проектного управления), примерно 5000 кейсов пришли от системы управления качеством собственно Олимпиады (выполнение требований Олимпийского комитета) и ещё примерно 5000 кейсов пришли в качестве поручений от первых-вторых лиц государства. Тем самым под управление российской командой организации олимпиады попало примерно 15 тысяч кейсов²⁰. Поскольку в самом начале работ было непонятно, что это за такой странный объект у них в управлении (кейс-менеджмент не рассматривался, ибо на слуху у всех было «проект» и люди хотели получать премии за выполнение проектов), то примерно 35 человек из Microsoft написали специальный софт для сопровождения этого винегрета «проектов на контроле». Терминология использовалась проектного управления, но перед самым стартом Олимпиады люди сообразили, что это кейс-менеджмент! И появилась идея по-быстрому перегрузить все 15 тысяч кейсов в простую программу issue tracker (предлагался open source Redmine²¹, тем более что он позиционировался не как issue tracker, а как «flexible project management web application»). Этого не случилось, поскольку эти идеи появились буквально за три недели до старта Олимпиады, и просто испугались каких-то потерь данных при переливе информации по 15 тысячам кейсов плюс какому-то переучиванию людей команды. Решили, что «продержимся ещё три недели, потом Олимпиада — и всё, конец истории». Но если бы люди понимали суть управления кейсами, то жизнь их была бы проще!

Управление кейсами потребовало не только отдельной идеологии, но и отдельных программ (простые issue trackers явно не учитывали полноценного варианта case management в части адаптивности, которая понималась как «шаблоны готовят непрограммисты») — а поскольку выяснилось, что эти программы решают огромное количество проблем, то они были выпущены и стоили баснословные деньги. Это всё случилось как раз в 2013-2015 году, и потом идеи адаптивного управления кейсами исчезли под этим названием, но не исчезли из жизни:

• Большинство issue trackers были переименованы в «программы управления проектами», хотя помним, что они появились сначала по линии процессного управления, ибо «шаблоны кейсов» были по факту описанием практик! Но процессное управление «про практики», а работами-проектами надо было управлять, поэтому победило слово «проектное управление», но оно оказалось не тем, что в классическом проектном управлении, совсем другое body of knowledge! С другой стороны, чтобы быть более похожими на программы проектного управления кейсы могли быть представлены на верхнем уровне в современных программах в виде диаграмм Гантта!

• Появились универсальные табличные моделеры (notion.so, coda.io и прочие), которые хорошо подходили под идеи LowCode и NoCode. Это LowCode формулировалось как «непрограммисты могут написать какие-то простейшие процессы/workflow», то есть код, поддерживающий отслеживание/tracking работ по какому-то шаблону. Но это как раз совпадало с тем, о чём говорилось в adaptive case management. Дорогие специализированные программы управления кейсами массово начали отпадать, и прототипирование работы с шаблонами кейсов массово перешло в это универсальное моделирование. Но если кейсы по каким-то шаблонам оказывались реально массовыми, или оказывались кейсами не изменений в реальном виде, а кейсами обработки информации, то это просто переносилось в специализированный «процессный софт».

Итак, у нас есть несколько разных методов управления работами: управление проектами (классическое), управление программами, управление процессами, управление кейсами. Как определить, для Васи, исполняющего какую-то практику MX (например, приготовления кофе с молоком с использованием кофе-машины для Клавдии, практика эта разбиралась в курсе «Методология») — это программа, проект, процесс или кейс?! Мы довольно быстро договоримся, что результатом там должна быть чашка капучино в состоянии «сервировано у Клавдии» (ибо надо будет учесть и особенности подачи — все эти блюдца, салфеточки, опциональный сахар и ложечку). Но ведь тренированный специалист и напишет, и обоснует это всё как проект (в PRINCE2 как раз в названиях работ и проектов рекомендуют писать их результат, это близко к кейсам, где кейс тоже называют по предметам кейса). Примерно так же можно обосновать, что это процесс, и что это кейс! Напомним, что основные критерии там — это «работа будет повторяться по шаблону много раз» или «нет, работа уникальная одноразовая, никакого шаблона». Но дальше в софте обязательно оказывается, что поддерживается и одно, и другое (понятно, что нужно и практику поддержать, и экземпляры задействования практики — работы). Вот тут «что только в софте» показано пунктиром, а что «в учебнике дисциплины» показано сплошным контуром:

Тут важно, что вопрос из предыдущего абзаца задан некорректно. Для этого вернёмся к 4D представлению мира:

• Вот Вася готовит капучино для Клавдии в реальном мире, прямо в физическом мире, в 4D (то есть он, кофе, молоко, кофе-машина, чашка и т.д. занимают пространство-время), он работает.

• А вот Илья, имеющий знания по проектному управлению, описывает это как проект (каждая чашка кофе уникальна, каждый посетитель требует что-то своё! Это неважно, что эти проекты похожи: в учебниках этого нет, но просто задействуем софт проектного управления достаточно мощный, чтобы в нём был «шаблон проекта». При этом помним, что в проектах есть подпроекты, а проекты получаются из программ. Так что берём программу «сделать Клавдию довольной», порождаем проект «напоить капучино», там внутри, конечно, подпроекты приготовления кофе, капучинирования, подачи. Можно хорошо описывать разделение труда, привлечь Петю для капучинирования!). Получается, что работа сама происходит в 4D уж как происходит, но она описана как проект! Проектное управление в его классическом варианте — это метод описания, viewpoint, а описание — это всего лишь view на работу, а не сама работа! Правильно говорить не «работа Васи — это проект», а «работа Васи описана/классифицирована как проект»!

• То же рассуждение для Ольги, имеющей знания по процессному управлению, она описывает это как процесс. Не будем расписывать подробно. Работа в физическом мире, но она будет описана как процесс, это только одно из возможных описаний.

• И Крис, который только-только узнал об управлении кейсами, он опишет эту работу Васи как кейс — но это никак не помешает существовать описаниям Ильи этой работы как проекта (и даже программы работ!), и описанию Ольги как процесса, и описанию Криса как кейса.

Нет «на самом деле» проектов, процессов, кейсов! Это всё разные акценты моделирования одной и той же реальности живой работы (а хоть и будущей, у нас 4D).

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

Каждый вариант нарезки мира работ по факту ведёт к выбору софта, который хорошо поддерживает ответы на какие-то определённые вопросы:

• Проектное управление (графики работ и задействования ресурсов — отвечает на вопрос «когда кто что должен делать»? И помним, что без нормирования работ, учёта ресурсов, возможности знать все работы до начала проекта — не работает, ответа на вопрос не будет!)

• Теория массового обслуживания (потоки и очереди — переварим всё однородное за минимальное время! Сколько надо иметь ресурсов, чтобы мы справились? Но нет ответов на вопрос «когда и кто будет делать», это всё «в рабочем порядке»)

• Процессный подход в смысле BPMN (кто что должен делать, но вот когда — непонятно, «когда работа будет готова»)

• Адаптивное ведение дел/case management/«отслеживание/tracking проблем/issue, багов/bugs, происшествий/incident» и дальше разные варианты Workflow с LowCode и даже NoCode (тут обычно agile/шустрость в реакции на непредсказуемое: удерживать во внимании цель, чтобы её достичь, но по какому маршруту пойдут работы, и какие они будут, заранее неведомо. Но мы удержим внимание!)

• Потоки пользы / value networks²² (бизнес, т.е. кому это выгодно). Мы не поминали это, но в некоторых организационных практиках такое описание работ тоже может использоваться — чтобы обнаруживать работы, которые не приносят никакой пользы. В этих сетях указывают оргроли, и кто кому что предоставляет (deliverables) — чтобы на выходе получить итоговую систему, дающую пользу. Но легко представить, что речь идёт о работах, которые надо выполнить, чтобы получить эти deliverables.

Так что мы рекомендуем:

• Где можно, используйте кейс-менеджмент, ибо там наиболее общее описание работ. Объявляйте альфы как объекты внимания в проекте кейсами, описывайте их состояния, формулируйте для этого контрольные вопросы, добивайтесь ответов на контрольные вопросы путём выполнения работ, которые ведутся по каким-то практикам. Всё это моделирование записывайте в табличном формате, или используйте какой-то подходящий софт (например, PLM-систему, если речь идёт о машиностроении или стройке).

• Смело смешивайте любые описания, если вам нужны какие-то ответы на вопросы, или решение каких-то проблем. Например, смело называйте кейс проектом, или даже программой. И задействуйте issue trackers, которые сейчас тоже называются софтом управления проектами (хотя этот софт совсем не похож на софт классического управления проектами). На верхней паре уровней декомпозиции кейсов на подкейсы огромного проекта говорите «директивный график» и переходите на язык классического управления проектами (ибо там будут «директивные сроки», которые даже не прогнозные, а предписанные по интуитивным оценкам дедлайны, конкретные даты). Вас поймут все менеджеры. А ниже переходите на язык разговора о кейсах и отслеживания/tracking проблем/issues, только часть из которых известна upfront/перед началом работ — и вас будут понимать все разработчики, архитекторы и инженеры платформы/DevOps/internal development platform engineers. Общий принцип: с менеджерами старой закалки говорите на языке классического управления, это будет ласкать им слух (даже в случае работ по разработке, к чему категорически проектное управление противопоказано), а с инженерами «от сохи» говорите на языке управления кейсами.

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

• Все неожиданности (включая обнаружение и исправление ошибок, а также выдача поручений начальством «из ниоткуда») должны рассматриваться как кейсы, иначе запутаетесь.

TEST Проекты, программы, процессы, кейсы

!!! Серафима на заседании настаивает, что выполнение договора по высадке 100 деревьев в парке — это процесс. Дженнифер утверждает, что это кейс. Нуржигит говорит, что это проект. Кто прав?

--- Серафима, ибо 100 деревьев это точно что-то повторяющееся. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как процесс. Процесс — это только одно из возможных описаний/view этих работ.

--- Дженнифер, ибо непонятно, что мы встретим в выполнении этих 100 работ как целого, и работ по высадке отдельных деревьев. Да, там будет что-то повторяться, так это просто шаблон кейса. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как кейс с подкейсами. Кейс — это только одно из возможных описаний/view этих работ.

--- Нуржигит, ибо это совершенно уникальные работы в уникальном месте с уникальными условиями, и мы хорошо понимаем, сколько примерно времени займёт высадка одного дерева, можно говорить о нормировании работ. ### Нет, выполнение договора — это выполнение договора, хотя можно рассмотреть его как проект. Проект — это только одно из возможных описаний/view этих работ.

+++ Все ошибаются. Выполнение работ — это выполнение работ, изменения в физическом мире, само по себе выполнение работ не есть «процесс», или «проект», или «кейс». ### Да, мы какие-то работы можем описать как процесс, проект, или кейс. Это не означает, что сами работы вдруг стали процессом, проектом, кейсом, программой.

+++ Все неправы, но они могут продолжать думать и действовать в соответствии со своими убеждениями, учитывая разные особенности ведения работ по этому договору. ### Да, выполнение работ по договору — это действия в физическом мире, но думать о них можно по-разному.

!!! Можно ли одновременно использовать разные методы управления работами?

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

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

!!! Когда говорят «процесс проектного управления», что имеют в виду?

--- последовательность шагов процедуры/алгоритма, по которому идёт управления проектом (сначала открыть проект, потом запланировать работы, после этого начать работы и следить за выполнением плана и т.д.). ### Нет, слово «процесс» давно уже не относят именно к шагам, чаще всего оно означает «практику» или даже «метод». Хотя и могут говорить о практике открытия проекта, практике планирования работ, но это не последовательность шагов — это именно практики.

+++ просто это практики проектного управления, «процесс» тут синоним «практики» ### Да, это наиболее вероятно. «Процесс» как развёртка чего-то во времени уже редко используется в менеджменте, чаще в инженерии. Хотя «процессное управление» ещё работает с шагами процесса.

!!! Вам нужно выбрать софт для управления работами в вашей компании. Вы ожидаете, что будет довольно много работ по разработке, плюс придётся время от времени управлять муторными однообразными процедурами тестирования оборудования, а ещё обрабатывать мелкие поручения клиентов, вечно чем-то недовольных. Феликс предложил для управления работами использовать софт проектного управления, хотя бы входящий в MS Office Microsoft Project, ибо такой софт предназначен как раз для управления работами! Лидия предложила купить софт управления процессами, ибо процесс разработки, процесс тестирования, процесс выполнения поручений клиентов — это всё бизнес-процессы, а в этом софте есть и BPMN, можно написать это всё на языке Business Process Model and Notation. Виталия предложила использовать issue tracker, который используют программисты и системные администраторы компании: просто начать использовать его ещё и для всех некомпьютерных работ. Чьей рекомендации нужно последовать?

--- Феликса. ### Нет, проектное управление тут вряд ли пригодится, ибо речь идёт об управлении разработкой, и управлении поручениями, работы в них предварительно не запланируешь.

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

+++ Виталии. ### Да, вполне можно приспособить issue tracker для управления работами, если там есть разработка и выполнение поручений. И можно даже использовать issue tracker для работы с чеклистами при выполнении «муторных однообразных процедур тестирования», а то и автоматизировать их (скриптование каких-то «процессов» есть в большинстве issue trackers, хотя необязательно на языке BPMN).

--- никого из них, каждый как-то сам приспособится. ### Нет, всё-таки придётся развернуть софт управления работами, иначе не будет удаваться согласовывать деление времени сотрудников между самыми разными проектами.

--- будем вести обычные протоколы на совещаниях по управлению работами, никакого софта, софт — это лишние хлопоты по его разворачиванию и поддержанию в актуальном состоянии. А протоколы — это классика, она вечно живая! ### Нет, протоколы непригодны для дел, которые не успеваются выполниться за неделю. В даже небольших программных проектах, например, проходит от 6 тысяч работ: какие протоколы переварят это количество? А ведь ни одну из них нельзя пропустить! Так что нужно от протоколов всё равно переходить к софту управления работами.

!!! К вам пришёл Гарегин, которому вы поручили на предыдущих трёх совещаниях 15 дел, а ещё до этого у него уже было недовыполненных 8 дел (всего ему поручили 23 дела). Каждое дело небольшое, на несколько часов или максимум на пару дней. Вы понимаете, что месяца на них всех вполне должно хватить. Гарегин рассказывает, что тратит на выполнение каждого дела примерно по 20 минут в день, иначе он не может гарантировать, что хоть как-то движутся все порученные ему вами дела. Что он делает не так?

+++ допускает мультитаскинг, занимается каждым делом слишком мало. ### Да, мультитаскинг с малым временем выполнения каждой работы приводит к обманчивому впечатлению, что «все дела идут». На самом деле «все дела стоят», ибо они бо́льшую часть времени будут в состоянии «не закончены». При таком подходе большинство дел будут выполнены позже, чем если их просто выполнять подряд целиком.

--- он всё правильно делает, это типичная ведь ситуация! ### Нет, он делает неправильно. Он задерживает те работы, которые могли бы быть выполнены быстро, если бы ими занимались достаточное время. А так большинство работ перейдёт из состояния «работы идут» в «выполнено» намного позже, чем если бы они выполнялись последовательно. Последние работы всё равно будут выполнены ближе к концу месяца, но результаты первых выполненных работ к этому моменту будут уже месяц как доступны!

Упражнение

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

«Распожаризация» и управление работами

Главное — это понимать, что операционный менеджмент в конечном итоге сведётся к правильному размещению во времени потока/flow работ (по-русски вместо «потока» говорят «ход», отсюда и неминуемые «шаги», в английском используются разные слова, чтобы подчеркнуть непрерывность и дискретность — поток, работы текут!) по ресурсам-агентам, которые ведут эти работы. Так что организация для управляющего работами/операционного менеджера — это сеть, по которой текут работы, а главный интерес — поднять throughput/«проход» как то, что протекает через сеть ресурсов-агентов, работающих по каким-то практикам, чтобы получить на выходе или товар-продукт, или обработанную чужую целевую систему как «предоставление сервиса». В одну сторону (от поставщиков сырья или исходной информации) текут потоки вещества, информации, работ и вытекают из фирмы к клиентам, а в другую встречным потоком текут деньги, из которых происходит оплата за каждый ресурс, проводящий обработку потока. Поэтому на обложку книги по нашему курсу попал фрагмент дорожной сети, в которой всё запутанно, но пока вроде как всё едет. Тем не менее, в дорожной сети легко образуются «пробки», когда уже никто никуда не едет. На работе это характеризуется «пожарами» и «авралами», когда самые разные люди вдруг обнаруживают, что всё вдруг резко остановилось или вот-вот встанет в масштабах фирмы из-за того, что они что-то не успевают. Как выполнять «распожаризацию»? Понятно ведь, что если автомобильчиков много, то пробки всё равно будут — а уж если всё остановилось, то и убрать пробку быстро нельзя! Будет «непрерывный пожар и аврал», но это совсем не та «непрерывность всего», которую мы хотим!

Тут есть следующие шаги:

1. Нужно выполнить инженерную работу по принципам Lean/элегантности. То есть надо найти то, что можно не делать — и при этом риски что-то ухудшить останутся более-менее приемлемыми. Учтите, что вы сейчас собираетесь резко ускорить работу. Ненужную работу не нужно ускорять, она вредит делу! Поэтому просто перестаньте эту работу делать. Элон Маск как-то сделал замечание, что если вам не приходится возвращать одну из десяти убранных работ, то вы слишком мало убираете ненужных работ: ищите их тщательней! Это инженерная, содержательная работа.

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

3. Дальше устраняем wait time, время пауз в работе. Берётся специфическая точка зрения «изнутри работы», то есть это время, которое объект обработки готов принять работу ресурса над собой, но его не трогают, поскольку ресурсы заняты чем-то другим, или просто не знают, что нужно обрабатывать этот объект. Это терминология подхода TameFlow, которая по большому счёту и отражает современное состояние операционного менеджмента — то, как именно нужно «управлять работами» (помним, что без предыдущих двух пунктов использование этой книги будет вредным! Вы резко ускорите беспорядок! Будет не хаос и пожары на работе, а крайне быстрый хаос и пожары!). Вот это «устранение времени пауз», предотвращение «пробок» в работе, поддержание стабильного скоростного потока — это и есть операционный менеджмент.

4. После того, как вы добились успеха в устранении времени пауз (там очень, очень много нюансов, для их понимания нужно читать специализированные учебники операционного менеджмента, в нашем общем курсе менеджмента мы не сможем об этих нюансах рассказать, но только скажем, какие учебники надо читать), вам нужно опять обратиться к инженерии и заняться уменьшением времени обработки рабочих продуктов на определённых операциях (touch time), которые будут вам даны по итогам предыдущего шага. Важно, что не нужно сокращать время любых производственных операций, а только находящихся на критических местах в потоке работ — вся арифметика для нахождения этих мест вам будет дана на предыдущих шагах. И это опять будет инженерная задача, которая потребует уже решений по существу инженерного вопроса, а не чисто менеджерская задача по распределению работ по ресурсам и учёту выполнения этих работ.

5. Не давайте инерции себя остановить! Вернитесь к пункту 1 и повторите всё с самого начала: выкиньте лишние операции, наладьте управление конфигурацией (операционный учёт), займитесь принятием решений по уменьшению времени пауз в работе, а затем вернитесь к определению тех операций, которые нужно изменить инженерно, чтобы сократить их время.

Упражнение

Опишите от трёх потоков в вашем рабочем проекте.

TEST Управление кейсами

!!! На чём фокусируется кейс?

--- На действиях ### Нет, на действиях фокусируются практики проектного и процессного управления прежде всего.

+++ На предмете, над которым производятся действия ### Да, именно так. Кейс — ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Кейс фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведется постепенно появляющимися обстоятельствами дела.

--- на исполнителях действий с каким-либо предметом ### Нет, на исполнителях действий (акторах/актёрах) фокусируются подходы, обсуждающие организацию команды, это вопрос оргдизайнеров.

--- на уникальности и однократности выполнения кейса ### Нет, дело тут не в уникальности: проект тоже определяется как некоторая уникальная работа, не подразумевающая многократного её исполнения. Уникальность или однократность — плохие критерии выбора метода управления работами.

!!! Почему приложения low code могут не оправдывать ожиданий?

--- они работают очень медленно ### Нет, у них скорость работы не больше и не меньше, чем у любых других приложений.

--- софт low code очень дорогой ### Нет, стоит такой софт очень по-разному, нельзя сказать, что дороже любых других приложений.

+++ хорошо работают на простых демонстрациях с малым числом объектов, но всё равно требуют профессионального программирования для массовой работы (то есть свойство low code не выполняется) ### Да, именно так: заявление, что программисты не нужны, верно только для прототипирования, в массовой эксплуатации всё равно нужны программисты. Но справедливости ради, надо заметить, что огромное число прототипов оказывается достаточным: отнюдь не всеми приложениями пользуются тысячи и тысячи людей, а для нескольких человек LowCode может дать отличные результаты.

+++ они используют визуальные языки описания процессов, которые ужасны при росте объёма программ ### Да, именно так: визуальные языки описания очень хороши и наглядны только для крошечных примеров, демонстрируемых менеджменту в момент покупки. Для сложных программ работает только текстовое представление, профессиональные программисты не пишут на визуальных языках, они «не тянут». В приложениях low code всё равно нужны профессиональные программисты, и они получают при этом неудобный для них инструмент: визуальное программирование.

Упражнение

Заполните табличку, приведя от трёх кейсов и подкейсов вашего рабочего проекта. «Примечание» — если у вас есть сомнения или вопросы, запишите их в эту графу, чтобы не забыть над ними подумать.

Заполните табличку по операционному софту (от трёх приложений), который вы используете в проекте:

Заполните табличку по софту трекинга кейсов/issue tracker, который вы используете для рабочих и личных дел (от трёх, включая списки дел на бумаге и в файлах Ворда):

Основные книги по современному операционному менеджменту

Вот базовая книга по управлению работами: Steve Tendon, «The Book of TameFlow», 2022:

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

• Объясняет, что бесполезно заниматься улучшениями, если только вы не точно знаете, где именно эти улучшения надо делать. Место улучшений нужно вычислить, иначе это просто бесполезные траты времени и ресурсов!

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

• Рассказывает, как правильно порезать работу на части: что должно попасть обязательно в одну работу, а что нужно разложить по разным работам.

• Рассказывает, как операционному менеджеру выжить в условиях множества продуктов, множества проектов, множества команд.

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

Основные идеи, которые лежат в основе менеджерских решений в части операционного управления — это идеи по управлению самыми разными типами потоков (не только потоков работ) из практик:

• сomputer operating systems

• control engineering

• data communications networks

• finance and economics

• information theory

• maneuver warfare

• manufacturing

• operations research

• probability and statistics

• queueing theory

Идеи изо всех этих практик были собраны и относительно популярно (без зубодробительных формул) изложены в книге Donald Reinertsen «The Principles of Product Development Flow», 2011 (по сути — это книга «теории» операционного менеджмента, в то время как предыдущая книга больше была посвящена нормативной практике):

В этой книге в том числе очень чётко объясняется про использование принципов управления потоком при разработке/development, а не при производстве/manufacturing. Легко увидеть «пробку» на пути каких-нибудь заготовок на заводе, это будет «затор» в виде груды заготовок перед каким-нибудь станком, или затоваренного продукцией или сырьём склада. А как увидеть «затор» в разработке, где «станки» — это компьютеры? В разработке:

• Есть циклы (пробы гипотез), их число заранее неизвестно.

• Есть тупики (отброшенные гипотезы), их число заранее неизвестно.

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

• Собрать результаты размышлений вместе — это совсем не похоже на то, как собирается конструкция из точно изготовленных деталей! Время на такую сборку плохо поддаётся оценке.

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

• Хорошо известные способы оптимизации проектов и процессов (например, «маленькая партия для обработки») плохо работают: какая такая «маленькая партия для размышления», как её выделить из всех размышлений?

У нас нет места в курсе «Системный менеджмент» для описания того, что вы вычитаете в этих двух книгах, но для того, чтобы хоть как-то понимать, каким образом прекратить «пожары» и «авралы» вокруг вас, вам нужно знакомство с этим материалом.

Мы не даём много дополнительной литературы, ибо она сегодня общеизвестна (например, книги Элияху Голдратта и его коллег по теории ограничений, или книги Давида Андерсона десятилетней давности по канбану в разработке). На все эти книги есть ссылки в предложенных нами двух книгах.

Тут ещё много нюансов, но в нашем обзорном курсе вряд ли мы сможем рассказать о них всех. Например, использование визуальных средств для управления работами: скажем, Trello очень нравится менеджерам старой закалки, потому что у них редко бывает 200-300 кейсов/issues на контроле, и красивые раскладки карточек на бумаге радуют глаз. У программистов легко в небольшом очень проекте получаются 6000 кейсов/issues, и они ещё привязаны к системе версионирования, и тут нужна нормальная табличная работа в программах, которые не будут нравиться менеджерам старой закалки. В некоторых фирмах вместо issue tracker используют протоколы, которые не выживают больше одного приноса на совещание (максимум двух приносов), поэтому всегда проблемы с «забытыми задачами». Некоторым особо ценным сотрудникам разрешают нарушать принцип «не записано в issue tracker, значит, работа не сделана» — и не увольняют их за нарушение производственной дисциплины, ведущей к конфигурационным коллизиям, потом удивляются, что никак не удаётся потушить авралы и пожары (но это же пункт 2 в нашей истории — наладить контроль конфигурации).

В принципе, весь этот материал пригоден и для управления собственными работами. Поэтому в курсе «Собранность» довольно много отсылок к TameFlow именно для операционного менеджмента личных работ, но вам не помешает также и знакомство с идеями Product Development Flow, их тоже вполне можно применить к менеджменту личных работ. В курсе «Собранность» тоже подчёркивается важность моделирования (ничего не держать в голове! Мозгу не верим! Всё записывать!), весь операционный менеджмент держится на хорошо налаженном моделировании работ и рабочих продуктов, то есть на хорошо налаженном операционном учёте. В основе практик time management (так иногда называют операционный учёт для личности), или практик личной продуктивности (есть и такое название) лежат модификации довольно древней практики GTD²³, где главное ровно вот это: всё записывать, ничего не помнить, голова должна быть свободна от планов — все планы нужно выгрузить из головы в экзокортекс, но иметь привычку регулярно (несколько раз в день!) заглядывать в списки дел и заниматься стратегированием и планированием. Из современной литературы по управлению собственными работами можно посоветовать книги Максима Дорофеева²⁴.

Задания

Поставьте отметки о выполнении следующих дел:

1. Прочтена книга Steve Tendon, «The Book of TameFlow», 2022. Опубликовано в блоге эссе с мыслями, пришедшими в голову по ходу прочтения книги (без этого эссе книгу нельзя считать прочитанной).

2. Прочтена книга Donald G Reinertsen «The Principles of Product Development Flow: Second Generation Lean Product Development». Опубликовано в блоге эссе с мыслями, пришедшими в голову по ходу прочтения книги (без этого эссе книгу нельзя считать прочитанной).

3. В рабочем проекте использована как минимум одна практика операционного менеджмента книги «The Book of TameFlow» и опубликовано эссе с описанием этого эксперимента и его результатов.

4. Опубликовано эссе о том, что наиболее контринтуитивно в принципах, изложенных в книге «The Principles of Product Development Flow».

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

Управленческий финансовый учёт и контроллинг

Не забываем и про управленческий финансовый учёт и контроллинг. Его выполнение — это задача администрирования. Операционный учёт материалов, работ и денег (учёт экземпляров тех типов важных объектов, которые определены менеджерами оргразвития). Речь идёт о модели предприятия (модель — это про экземпляры, типы задаются метаС-моделью). Понятно, что для разных целей разным ролям нужны разные модели, поэтому есть ТебеУчёт и СебеУчёт. Вот управленческий учёт — это СебеУчёт, а налоговый учёт, иногда демонстрация затрат клиентам и партнёрам — это варианты самых разных ТебеУчётов, и очень часто в этот момент мы вспоминаем схему и вполне возможно, что корректируем управленческие решения, они принимаются по всем учётам в совокупности. Но чего нельзя делать, так это вместо ведения СебеУчёта использовать какой-то из вынужденно ведущихся ТебеУчётов.

Как именно надо считать деньги, чтобы принимать решения по управлению работами — это задача операционного менеджера. Он управляет и потоком работ, и потоком денег, ибо нет работы — нет денег, а если нет денег, то незачем работать. Максимизируем проход в потоке и работы, и денег.

TameFlow рекомендует Throughput Accounting, построенный на идеях маржинализма (вы должны были уже понимать эти идеи из материала по австрийской школе экономики, именно эта экономическая школа совершила маржинальную революцию в экономике). Вся экономика фирмы базируется на маржинальных рассуждениях, которые операционным менеджерам надо хорошо понимать. Так, бессмысленно спрашивать о выгоде проекта, если непонятны текущие производственные мощности и их текущая загрузка. Сферический проект в вакууме не может быть оценен как выгодный или невыгодный! А ещё все рассуждения про «себестоимость» немаржинальны, ими опасно пользоваться при оценке работы фирмы. Так что управленческий СебеУчёт должен строиться на принципах маржинализма, и этому хорошо соответствует как раз Throughput Accounting. Подробности можно узнать в паре книжек. Первая — это Томас Корбет, «Учёт прохода. Управленческий учёт по ТОС» (оригинал вышел в 1998, финансовый учёт — очень консервативная практика!):

Вторая книга — это John and Pamela Caspari, «Management Dynamics: Merging Constraints Accounting to Drive Improvement», 2004:

Добавить сюда нужно идеи юнит-экономики, но книг по ней нет, ибо материал важный, но укладывается в размер статьи²⁵:

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

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

• В зарубежной литературе могут по-старинке пользоваться ROI (return on investment) или ROMI (return on marketing investment) — всё то же самое, что в юнит-экономике, но относимое к инвестициям в конкретную продукцию и конкретный канал дистрибуции (показатели для разных продуктов и разных каналов дистрибуции будут разными)

• Главный показатель — LTV (lifetime value — сколько принесёт один юнит за всю свою историю) и CA (cost of acquisition — сколько нужно денег на маркетинг, чтобы заполучить юнит).

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

Из современных трендов нужно указать также тренд перехода от ежегодного бюджетирования к ежеквартальному, ежемесячному, а затем (в пределе) ежедневному — когда решения о направлениях траты денег принимаются не заранее за год, а по мере возникновения потребности в деньгах и с учётом текущих приоритетов, а не приоритетов, которые были, возможно, аж за год до момента актуального расходования бюджета. Это движение «скользящего окна финансового планирования» «за пределами бюджета», beyond budgeting²⁶. Для этого направления есть уже довольно много литературы, оно скрывается под разными именами. Там есть довольно много особенностей²⁷ (большинство из них связаны с тем, что планировать расходы ограниченно, но можно, но есть большой соблазн планировать и доходы! А вот это опасно. Помним, что «стратегирование» в менеджменте появилось в 40х годах прошлого века как раз как «бюджетирование» и только потом стало независимой практикой, потихоньку избавляясь от ошибок. Но эти старинные ошибки все вполне могут присутствовать в практиках бюджетирования).

TEST Много разных финансовых учётов

Мария утверждает, что учёт должен быть в фирме один: нельзя считать разные показатели из одних и тех же первичных финансовых документов! Ольга считает, что наоборот: из одних и тех же документов нужно выводить разные показатели. Кто прав?

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

+++ Ольга. ### Да, показателей должно быть много, хотя они и выводятся из одних и тех же первичных финансовых документов. Разные проектные роли используют разные принципы финансового учёта, и каждая проектная роль должна получить понятные и удобные для принятия их управленческих решений цифры. Другое дело, что все эти решения должны быть согласованы между собой, но это не отрицает идеи множественности учётов.

Задание

Поставьте отметку о выполнении:

1. Прочтена книга Томаса Корбетта «Учёт прохода». Опубликованы в блоге собственные мысли, которые пришли в голову по мере чтения книги Томаса Корбетта.

2. Написан обзор по практикам бюджетирования, найдены современные модификации практики beyond budgeting. В конце обзора вы даёте краткую справку, какие из этих практик использует ваша организация, приводите рекомендации по улучшению этих практик, исходя из материала вашего обзора.