Ох, коллеги, как я люблю, когда у вас что-то "чешется", и вы это "чешете" с забавными (для меня) искажениями.

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

Проблема кроется в слове "найти".

В популярном изложении TOC поиск ограничения часто выглядит примерно так: посмотреть на бизнес с высоты, увидеть, где застревают деньги, клиенты и ресурсы, оценить емкость этапов, оцифровать процессы - и вуаля, "бутылочное горлышко" станет очевидным.

Нет, не станет. По крайней мере, совсем не обязательно. Я любезно объясню вам, почему.

Во-первых, ограничение системы и участок с низкой пропускной способностью - не одно и то же. Ограничением может оказаться не только производительность конкретного процесса, но и дефицит компетенций, способ принятия решений, архитектурное решение, управленческая политика или даже сам рынок. Сведение constraint к "самому медленному месту" удобно для объяснения истории про Герби, но заметно обедняет саму концепцию.

Во-вторых, наблюдение системы не является методом диагностики. Можно посмотреть на процесс в масштабе 1:1, 1:1000 или нарисовать его на стене целиком. Это поможет увидеть связи, но не даст критерия, по которому один фактор следует признать ограничением, а другой - его следствием.

То же самое относится к, простите, оцифровке. Данные не "подсвечивают реальные провалы" сами по себе. Они делают наблюдаемым то, что мы решили измерять. Можно идеально оцифровать процесс, построить десятки дашбордов и получить очень точное описание симптомов, абсолютно не обнаружив их причины.

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

Наконец, даже после обнаружения ограничения TOC не предлагает немедленно его "расширять". Классические Five Focusing Steps устроены иначе:

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

Именно поэтому фраза "как я нахожу узкие места" требует большего, чем перечень общих принципов системного управления. Нужен хотя бы ответ на простой вопрос: по каким наблюдаемым признакам и причинно-следственным связям мы заключили, что именно этот фактор ограничивает достижение цели системы?

Один из вариантов такой работы дают Thinking Processes Голдратта. Например, через упрощенное дерево текущей реальности: собрать наблюдаемые нежелательные явления, установить причинно-следственные связи между ними, найти фактор, способный объяснить несколько эффектов одновременно, сформулировать кандидата на ограничение и проверить гипотезу.

Здесь и кроется принципиальная разница.

Наблюдение системы ≠ диагностика ограничения. Оцифровка ≠ диагностика ограничения. Очередь ≠ доказательство ограничения. Расчет мощности ≠ поиск любого ограничения. Устранение заметной проблемы ≠ работа с ограничением системы.

Все перечисленное может дать данные, симптомы и кандидатов, да. Но между "здесь что-то происходит" и "мы нашли ограничение системы" должна появиться причинно-следственная модель и проверяемая гипотеза.

Поэтому правильный вопрос звучит не "где у нас медленнее всего?", а "какой фактор ограничивает достижение цели системы и какие наблюдаемые эффекты должны измениться, если мы воздействуем именно на него?"

Иначе вместо Theory of Constraints довольно легко получить Theory of Suspicious Places.

P.S. У меня есть целая статья по TOC на GBAK. Не благодарите.