Уже 50 с лишним лет прошло с активного начала “пропихивания” Хаббардавскими адептами “великомогучей и вселенско-универсальной” организующей схемы и ее производных.

Я и сейчас встречаю в России ярких приверженцев этого подхода, в 2026 году. Да, она сильно видоизменилась, но лик зла постоянен и неизменен 🙂

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

Именно поэтому он и затачивал систему под свой профиль (религиозная секта с максимально быстрой экспансией). И может быть в пределах его сферы это работало, но его адепты из WISE (World Institute of Scientology Enterprises), ИМХО, допустили фундаментальную ошибку, оставив жесткую вертикаль власти в качестве элемента, который по их мнению должен был способствовать увеличению коэффициента E (см. ниже).

(обозначим эффективность всей системы за P и универсальный коэффициент эффективности за E, увеличивая или уменьшая который в разных формулах, мы соответственно изменяем общую эффективность всей системы (P))

Но давайте попробуем разобрать неизбежно вытекающие аспекты такой жесткой иерархии (особенно в современном IT-бизнесе) и понять, как они реально могли бы влиять на введенный коэффициент E (в силу ограничений размера постов в Сетке буду разбирать аспекты по одному на пост)

1. Затянутость обработки инцидентов.

Любая система генерирует инциденты. Это утверждение легко доказывается из определения системы (ее сложности), но в реальности в доказательстве не нуждается 😉

Интенсивность потока инцидентов напрямую связана с масштабом и сложностью системы.  Также и пропускная способность канала обработки инцидентов зависит от мощности ресурсов которая компания готова выделять.

А теперь самая элементарная и неудобная для руководителя правда: Вы когда-нибудь встречали системы где инциденты генерируются сверху вниз? ;) Это ведь та самая, пресловутая “инициатива”, которая словно наш любимый event bubbling из JS: инциденты бОльшим потоком всплывают из глубин системы 😀

И если компания борется с ней сверху-вниз (категоризация инцидентов/заранее прописанные превентивные меры и пост-меры в регламентах/etc) - то архитекторам таких систем следует как минимум задуматься, с того ли конца Вы подходите к решению задачи, ведь Все еще помнят крылатое выражение “Corruptissima re publica plurimae leges”

Нас же сейчас интересует только влияние такого аспекта на универсальный коэффициент E.

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

Жесткость иерархии играет здесь ключевую роль. Все Вы видели древовидные структуры компаний и “шляпы” для руководящих должностей.

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

Это прямое следствие нежелания работать с системой как с единым организмом связанных и зависимых элементов.

О следующем аспекте расскажу в следующей статье, а сейчас хотелось бы узнать у Вас - насколько структура Вашей компании похожа на дерево и не задумывались ли Вы о более реалистичной, пространственно-временной топологии структуры и связей команд/отделов/сотрудников и системы в целом? 🤯