Давайте разберем конкретные примеры, как применяется теория ограничений на практике. Разберем примеры из производственной сферы и из сферы IT.
Начнем с обычного производственного процесса.
Дано:
Какой будет максимальный выпуск продукции в день?
Ответ — 6 единиц в день (этап 3). Это значит, что именно на этом этапе производства нам нужно сфокусировать наши силы. Именно там нужны инновации и внедрение изменений, которые позволят компании увеличивать оборот.
Давайте предположим, что мы проделали хорошую работу, и добились хороших показателей на каждом из этапов производства — от 17 до 23 единиц продукции в день.
Что произойдет тогда? Где слабое звено?
Ответ — рынок.
Рынку сейчас не нужно более 15 единиц продукции в день. Сколько бы продукции мы не создали, она не будет потребляться более 15 единиц в день. Это значит, что все производство выше 15 единиц будет избыточным, и будет являться потерей.
Если мы захотим расширяться, нам нужно будет придумать что–то новое, отличное от простого увеличения оборота и производственных мощностей. Например — новый продукт, захват новой целевой аудитории, расширение территории охвата или что–то еще.
Давайте разберем пример работы IT компании.
Представим, что у нас идет разработка программного обеспечения. У вас есть ряд активностей, которые нужно сделать, чтобы добиться результата.
Вот, что может быть нужно:
Руководство должно создать задачи в бэклоге
Разработчики должны реализовать функционал
Тестировщики должны протестировать
Аналитики должны проанализировать
и т.д.
Предположим, что вы можете создать за неделю 1000 задач для разработки. Разработчики могут реализовать за неделю 6 задач. Тестировщики могут проверить 30 задач. Аналитики могут обработать 10 задач.
Согласно теории ограничений и руководствуясь здравым смыслом, мы можем понять, что сколько бы задач не обрабатывали тестировщики и аналитики, и сколько бы задач не создавалось, вы сейчас не можете реализовать более 6 задач (ограничения на этапе разработки), которые в итоге и приносят ценность бизнесу. Это — ключевое ограничение этой системы.
Из этого следует, что вам нужно обратить внимание именно на процесс разработки.
Даже если бы можно было создавать, анализировать и тестировать миллионы задач, от этого ничего бы не изменилось. Потому что разрабатывается по–прежнему всего 6.
Что можно сделать? Например, можно подключить часть людей к процессу разработки (например, отдельных его этапов). Или лучше декомпозировать задачи, чтобы разработчики могли быстрее их выполнять. Можно нанять дополнительных программистов, чтобы команда могла обрабатывать больший объем работы.
В любом случае, пока вы не сделаете что–то с этим конкретным ограничением, нет никакого смысла работать над чем–то другим — потому что общая производительность этой системы никак не изменится.
Предположим, что вы повлияете на это ограничение. Вы что–то изменили в процессах, и теперь разрабатывается 15 задач в неделю. Теперь разработка — уже не ключевое ограничение. Теперь ограничение и «узкое место» бизнеса — в области аналитики, ведь здесь только 10 задач в неделю проходит обработку.
Теперь даже миллион обработанных в разработке задач не улучшат вашу ситуацию, потому что вы не будете получать ценность больше, чем 10 задач, если для релиза необходим этап аналитики.
И так далее — вы можете обеспечить непрерывный процесс совершенствования, с опорой на ключевые ограничения системы.