Измерение изменений

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

Что нужно, чтобы измерить изменения? Для начала определиться, что именно должно быть результатом выполнения метода, а именно – какие объекты должны быть в каких конечных состояниях. Например, «обед» «приготовлен» (или «подан на стол»), «отчёт составлен», «встреча проведена».

Далее неплохо бы отмоделировать, какие ключевые состояния объекты внимания/предметы метода будут проходить в ходе применения метода «вообще». Например, «выбрано блюдо для готовки», «наличие ингредиентов проверено», «выбран метод составления отчёта», «метод понятен исполнителю» и так далее. Тут важно отметить, что при моделировании состояний объектов/предметов метода вы будете размышлять в так называемом «методологическом» времени. Это «вневременное время» в том смысле, что тут нет никаких временнЫх меток. Вы не прописываете, когда, к какому времени, обед должен быть «приготовлен», отчёт «подготовлен и загружен». Вы только описываете состояния, которые не могут не принять объекты в ходе выполнения метода.

При первой попытке описать состояния вы получите что-то наподобие V-диаграммы инженерии (только с парами объект-состояние):

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

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

Рассуждение придётся повторять на разных уровнях организации предприятия как системы. Системами пока будем называть масштабы крупности физических объектов. Далее в руководстве по системному мышлению понятие «системы» будет расширено и дополнено.

Для компании как системы в целом будет верно такое же рассуждение. Общий алгоритм рассуждения таков:

1. Определить конечный результат. Для компании в целом конечный результат – это вещь, покидающая границу предприятия (далее вы будете называть это «целевой системой»). С точки зрения операционного менеджмента интересует количество таких вещей в штуках/партиях/иных единицах измерения, то есть, выпуск**.** Вернёмся к примеру со столярной мастерской. Если в ней изготавливают лестницы, то границу предприятия покидают лестницы – сколько-то штук ежедневно/еженедельно/ежеквартально и так далее (выпуск в штуках). Если вы производите молоко, придётся выбрать какой-то измеримый результат для замеров, например, количество произведённых бутылок молока. У ИТ-компаний это могут быть релизы;
2. Определить, каковы ключевые состояния вещи, через которые она проходит, прежде чем покинуть границу предприятия. Тут можно думать так: класс «лестниц, выпускаемых предприятием», уже существует; теперь надо, чтобы воплотились физические объекты – экземпляры класса, то есть, лестница ID 405 для клиента А, лестница ID 406 для клиента Б, которые 4 мартобря 20ХХ года отправятся клиентам. Для этого должно появиться «описание лестницы» (и описания её частей), причём, скорее всего, не одно (описание для клиента, для столяра, для юриста и так далее), подобран материал, бруски напилены, обстроганы, фрезерованы и так далее, лестница собрана – вплоть до конечного состояния, которое вы определите сами (кто-то посчитает, что конечное состояние – это «лестница, отправленная клиенту», а клиент уже сам собирает, кто-то решит, что для них конечное состояние – «лестница, установленная у клиента», а кто-то и вовсе скажет, что конечное состояние – «лестница, выдержавшая полгода эксплуатации»). Здесь можно вспомнить чеклисты или V-диаграмму выше, можно описать состояния объектов в таблице.
3. После определения ключевых состояний нужно будет замерить скорость выпуска/скорость до результата: с какой (средней) скоростью объект/альфа/ключевой предмет метода проходит путь от начального состояния (его тоже придётся выбрать самостоятельно, как и конечное состояние!) до конечного. Выпуск в штуках учитывает только количество покинувших предприятие вещей (штук лестниц в данном случае) – и нам не важно, сколько вещь изготавливается. А вот скорость выпуска оценивает, как быстро вещь (экземпляр класса «лестниц, выпускаемых мастерской») проходит путь по конвейеру.
4. После вы можете приблизить/zoom in «камеры внимания», навести их на конкретные кусочки пути, где возникает больше всего проблем (часто там расположены бутылочные горлышки, воздействие на которые даст максимальный эффект с точки зрения операционного менеджмента/управления работами). Выделить конкретные работы по методу (например, на схеме или в таблице), которые выполнить сложнее всего, например, в силу сложности метода (например, моделирование обычно сложнее, чем использование модели для получения конечного результата. Составить хороший чеклист посложнее, чем его выполнить) или в силу ограниченности ресурсов для выполнения работ (недостаточно квалификации исполнителей, мало материалов, мало денег и так далее).
5. После чего выделить как самые проблемные, так и самые медленные операции на участках пути. Наиболее медленная операция из всех будет ограничением. Чтобы ускориться в выполнении работ, нужно воздействовать на ограничение в первую очередь.
6. Для воздействия на скорость работы ограничения мы можем применять разные управленческие воздействия/оргизменения. Мы можем вычислить ожидаемый эффект от воздействия – а именно, изменение в скорости работы ограничения или темп/ускорение.
7. Для сравнения воздействий между собой нужно будет вычислить, какое из них даёт наибольшую прибавку в скорости до результата. То есть, сравнить ускорения между собой. Для этого мы можем сравнить ускорения «в лоб» или рассчитать рывок, то есть, изменение в ускорении. Если одна инициатива даёт ускорение в 1.5 раза, а вторая – в 3 раза, то рывок от второй инициативы в 2 раза больше.

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

В квантовой механике считается, что нельзя измерить одновременно координаты частицы и её импульс/количество движения. Для физики предприятия ситуация такая же запутанная, и по-своему ещё хуже: мы заранее вообще ничего не знаем точно.

Мы не знаем заранее точный путь объекта от начального состояния до конечного. Мы можем только описать «методологический путь» и затем замерять «физический путь» в реальности.

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

Мы не знаем заранее скорость движения объекта. Мы можем предположить/спрогнозировать на основе статистики и наших предположений о том, что изменится в будущем. Как спрогнозировать, можно вычитать в книжках The Book of TameFlow/Tame Your Work Flow (разные названия одной книги) от Steve Tendon или Actionable Agile Metrics и When Will It Be Done от Daniel S. Vacanti. Но и эти прогнозы будут проваливаться в некоторых случаях.

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

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