Принципы физики предприятия и закон Литтла

Из-за наличия изменчивости при выполнении работ долгосрочная производственная мощность/****capacityвсегда выше, чем долгосрочный **реальный выпуск/**Throughput предприятия (при условии, что создатель в стабильном состоянии). Иными словами, долгосрочная производственная мощность задаёт предел, ограничение сверху на выпуск предприятия. И если мы хотим в долгосрочном периоде значительно увеличить выпуск, нам придётся в какой-то момент увеличивать его долгосрочную производственную мощность/capacity. Это один из принципов физики предприятия.

Это кажется очевидным. В самом деле, если сотрудник:: рабочая станция может максимально выполнить 3 сложные задачи в день, то долгосрочный реальный выпуск будет не 3 задачи в день, а меньше, например, 2-2,5. Ведь будут дни, когда у сотрудника будут несколько встреч в день, дни, когда придётся ждать ответа, дни, когда он не выспится и будет плохо соображать, и так далее. За счет собранности сотрудника и грамотного проектирования организации (включая проектирование петель обратной связи) можно уменьшить долгосрочные потери выпуска, но не убрать их полностью. Если бы можно было полностью избавиться от долгосрочных потерь выпуска, а долгосрочный реальный выпуск/Throughput был бы равен долгосрочной производственной мощности, это бы означало, что мы живём в мире без изменчивости. Но вы знаете (можете узнать при помощи ), что это не так. Поэтому в долгосрочном периоде реальный выпуск всегда меньше производственной мощности.

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

Второй принцип физики предприятия – принцип нелинейного увеличения времени выполнения работ/потокового времени/FlowTime**/CycleTime** при увеличении загрузки производственной мощности/capacityutilization****рабочей станции.

Зачем нужен показатель загрузки производственной мощности рабочей станции? Он позволяет отследить, как быстро рабочая станция обрабатывает пришедшие к ней наборы предметов работ/sets of work items, или как рабочая станция справляется с нагрузкой/workload, а также определить, какая станция является ограничением (самой медленной станцией).

Рабочая станция может выполнять работы по методу медленно в силу особенностей метода, которым работает. Например, работы по составлению моделей будут выполняться при прочих равных медленнее, чем работы по критике моделей, потому что в одном случае вы делаете всё с нуля, а во втором – ищете недостатки в принесенном описании модели. Аналогично работы по составлению статьи автором будут, скорее всего, выполняться медленнее, чем работы по редактуре и корректуре статей. Это означает, что производственная мощность/capacity автора будет меньше, чем у редактора. Производственная мощность автора – 0,83 статьи в неделю или 1,66 статьи за две недели; производственная мощность редактора может быть равна 0,95 статьи в неделю или 1,9 статьи за две недели. Производственная мощность как предельный/максимальный потенциальный выпуск зависит от особенностей применяемого метода. Чтобы ускорить рабочую станцию с наименьшей производственной мощностью, нужно что-то изменить в методе её работы. Например, автор меняет метод составления статей: подключает нейросети для генерирования шаблонов текста (на основе ранее составленных шаблонов), а затем осуществляет авторский надзор за текстом, исправляет ошибки, меняет подачу текста при необходимости и так далее.

Однако вы можете столкнуться с ситуацией, что благодаря изменению метода выполнения работ производственная мощность автора поднялась на ~30% до 1 статьи в неделю, но выпуск контентной команды не увеличился. Это произошло потому, что автор как рабочая станция не был ограничением команды! Да, автор медленнее всего выполняет работы по методу; однако авторов в команде 5, а редактор – 1. Как вы таком случае вычислить ограничение? Тут и помогает показатель загрузки производственной мощности/сapacity utilization рабочей станции: он показывает, как соотносится «входящий» поток предметов работ (он же «входящая нагрузка») и производственная мощность станции:

Capacity utilization = rate into station / capacity

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

Как рассчитать этот показатель: оцениваем для начала производственную мощность рабочей станции. Например, у автора статей она равна 0,83 статьи в неделю или 1,66 статей за 2 недели. Далее смотрим, как действует автор. Допустим, он передал статью:: предмет работ редактору на 10-й календарный день после даты (или даты и времени) старта статьи, и немедленно взял в работу следующую статью: начал набрасывать структуру, подбирать материал, и так далее (выполнено касание работы, начало отсчитываться потоковое время для следующей статьи). В таком случае его «входящий поток» за 2 недели – это 2 статьи: одну он передал, вторую начал. Но производственная мощность у него – 1,66 статьи за 2 недели. Тогда загрузка производственной мощности равна 2/1,66, или ~120%. И тут у вас должен сработать сигнал: что-то не так! Загрузка не должна быть выше 100%, мы делаем что-то не то!

Если автор контентной команды сдаёт одну статью редактору и немедленно берёт в работу вторую, то далее происходит следующее: автору прилетают переделки по первой статье, но он уже в фокусе работает над второй, поэтому откладывает правки. Выпуск статьи задерживается на неопределённое время по второму принципу физики предприятия: при увеличении загрузки производственной мощности потоковое время производственной линии растёт нелинейно. Причём чем ближе вы к 100% загрузке, тем больше рост! И особенно серьёзные последствия при высокой изменчивости/variability:

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

• Обучение – инвестирование в повышение своего мастерства;
• Поиск конфигурационных коллизий – то есть, статей, выпущенных другими контентными командами и предлагающих другой метод решения проблемы бухгалтера или юриста. Если не отслеживать такие коллизии вовремя и не принимать решение о разбирательстве с ними заранее, то впоследствии вы получаете задержку выполнения требуемых действий клиентом (юристом или бухгалтером), недовольство клиента, необходимость срочно собирать команду и аврально тратить время на выработку единой позиции;
• Эксперименты, например, с использованием нейросеток в работе, исследования клиентов (необходимое для более глубокого понимания языка клиента, на котором предстоит писать, составления модели клиента, чтобы правильно доносить информацию, и так далее).

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

Поэтому, если обнаружено, что автор загружен более чем на 100%, надо передоговориться с ним о следующем: пока статья не перешла в состояние, в котором переделок автору не прилетит, он не берёт в работу новую статью. Например, договариваетесь, что для автора сигналом о том, что можно брать в работу новую статью, является событие перехода статьи в состояние «опубликовано», или «одобрено к публикации», или «одобрено редактором» (какое именно событие – выбирать вам). До тех пор автор не берет новую статью. Допустим, выбранное событие происходит через 5 (календарных) дней после передачи статьи редактору. В таком случае в течение двух недель автор касается не двух статей, а одной статьи. Его загрузка падает до примерно 60% (1/1,66). Автор ждёт, пока не придёт сигнал о том, что можно брать в работу новую статью. А пока ждёт, он может:

• Проходить обучение, чтобы повысить квалификацию в мастерстве (прикладном или фундаментальном);
• Найти конфигурационные коллизии между отправленной редактору статьей и уже опубликованной статьей на портале – и поднять вопрос о выработке единой позиции. Может даже составить черновик общей позиции, который затем будет критиковать совместно с коллегами;
• Провести предварительную подготовку/Full Kitting для следующей статьи: заранее поискать конфигурационные коллизии и озаботиться их разрешением (не постфактум после написания статьи); подобрать список источников информации и составить план исследования; начать читать подобранную информацию и составлять заметки/заготовки будущей статьи;
• Проводить эксперименты по использованию нейросеток в работе, участвовать в клиентских исследованиях для понимания моделей клиентов, языка их общения, и так далее.

При этом автор не забывает, что приоритет всё равно у статьи: если приходят переделки – их надо внести быстро (на такие задачи зарезервировано 30% времени – это буфер). Но остальное время уходит не на «текучку», а как раз на подобные инвестиционные работы, которые затем дадут улучшение качества предметов работ (и возможность брать с клиентов больше денег за это).

Однако загрузка автора на 60% нас тоже может не устраивать: если автор – ограничение в команде, то выпуск всей остальной команды будет ограничен выпуском ограничения. Поэтому мы хотели бы иметь более высокую загрузку автора. Как этого достичь? Можем прикинуть: в неделю производственная мощность составляет ~0,83 статьи, значит, за месяц она составит примерно 3,569 cтатьи (0,83 * 4,3 недели в месяц). Тогда мы можем выбрать ближайшее целое число, которое будет меньше 3,569 – это 3. Если автор будет брать в работу 3 статьи в месяц (а не 2), то загрузка будет высокой (3/3,569 = 84%), но всё ещё меньше 100%. (Мы ожидаем, что за месяц он сможет написать 2 статьи, которые будут опубликованы, и 1 начнёт). Далее надо будет вычислить событие, которое станет сигналом для автора брать в работу следующую статью. Это должно быть, с одной стороны, такое событие, после которого правки возможны, но маловероятны. Если вы выберете событие, где правки уже невозможны, например, событие «публикации», то вы выбрали слишком позднее на временной линии событие и потеряли время в ограничении. Если вы выберете событие слишком раннее (например, событие передачи статьи редактору), то вы рискуете сместить фокус внимания автора на новую статью, и со старой (находящейся ближе к выходу с линии!) он будет работать по «остаточному принципу», растягивая сроки внесения правок. Поэтому подбираем событие, где правки именно что возможны, но уже маловероятны и/или несущественны по времени – с одной стороны. А с другой – это должно быть такое событие, частота наступления которого позволит автору взять в работу 3 статьи в месяц (и сдать 2).

Аналогичным образом нужно подсчитать загрузку производственной мощности других рабочих станций в производственной линии и, если она превышает 100%, уменьшить её.

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

Всё из-за рабочей нагрузки/work load/большом потоке «входящих» предметов работ. Одному редактору сваливаются статьи сразу 3 авторов одновременно. Его производственная мощность – 4 статьи в неделю, поэтому загрузка равна ¾ или 75% – больше, чем 60% у автора. На самом деле редактор является ограничением: именно на редакторе «застрянут» невыпущенные статьи. В таком случае скорость выпуска/Throughput Rate статей производственной линии (контентной команды) будет равна скорости выпуска статей редактором. Если вас не устраивает текущая скорость выпуска, надо будет работать в первую очередь с редактором, а также рабочей станцией прямо перед ним и сразу после него. Внимание управленцев должно фокусироваться на ограничении и его окрестностях.

К сожалению, многие ERP-системы поддерживают возможность регулярно/систематически указывать загрузку производственной мощности/capacity utilization выше 100% и не ругаются на это. Тем самым поддерживается заблуждение менеджеров, что при загрузке выше 100% можно выстроить оптимальный рабочий процесс. Лучше не попадаться в эту ловушку.

Ещё одно важное уравнение, с которым вы уже встречались в ходе стажировки, называется законом Литтла. Закон Литтла описывает, как выпуск зависит от незавершёнки и среднего потокового времени:

Выпуск = незавершёнка / среднее потоковое время, или Throughput = WIP**/av.** Flow****Time

или

WIP = Throughput * averageFlowTime

или

averageFlowTime = WIP / Throughput

Закон Литтла был выведен в теории массового обслуживания и использовался для расчётов времени завершения обслуживания клиентов в очереди. Его можно применять там, где мы имеем дело с очередями. Изначально он формулируется так: среднее количество объектов в очереди равно средней скорости прибытия объектов в очередь, умноженная на среднее время ожидания в очереди (ожидания до обслуживания):

Average Items in Queue = Average Arrival Rate * Average Wait Time in Queue

Запись WIP = Throughput * Average Flow Time – это переформулировка закона Литтла для потоков работ. Однако есть нюанс применения: в изначальной формулировке учитывалась скорость входа объектов, а Throughput/Thrpughput Rate описывает скорость выхода. Поэтому закон применим, только если скорость входа объектов равна скорости выхода, то есть, новые задачи берутся в работу по сигналу, что рабочая станция (в идеале – ограничение) выполнила работу по какой-то задаче и освободилась, может взять новую. Тогда «скорость входа» можем заменить на «скорость выхода» и грубо подсчитать время выполнения работ. В случае с автором контентной команды это означает, например, что он начинает следующую статью только после сигнала о выбранном событии (например, узнал, что статья в состоянии «одобрена к публикации»).

Но это не единственное условие применимости закона Литтла. Закон Литтла даёт неточную, но полезную оценку времени выполнения, например, проекта, если приоритет проекта не меняется, те вы продолжаете выполнять задачи по проекту регулярно. Если рабочая станция сначала выполняет MOVEs по проекту регулярно в режиме «первого приоритета» (см подраздел «Перестройка расписания» для подробностей), а потом переводит проект в режим «третьего приоритета» и выполняет работы лишь тогда, когда есть свободное время, или точечно/нерегулярно, то закон Литтла можно применить только для части проекта, выполняемой в режиме «первого приоритета». Также оценка перестаёт быть надежной, если в ходе проекта вы меняете правила работы с очередью: взятое в работу после предварительной подготовки должно быть выполнено, метод приоритизации при выборе проектов и задач должен соблюдаться, приоритизация должна выполняться по всей очереди (никаких задач и проектов-зайцев). Также не должно сильно увеличиваться количество незавершёнки/WIP, а средний возраст незавершёнки стабилен (отсутствуют долги и/или «технические» и прочие долги поддерживаются на одном уровне, не увеличиваясь).

Кроме того, выпуск, незавершёнка и потоковое время/Flow Time должны считаться в одних и тех же единицах измерения. То есть так:

Количество объектов = количество объектов/временное окно * размер временного окна,

где «временное окно» можно заменить на день/неделю/любой подходящий период, или

Количество денег = количество денег**/временное окно * размер временного окна**.

То есть, мы считаем выпуск в количестве штук объектов (релизов, статей, или задач) в день ИЛИ количестве денег в выбранное временное окно (например, день, месяц, год), затем умножаем на средний размер временного окна и получаем количество объектов. Применительно к выпуску статей: мы можем выбрать расчёт выпуска в количестве статей в неделю, тогда мы должны считать незавершёнку в количестве статей, над которыми команда начала работу, но ещё не выпустила, и рассчитывать среднее потоковое время в неделях. Можем выбрать расчёт не в количестве статей, а в количестве задач, и тогда мы считаем количество незавершёнки тоже в задачах (а не в статьях!).

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

По закону Литтла, уменьшение незавершёнки приводит к уменьшению среднего времени выполнения:

averageFlowTime = WIP / Throughput

Именно поэтому те действия, которые вы выполняли в течение первых недель работы по руководству, позволили вам ускориться. Вы начали выполнять условия применимости закона Литтла, и ваше среднее время выполнения работ уменьшилось, а выпуск увеличился. Теперь вы можете описать, почему так происходит.

Закон Литтла применим и на уровне линий/потоков, но при одном условии: если вы уменьшаете незавершёнку станции-ограничения. Пока вы не начали моделировать потоки работ и считать, вы не знаете, какая именно станция будет ограничивать выпуск. Но ещё до того, как вы её нашли, вы можете сделать следующее: уменьшить незавершёнку на всей линии (для всех включённых в неё рабочих станций), то есть, уменьшить скорость входа/arrival rate новых задач, сделав её равной скорости выполнения/скорости выхода/departure rate. Это позволит вам ещё до нахождения ограничения уменьшить его незавершёнку, а соответственно, повысить выпуск всей станции.

Вы можете попробовать рассчитать прогнозируемое время выполнения работ, используя закон Литтла. Но вам надо будет следить за выполнением условий применимости закона Литтла.