Системный анализ · Организационная теория · ЭКОНОМИКА ОТНОШЕНИЙ

Энтропийный подход к инжинирингу информационных систем

Формализованное обоснование несовместимости условно-постоянных организационных структур с динамической реальностью инжиниринга. Практика создания информационных платформ.

Владимир Лемех

Настоящий текст создан автором как агентом замысла. Искусственный интеллект использовался в качестве инструмента структурирования, редактуры и технической компоновки материала

Аннотация

Любая функциональная структура — отдел, сектор, управление — является условно-постоянной: её состав, связи, регламенты и критерии оптимизации фиксированы. Действительность — переменна: требования меняются, связи между подзадачами перестраиваются, появляется новая информация. Соотношение постоянного и переменного неизбежно порождает энтропию — информационный шум, рассогласование между структурой управления и объектом управления. Статья формализует этот механизм с помощью теории информации, нечётких множеств, теории графов, теории игр и математического программирования. Практическая часть посвящена созданию информационных платформ — проектов, которые принципиально невозможно реализовать штатной командой отдела и которые требуют сетевого взаимодействия. Приводятся конкретные кейсы с данными о трудоёмкости, составе команд и распределении работ.

Ключевые слова: энтропия, нечёткие множества, функциональная структура, сетевое взаимодействие, информационная платформа, инжиниринг, декомпозиция, кросс-функциональные команды

Введение: проблема, которую не видят

Каждый, кто работал в информационном проекте внутри функционального отдела, знает это ощущение: все работают, все стараются, каждый выполняет свою задачу — а результат не складывается. Переделки, задержки, конфликты между отделами. Обычно это списывают на «человеческий фактор» или «плохое управление». Но причина глубже — она математическая.

Суть проблемы в следующем. Любая функциональная структура — отдел, сектор, бюро — является условно-постоянной: те же люди, те же связи, тот же регламент, те же критерии оценки. Действительность, с которой эта структура работает, — переменна: требования меняются, связи перестраиваются, появляется новая информация.

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

Центральный тезис

Функциональная структура условно-постоянна. Действительность переменна. Соотношение постоянного и переменного неизбежно создаёт энтропию. Энтропия — это шум, помеха, которая съедает производительность и эффективность. Единственный способ снизить энтропию — перейти от постоянной структуры к переменной, то есть к сетевому взаимодействию.

Условно-постоянное и переменное: природа рассогласования

Что значит «условно-постоянная структура»

Функциональная структура — это способ организации людей по признаку выполняемой функции. Она условно-постоянна: состав фиксирован (одни и те же люди), связи фиксированы (каждый связан с начальником, а не с тем, кто нужен для задачи), регламент фиксирован (процедуры не зависят от содержания задачи), критерии оптимизации фиксированы (отдел оценивается по своим показателям, а не по результату продукта).

Слово «условно» важно: структура может меняться (реорганизация), но она меняется медленнее, чем задачи. Реорганизация — месяцы. Изменение задачи — дни или часы.

Что значит «переменная действительность»

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

Рис. 1. Источник энтропии: $S = \text{const}$ пытается управлять $R = R(t)$. Несовпадение = шум = потери.
Слева — функциональный отдел: связи между подразделениями фиксированы, регламент и критерии неизменны во времени. Справа — инжиниринговая действительность: требования сдвигаются, связи между подзадачами перестраиваются, информация обновляется непрерывно. Попытка управлять переменной реальностью неизменной структурой порождает рассогласование — и рост энтропии ($H \uparrow$).

Энтропия как мера рассогласования

Энтропия — не абстрактное понятие. Это измеримая величина, которая показывает, насколько структура рассогласована с реальностью.

Энтропия по Шеннону

Если система может находиться в $n$ состояниях с вероятностями $p_1, \ldots, p_n$, энтропия равна:

$$H = -\sum_{i=1}^{n} p_i \log_2 p_i$$

$H = 0$ — полная определённость. $H = \log_2 n$ — максимальная неопределённость.

Расстояние Кульбака-Лейблера: мера рассогласования

Применим это к организации. Пусть $p_i$ — реальное распределение состояний задачи (какая конфигурация требований, связей, ограничений актуальна прямо сейчас). $q_i$ — распределение, которое «ожидает» структура (какие состояния покрывает её регламент). Тогда:

$$D_{KL}(p \| q) = \sum_{i=1}^{n} p_i \log_2 \frac{p_i}{q_i}$$

Расстояние Кульбака-Лейблера — мера различия между реальным распределением и распределением, которое «ожидает» структура. $D_{KL} = 0$ — полное совпадение. $D_{KL} \gt 0$ — рассогласование = энтропия = шум.

Демонстрация: KL-расхождение на примере информационного проекта

Чтобы сделать это наглядным, рассмотрим конкретный информационный проект с 10 задачами. Для каждой задачи существует требуемый уровень вовлечённости специалиста (от 0 до 1) и фактический уровень, который определяется тем, есть ли такой специалист в штате отдела. Расстояние между требуемым и фактическим — это и есть энтропия рассогласования.

Рис. 2б. KL-расхождение на практике: 10 задач информационного проекта. Зелёные столбцы — требуемый уровень вовлечённости специалиста. Красные — фактический уровень, который может обеспечить отдел с фиксированным штатом. Оранжевые стрелки — энтропия рассогласования: чем больше разрыв, тем больше переделок, задержек, потерь.

Что показывает график

Обратите внимание на асимметрию. По трём задачам (Аналитика, Архитектура, Backend) отдел перепредоставляет ресурсы: фактическая вовлечённость выше требуемой. Это серые стрелки — избыток, который выглядит как «запас прочности», но на деле является нерациональным распределением: люди работают на задачах, где их компетенции избыточны, вместо того чтобы быть направленными на задачи, где они критически необходимы.

Одновременно по задачам UX/UI-дизайн ($\Delta = 0.55$), Безопасность ($\Delta = 0.45$), Интеграция ($\Delta = 0.40$) и DevOps ($\Delta = 0.40$) разрыв катастрофический — оранжевые стрелки. Отдел физически не может обеспечить требуемый уровень вовлечённости, потому что таких специалистов нет в штате. Это не вопрос «постараться больше» — это структурный дефицит, который невозможно компенсировать в рамках замкнутой структуры.

Именно эта асимметрия — избыток в одном месте, дефицит в другом — и есть энтропия замкнутой структуры. В сетевой команде специалисты перераспределяются по потребностям задачи: когда Backend-задача закрыта, разработчик переходит на интеграцию. В отделе каждый «сидит на своём месте» независимо от того, нужен он там сейчас или нет.

Суммарная энтропия рассогласования по всем 10 задачам:

$$D_{KL} = \sum_{i=1}^{10} p_i \log_2 \frac{p_i}{q_i} \approx 1.87 \text{ бит}$$

Это высокое значение: структура отдела покрывает лишь около 40% требований задачи. Остальные 60% — энтропия, которая проявляется как переделки, задержки, конфликты и потери качества.

Практический вывод

KL-расхождение можно использовать как диагностический инструмент: построить матрицу «требуемая vs фактическая вовлечённость» для каждого проекта и измерить суммарный разрыв. Если $D_{KL} \gt 1$ бит — проект структурно не может быть выполнен отделом без критических потерь. Если $D_{KL} \gt 2$ — гарантирован провал по срокам и бюджету. Это не экспертная оценка — это измеримая величина, которую можно рассчитать до начала проекта и принять решение о структуре команды на основе данных, а не интуиции.

Практическое значение KL-расстояния

$D_{KL}$ — это не теоретическая абстракция. Каждый бит рассогласования — это конкретные часы переделок, конфликтов, решений, которые приходится пересматривать. Чем больше $D_{KL}$, тем больше шум, тем ниже производительность. В приведённом примере суммарный разрыв по задачам UX/UI, Безопасность и Интеграция составляет более 1.3 бит — это означает, что только по этим трём задачам отдел гарантированно потеряет в 2–3 раза больше времени и бюджета, чем проектная команда с нужными специалистами.

Энтропия растёт со временем

Пока структура остаётся постоянной, а реальность — переменной, энтропия монотонно растёт. Это аналог второго начала термодинамики для информационных систем:

$$\frac{dH}{dt} \geq 0 \quad \text{пока } S = \text{const} \text{ и } R(t) \neq \text{const}$$

Остановить рост можно только одним способом: сделать структуру переменной — перейти к сетевому взаимодействию.

Комментарий: почему это важно на практике

Этот тезис объясняет один из самых распространённых феноменов в управлении информационными проектами: проект, который успешно стартовал, через 3–6 месяцев начинает буксовать. Не потому, что команда развалилась или исполнители «обленились». А потому, что за эти месяцы требования изменились, появились новые ограничения, обнаружились неучтённые связи — а структура отдела осталась той же. Энтропия накопилась до критического уровня.

Типичная реакция руководства — «нужно лучше планировать» или «нужно больше контроля». Но планирование и контроль — это попытки улучшить $q_i$ (ожидания структуры), не меняя саму структуру. Это как повышать дамбу против прилива: временно помогает, но прилив не остановить. Единственный способ — сделать структуру переменной, чтобы $q_i$ менялось вместе с $p_i$.

На практике это означает: если проект длится более 3 месяцев, состав команды обязан меняться. Те специалисты, которые были нужны на этапе аналитики, не нужны на этапе разработки. Те, кто нужен на этапе интеграции, не нужны на этапе проектирования. Фиксированный штат = фиксированное $q_i$ = растущая энтропия.

Рис. 2. Динамика энтропии. В замкнутой структуре (отдел) энтропия растёт, несмотря на улучшение процессов. В сетевом взаимодействии (сеть) энтропия стабильно низкая.

Нечёткие множества: когда границы структуры не совпадают с границами задачи

Классическая теория множеств работает с чёткими границами: элемент либо принадлежит множеству, либо нет. Но реальные инжиниринговые задачи не имеют чётких границ. Нечёткие множества (Заде, 1965) позволяют формализовать это размытие — и показать, откуда ещё возникает энтропия.

Нечёткое множество задачи

Инжиниринговую задачу можно описать как нечёткое множество $\tilde{A}$, в котором каждый элемент $x$ (подзадача, требование, ограничение) имеет степень принадлежности $\mu_{\tilde{A}}(x) \in [0, 1]$. Значение $\mu = 1$ означает «задача полностью определена», $\mu = 0$ — «задача не определена», промежуточные значения — «задача частично определена, нечётка».

$$\tilde{A} = \{(x,\; \mu_{\tilde{A}}(x)) \mid x \in X,\; \mu_{\tilde{A}}(x) \in [0, 1]\}$$

Нечёткое множество задачи: каждый элемент имеет степень определённости. В реальном проекте большинство элементов имеют $\mu < 1$ — задача нечётка.

Нечёткое множество структуры

Функциональную структуру тоже можно описать как нечёткое множество $\tilde{B}$: каждый элемент $x$ имеет степень покрытия $\mu_{\tilde{B}}(x)$ — насколько структура «готова» обработать эту подзадачу. В идеальном отделе $\mu_{\tilde{B}}(x) = 1$ для всех $x$. В реальности — далеко не для всех.

Энтропия как мера несовпадения нечётких множеств

Рассогласование между задачей и структурой — это разность нечётких множеств. Там, где $\mu_{\tilde{A}}(x) > \mu_{\tilde{B}}(x)$, задача требует больше, чем структура может дать. Разница — энтропия:

$$H_{\text{нечётк}} = \sum_{x \in X} \left[\mu_{\tilde{A}}(x) - \mu_{\tilde{B}}(x)\right]^2 \cdot \mu_{\tilde{A}}(x)$$

Энтропия нечёткого рассогласования: взвешенная сумма квадратов разностей. Вес — степень определённости задачи (чем задача актуальнее, тем больнее рассогласование).

Рис. 3. Нечёткие множества задачи ($\tilde{A}$) и структуры ($\tilde{B}$). Заштрихованные области — энтропия рассогласования: задача требует того, что структура не может дать.

Ключевая мысль

Задача — широкое нечёткое множество с размытыми границами. Структура отдела — узкое множество с чёткими границами. Область между ними — энтропия. Чем сложнее задача (больше $\tilde{A}$), тем больше энтропия. Чем жёстче структура (уже $\tilde{B}$), тем больше энтропия. Сетевое взаимодействие — это способ сделать $\tilde{B}$ таким же широким, как $\tilde{A}$.

Комментарий: нечёткость как практическая проблема

Нечёткость — это не «неопределённость», которую можно устранить «лучшим планированием». В информационных проектах нечёткость является фундаментальным свойством задачи. Требования к платформе формируются в процессе: пользователи не знают, чего они хотят, пока не увидят прототип. Архитектурные ограничения обнаруживаются при интеграции. Требования безопасности меняются с изменением регуляторных требований.

Попытка описать такую задачу чётким техническим заданием — это попытка превратить $\tilde{A}$ (нечёткое множество) в $A$ (чёткое). При этом неизбежно теряется информация: то, что не было описано в ТЗ, но существует в реальности, выпадает из рассмотрения. Это и есть энтропия нечёткости — потеря информации при попытке описать переменную реальность постоянным документом.

На практике это проявляется как «мы делали по ТЗ, а заказчик говорит, что не то». Заказчик прав: его требования были нечёткими, а ТЗ их «заморозило». Сетевое взаимодействие решает эту проблему иначе: команда работает не по замороженному ТЗ, а в режиме непрерывной обратной связи с заказчиком, адаптируя решение по мере прояснения требований.

Энтропия пересечения

Другой способ измерить рассогласование — через операцию пересечения нечётких множеств. Степень совпадения задачи и структуры:

$$\text{Совпадение} = \frac{\sum \min(\mu_{\tilde{A}}(x),\; \mu_{\tilde{B}}(x))}{\sum \mu_{\tilde{A}}(x)}$$

Если совпадение = 1 — структура полностью покрывает задачу. Если совпадение = 0.3 — 70% задачи не покрыто структурой. Это и есть энтропия: $H = 1 - \text{совпадение}$.

Топология коммуникаций: дерево vs сеть

Энтропия возникает из-за рассогласования структуры и реальности. Но почему отдел не может просто «подстроиться»? Потому что его топология коммуникаций этого не позволяет.

Функциональный отдел — это дерево: иерархия, в которой каждый узел связан только с начальником. Инжиниринговая задача требует сети: каждый участник должен иметь возможность обратиться к любому другому напрямую.

Рис. 4. Дерево (отдел): информация через иерархию, 66% потерь. Сеть (сетевое взаимодействие): прямая коммуникация, $\leq 30\%$ потерь.
Обозначения: Н — начальник, К — конструктор, Т — технолог, П — программист, М — менеджер, С — системный аналитик, О — обеспечение.

$$I_{\text{потеря}} = 1 - (1 - \alpha)^d \quad \text{где } \alpha \geq 0.3,\; d = \mathrm{diam}(T_n)$$

При $d=3$: потеря $\geq 66\%$. При $d=5$: потеря $\geq 83\%$. В сети ($d=1$): потеря $\leq 30\%$.

Комментарий: как это выглядит на практике

Потеря 66% информации — это не абстрактное число. Вот как это работает в реальном информационном проекте. Разработчик обнаруживает, что архитектурное решение, принятое архитектором, не учитывает ограничение фронтенда. В сетевой команде он поворачивается к фронтендеру и говорит: «У нас проблема, давай решим за 15 минут». В отделе он пишет заявку на имя начальника. Начальник пересылает её в другой отдел. Там начальник другого отдела поручает своему сотруднику. Тот отвечает через 3 дня. Ответ проходит обратный путь. К моменту, когда ответ доходит до разработчика, он уже потерял 30% содержания (передан через 3 посредников) и потратил 5–7 дней на коммуникацию, которая в сетевой команде заняла бы 15 минут.

Теперь умножьте это на десятки таких ситуаций в неделю. Каждая — мелкая. Но в сумме они составляют 30–50% бюджета проекта, уходящего на «координацию» и «согласование». Это и есть энтропия топологии — конкретные деньги и время, потерянные из-за того, что информация проходит через посредников вместо прямого контакта.

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

Закон Эшби: почему «улучшение процессов» не помогает

У. Росс Эшби (1956): разнообразие управляющей системы должно быть не менее разнообразия объекта управления. Функциональный отдел имеет низкое разнообразие (постоянное). Задача — высокое (переменное). После момента $t_{\text{крит}}$ разнообразие задачи превышает разнообразие структуры — и система теряет управляемость.

$$V_{\text{структуры}} = \text{const} \lt V_{\text{задачи}}(t) \quad \text{при } t \gt t_{\text{крит}}$$

Улучшение процессов отодвигает $t_{\text{крит}}$, но не отменяет его. Как повышать дамбу против прилива.

Комментарий: что такое «разнообразие» на практике

«Разнообразие» Эшби — это не метафора. Это количество различных состояний, которые система может принять. Отдел из 9 человек с фиксированными ролями имеет ограниченное разнообразие: каждый человек может выполнять одну-две функции, связи между ними фиксированы, процедуры регламентированы. Если задача требует компетенции, которой нет в штате (например, специалист по информационной безопасности с допуском ФСТЭК), разнообразие структуры физически не может покрыть разнообразие задачи.

На практике момент $t_{\text{крит}}$ наступает, когда требования проекта начинают выходить за рамки компетенций штатного состава. Для простых проектов (доработка существующей системы) это может не наступить никогда — разнообразие задачи невелико. Для сложных (создание новой платформы, интеграция с государственными системами, миграция легаси) $t_{\text{крит}}$ наступает через 2–4 недели после старта, когда обнаруживается, что для решения возникших проблем нужны специалисты, которых в штате нет.

Типичная реакция — привлечение подрядчиков. Но в замкнутой структуре подрядчик интегрирован плохо: он не знает контекста, не участвует в ежедневных стендапах, не имеет доступа к внутренним системам. Его разнообразие формально есть, но оно не интегрировано в разнообразие команды. В сетевом взаимодействии подрядчик — полноправный участник сети с прямым доступом ко всем. В отделе — внешний ресурс, который «подключают» через процедуры.

Энтропия стимулов: почему специалисты не кооперируются

В функциональном отделе каждый оценивается по показателям своей функции. Инжиниринг требует системной оптимизации. Теория игр описывает это как дилемму заключённого:

Табл. 1. Матрица выигрышей. Кооперация даёт +133%, но недостижима в замкнутой структуре.

Спец. 1 \ Спец. 2	Локальная оптимизация	Системная оптимизация
Локальная	(3, 3) — равновесие Нэша	(1, 5)
Системная	(5, 1)	(7, 7) — глобальный оптимум

Комментарий: почему равновесие Нэша устойчиво

Равновесие Нэша (3, 3) устойчиво, потому что ни один игрок не может улучшить свой результат в одиночку. Если конструктор перейдёт к «системной» стратегии, а технолог останется на «локальной», конструктор получит 1 вместо 3. Это рациональный страх, и никакие призывы к «командной работе» его не снимут — пока нет механизма, гарантирующего взаимность.

В информационном проекте это проявляется конкретно. Архитектор выбирает «красивую» архитектуру, которая оптимальна по его критериям (модульность, тестируемость), но неудобна для разработчиков (слишком много слоёв абстракции). Разработчик выбирает «быстрое» решение, которое оптимально по его критериям (скорость реализации), но неудобно для тестировщиков (нельзя автоматизировать тесты). Каждый действует рационально. Результат — система, которая ни модульная, ни быстрая, ни тестируемая.

В сетевой команде архитектор, разработчик и тестировщик сидят рядом и видят общий результат. Если архитектор выбирает «красивое» решение, разработчик сразу говорит: «Это добавит мне 2 недели». Архитектор корректирует решение. Это не «кооперация ради кооперации» — это прямая обратная связь, которая делает системную оптимизацию рациональной. Равновесие сдвигается от (3, 3) к (7, 7) не потому, что люди стали «добрее», а потому, что изменилась информационная структура взаимодействия.

Декомпозиция как источник энтропии

Отдел декомпозирует задачу: каждый получает свою подзадачу $f_i$ и оптимизирует её. Связи $g_{ij}$ отбрасываются:

$$F(x) = \sum_{i=1}^{n} f_i(x_i) + \sum_{i \lt j} g_{ij}(x_i, x_j) \qquad \xrightarrow{\text{декомпозиция}} \qquad \min_{x_i} f_i(x_i)$$

Потери: $\Delta F \geq \frac{1}{2}\sum g_{ij}^2 > 0$. Гарантированный проигрыш, растущий с числом связей.

Комментарий: что такое связи $g_{ij}$ в информационном проекте

Связи $g_{ij}$ — это не абстракция. В информационном проекте они конкретны: выбор базы данных ($x_1$) влияет на архитектуру API ($x_2$), архитектура API влияет на фронтенд ($x_3$), фронтенд влияет на UX ($x_4$), UX влияет на требования к безопасности ($x_5$). Каждая такая связь — это ситуация, где решение одного специалиста создаёт ограничения для другого.

Декомпозиция отбрасывает эти связи: каждый специалист получает свою подзадачу и оптимизирует её. Backend-разработчик выбирает базу данных, которая лучше всего подходит для его задачи. Фронтендер выбирает фреймворк, который лучше всего подходит для его задачи. Интегратор потом обнаруживает, что они несовместимы — и начинаются переделки. Это и есть $\Delta F$ — гарантированный проигрыш от декомпозиции.

Чем сложнее продукт, тем больше связей $g_{ij}$, тем больше потери. Для простого CRUD-приложения связей мало — декомпозиция работает приемлемо. Для платформы с десятками интеграций, сложной бизнес-логикой и требованиями к безопасности связей столько, что декомпозиция гарантированно даёт провал. Это объясняет, почему отделы справляются с простыми задачами и проваливаются со сложными — не из-за квалификации, а из-за числа связей.

Теорема о не-вложении: дерево не может заменить сеть

Можно ли «эмулировать» сетевую структуру внутри дерева — например, поручив начальнику отдела координировать все горизонтальные связи? Теорема показывает: нет, это невозможно без потерь.

Формулировка

Обозначим $G_P = (V_P, E_P)$ — сетевой граф проекта, где $E_P = E_{\text{vert}} \cup E_{\text{hor}}$ (вертикальные связи декомпозиции + горизонтальные связи координации). Обозначим $G_D = (V_D, E_D)$ — иерархическое дерево отдела глубины $h$ с максимальной степенью вершины $k_{\max}$.

Теорема (о не-вложении)

Произвольный сетевой граф $G_P$ с $|E_{\text{hor}}| \gt 0$ не может быть гомоморфно отображён в дерево $G_D$ без потери горизонтальных связей.

Идея доказательства

В дереве $G_D$ любой путь между двумя листьями проходит через их ближайшего общего предка — в конечном счёте через корень. Когда горизонтальная связь $e = (v_1, v_2)$ между двумя исполнителями проекта отображается в дерево, прямое горизонтальное соединение вырождается в цепочку «$v_1 \to$ предок $\to v_2$», создавая бутылочное горлышко на корне.

Практическое следствие

Любая попытка реализовать сетевую координацию внутри дерева перегружает корень — начальник отдела становится проводником всех горизонтальных связей, физически ограничивая пропускную способность. Чем больше параллельных горизонтальных связей, тем быстрее начальник «коллапсирует» как бутылочное горлышко. Это структурное ограничение, а не вопрос личной эффективности менеджера.

Рис. 5. Теорема о не-вложении: горизонтальные связи проекта (слева) не могут быть отображены в дерево отдела (справа) без вырождения в вертикальные цепочки через корень.

Модель многопроектной загрузки: теория очередей

Типичный «инжиниринговый отдел» одновременно ведёт от 3 до 7 проектов. Теория очередей Клейнрока позволяет точно рассчитать, при каком числе параллельных проектов отдел коллапсирует.

Формула деградации эффективности

Используя модель системы M/M/1, эффективность отдела при $n$ параллельных проектах:

$$\eta(n) = \frac{1}{1 + 0.35(n-1)^{1.3}}$$

$n$ — число параллельных проектов. 0.35 — коэффициент накладных расходов на переключение контекста и координацию. 1.3 — показатель нелинейного роста накладных расходов с увеличением межпроектных интерфейсов.

Ключевые значения

Табл. 5. Эффективность отдела в зависимости от числа параллельных проектов.

Проектов ($n$)	Эффективность $\eta$	Удвоение сроков	Оценка
1	1.00	Нет	Норма
2	0.79	Нет	Приемлемо
3	0.62	Нет	Снижение
4	0.48	Да (×2.1)	Критично
5	0.40	Да (×2.5)	Провал
6	0.35	Да (×2.9)	Коллапс
8	0.29	Да (×3.4)	Нежизнеспособно

Точка коллапса

При $n \geq 4$ параллельных проектах эффективность падает ниже 50% — сроки удваиваются. При $n \geq 6$ эффективность падает ниже 35% — проект становится нежизнеспособным. Это не вопрос квалификации сотрудников — это математическое следствие перегрузки системы.

Рис. 6. Кривая деградации эффективности отдела. При $n \geq 4$ проектах эффективность падает ниже 50% — сроки удваиваются.

Экономический парадокс: постоянные затраты vs переменные

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

Табл. 6. Сравнение бюджетов: проектная команда vs отдел (один проект, тыс. руб.).

Показатель	Проектная команда	Отдел	Разница
Состав	8 специалистов под задачу	9 постоянных сотрудников	—
Сроки	12 недель	27 недель	×2.25
Работы (ФОТ)	480	1 215	×2.53
Внешние ресурсы	0	200	—
Администрирование	48	150	×3.1
ИТОГО	528	1 565	×2.96

Экономический парадокс

Бюджет отдела в 2.96 раза выше, чем бюджет проектной команды, при худшем результате (27 недель вместо 12). Это не вопрос «эффективности» — это следствие несоответствия типа затрат (постоянные) типу работ (проектная логика). При многопроектной загрузке ($n \geq 2$) общие затраты отдела начинают превышать выручку, тогда как проектная модель с переменными затратами остаётся рентабельной при любом $n$.

Порочный цикл

Отдел не справляется с проектами из-за структурного дефицита компетенций → проекты проваливаются по срокам и качеству → решение: «нужно больше людей в штат» → ФОТ растёт → эффективность падает из-за роста накладных расходов и многопроектной перегрузки → новые провалы → ещё больше людей в штат. Этот цикл не разорвать добавлением штата — только сменой парадигмы.

Рис. 7. Порочный цикл «инжинирингового отдела». Выход — смена парадигмы: от постоянных затрат к переменным, от штата к сетевому взаимодействию.

Порог компетенций: 60% — точка невозврата

Для каждого проекта можно построить матрицу соответствия требуемых компетенций и имеющихся в отделе. Практика показывает: если перекрытие компетенций ниже 60%, проект обречён на 2–3-кратное превышение сроков и бюджета — независимо от квалификации сотрудников.

$$K_{\text{overlap}} = \frac{|\{\text{требуемые компетенции}\} \cap \{\text{имеющиеся компетенции}\}|}{|\{\text{требуемые компетенции}\}|} \times 100\%$$

Если $K_{\text{overlap}} \lt 60\%$ — отдел структурно не способен выполнить проект внутренними силами. Дефицит компетенций невозможно компенсировать «более старательной работой» имеющихся сотрудников.

Сетевое взаимодействие: структура, которая меняется вместе с задачей

Если энтропия возникает из-за несоответствия постоянного и переменного, то решение — сделать структуру переменной. Это и есть сетевое взаимодействие.

Сетевое взаимодействие — это способ организации, при котором структура коммуникаций определяется задачей, а не регламентом. Участники объединяются не по функциональному признаку, а по потребностям конкретного продукта. Структура перестраивается, когда меняется задача.

Функциональная структура

$S = \text{const}$, $\mathrm{diam} > 1$, $H(s) = \text{const}$, $\mu_{\tilde{B}}$ узкое. Энтропия растёт.

Сетевое взаимодействие

$S = S(t)$, $\mathrm{diam} = 1$, $H(s) = H_{\text{реальность}}(s)$, $\mu_{\tilde{B}}$ адаптивное. Энтропия минимальна.

Практика: информационные платформы как пример сетевого взаимодействия

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

Почему платформы нельзя делать в отделе

Платформа — это не программа и не документ. Это инфраструктура, которая должна одновременно удовлетворять множеству неопределённых и меняющихся требований: бизнес-процессы, данные, интеграции, пользовательский опыт, безопасность, масштабируемость. Требования не определены заранее — они формируются в процессе. Связи между подзадачами меняются на каждом этапе. Структура команды должна перестраиваться вместе с задачей.

Фундаментальное противоречие

Отдел имеет фиксированный состав специалистов. Платформа требует на каждом этапе разный набор компетенций. В начале — архитекторы и аналитики. В середине — разработчики и интеграторы. В конце — тестировщики и эксплуатационники. Штатный отдел не может менять свой состав каждый месяц.

Кейс 1 · Строительство информационной платформы управления проектами

Задача: единая платформа для управления портфелем строительных проектов

Заказчик — девелоперская компания с портфелем из 15–20 строящихся объектов. Задача: создать единую информационную платформу, которая объединяет данные о проектах, ресурсах, сроках, бюджетах, документах и рисках. Платформа должна интегрироваться с существующими системами (1С, AutoCAD, MS Project) и обеспечивать единую точку входа для руководства.

Состав команды по этапам

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

Табл. 2. Распределение трудоёмкости по этапам и ролям (человеко-месяцы). Источник: реальный проект, обезличен.

Роль	Этап 1: Анализ (2 мес.)	Этап 2: Архитектура (2 мес.)	Этап 3: Разработка (6 мес.)	Этап 4: Внедрение (3 мес.)	Всего
Бизнес-аналитик	4.0 (67%)	2.0 (25%)	1.5 (8%)	1.0 (11%)	8.5
Архитектор	0.5 (8%)	3.5 (44%)	2.0 (11%)	0.5 (6%)	6.5
Разработчик	0 (0%)	1.5 (19%)	10.0 (56%)	2.0 (22%)	13.5
Интегратор	0.5 (8%)	0.5 (6%)	3.0 (17%)	3.0 (33%)	7.0
Тестировщик	0 (0%)	0 (0%)	1.5 (8%)	2.5 (28%)	4.0
Всего	5.0	8.0	18.0	9.0	40.0

Визуализация: как меняется распределение работ

Этап 1: Анализ — доминирует бизнес-аналитик

Аналитик

67%

Архитектор

Разработчик

Интегратор

Этап 3: Разработка — доминируют разработчики

Аналитик

Архитектор

11%

Разработчик

56%

Интегратор

17%

Этап 4: Внедрение — доминируют интеграторы и тестировщики

Аналитик

11%

Разработчик

22%

Интегратор

33%

Тестировщик

28%

Что это значит для структуры

Штатный отдел с фиксированным составом не может обеспечить такое распределение. Если в отделе 3 разработчика и 1 аналитик, то на этапе анализа 3 разработчика простаивают (или занимаются не своим делом), а аналитик перегружен. На этапе разработки аналитик простаивает, а разработчиков не хватает. На этапе внедрения ни тех, ни других не хватает — нужны интеграторы и тестировщики, которых в отделе нет.

Сетевое решение: Команда формируется под задачу и перестраивается на каждом этапе. На этапе анализа — 2 аналитика + 1 архитектор. На этапе разработки — 4 разработчика + 1 интегратор. На этапе внедрения — 2 интегратора + 2 тестировщика. Люди приходят и уходят из сети по мере необходимости. Структура переменна, как и задача.

Кейс 2 · Платформа цифрового двойника производства

Задача: создание цифрового двойника для управления производственными процессами

Заказчик — машиностроительное предприятие. Задача: создать цифрового двойника — информационную модель производства, которая получает данные от оборудования в реальном времени, прогнозирует отказы, оптимизирует загрузку и позволяет моделировать сценарии.

Почему штатный отдел не справился

Первая попытка: задача передана в отдел автоматизации (8 человек: 3 программиста, 2 инженера АСУ, 2 электрика, 1 начальник). Результат через 12 месяцев: интерфейс для просмотра данных с одного станка. Ни прогнозирования, ни моделирования, ни интеграции.

Анализ через нечёткие множества

Задача $\tilde{A}$: множество элементов с высокой степенью неопределённости. Требования к данным ($\mu = 0.6$ — формат не определён), к алгоритмам ($\mu = 0.3$ — неизвестно, какие модели работают), к интеграции ($\mu = 0.4$ — протоколы оборудования различаются), к UX ($\mu = 0.2$ — пользователи не знают, что хотят).

Структура отдела $\tilde{B}$: узкое множество. Программисты покрывают только разработку ПО ($\mu = 0.9$). Инженеры АСУ — только оборудование ($\mu = 0.7$). Никто не покрывает: алгоритмы машинного обучения ($\mu = 0$), UX-дизайн ($\mu = 0$), работу с большими данными ($\mu = 0$), предметную область производства ($\mu = 0.2$).

$$\text{Совпадение} = \frac{\sum \min(\mu_{\tilde{A}}, \mu_{\tilde{B}})}{\sum \mu_{\tilde{A}}} \approx 0.25$$

Структура покрывает лишь 25% задачи. 75% — энтропия рассогласования.

Сетевое решение

Вторая попытка: сформирована сетевая команда из 12 человек на 8 месяцев. Состав менялся на каждом этапе:

Табл. 3. Состав сетевой команды по этапам (изменение = перестройка сети).

Специалист	Мес. 1–2	Мес. 3–5	Мес. 6–7	Мес. 8
Архитектор данных	●	●
Специалист по оборудованию	●	●	●
Data Scientist		●	●
Разработчик (backend)		●	●	●
Разработчик (frontend)			●	●
UX-дизайнер	●		●
Технолог производства	●	●	●	●
Тестировщик			●	●

Результат: Полноценный цифровой двойник за 8 месяцев. Прогнозирование отказов (точность 87%), оптимизация загрузки (рост на 15%), моделирование сценариев. Стоимость: сопоставима с 12 месяцами работы отдела, но результат — несопоставим.

Кейс 3 · Провал: Healthcare.gov

$1.7 млрд потрачено, система не работала

55 подрядчиков работали по отдельным ТЗ. $\binom{55}{2} = 1485$ межфункциональных связей — все проигнорированы. Ни одной интеграционной тестовой сессии. Система выдержала 6 одновременных пользователей.

Энтропия: Максимальная энтропия декомпозиции. Каждая неучтённая связь = потерянный бит = переделка. Стоимость исправления превысила стоимость разработки.

Источник: GAO-14-354, 2014.

Кейс 4 · Успех: Toyota Production System

Сетевое взаимодействие как стандарт

Toyota построила систему, в которой энтропия минимальна: кросс-функциональные команды ($\mathrm{diam}=1$), Andon (обратная связь от реальности), Kaizen (непрерывное улучшение), Gemba (решение на месте). Структура переменна, как и задача. Результат: #1 автопроизводитель мира.

Кейс 5 · Внедрение CRM-системы (500–1000 пользователей)

Требуемая команда: 10 специалистов. Отдел: 9 штатных. Перекрытие компетенций: ~50%

Типичный информационный проект: внедрение CRM-системы для крупной компании. Требуется: бизнес-аналитик, архитектор, 2 backend-разработчика, 1 frontend, DevOps, UX/UI-дизайнер, 2 QA, проектный менеджер с опытом CRM.

Отдел располагает: 4 универсальных разработчика, 2 бизнес-аналитика, 1 архитектор, 1 «менеджер», 1 сисадмин, совмещающий DevOps. Критические пробелы: frontend (0), UX/UI-дизайнер (0), PM с опытом CRM (0).

Хронология провала: Недели 1–2 — дизайнера нет в штате, привлечение подрядчика занимает 3 недели. Недели 1–4 — сисадмин мучается с CI/CD, требуется внешний DevOps (+200 тыс. руб.). QA растянут на 3 других проекта — 2-недельный цикл тестирования превращается в 6 недель. Функции PM распределены между начальником отдела и архитектором, ни один из которых не имеет CRM-опыта.

Результат: 12-недельный проект растягивается на 32 недели (8 месяцев). Бюджет: 2.8 млн руб. вместо запланированных 1.2 млн. 30% дефектов обнаружены только в продакшене. Структурный диагноз: 50% перекрытие компетенций гарантирует 2–3-кратное превышение сроков и бюджета независимо от усилий сотрудников.

Кейс 6 · Разработка мобильного приложения

Профессиональный подход vs «что есть в штате»

Табл. 7. Сравнение: проектная команда vs отдел при разработке мобильного приложения.

Параметр	Проектная команда (Native)	Отдел (React Native, 1 разработчик)
Команда	6 специалистов	1 (backend-разработчик)
Срок MVP	16 недель	20 недель
Производительность	60fps, плавные анимации	15fps, рывки
Crash rate	\lt 0.5%	4–7%
App Store review	Прошли с первого раза	Отклонено 3 раза
Итог	Продакшен	Переписка на native (+4 мес., +1.5 млн)

Результат: 9 месяцев потерянного времени и 2.5 млн руб. перерасхода. Ошибка структурная: попытка заменить отсутствующие компетенции (iOS, Android) «более дешёвой» универсальной технологией (React Native), не понимая, что кроссплатформенная разработка требует своих компетенций. Проблема не в React Native как инструменте, а в подмене проектной логики «тем, что есть в штате».

Кейс 7 · Интеграция с государственными системами (ЕСИА, Госуслуги, ЕГРЮЛ)

Экономика штрафов: «экономия» на специалистах обходится в 10×

Этот тип проекта требует: специалиста по ИБ с действующим допуском ФСТЭК, юриста с экспертизой 152-ФЗ, архитектора защищённого периметра, криптографа (СКЗИ, шифрование по ГОСТ).

Отдел назначает: «лучшего программиста, который что-то слышал про OAuth 2.0». Юридическое сопровождение — общему юридическому отделу без экспертизы 152-ФЗ. ИБ — формально человеку, который на деле управляет антивирусными политиками.

Последствия: Утечка персональных данных → нарушение ст. 13.11 КоАП → штрафы 75–300 тыс. руб. (первый раз), до 1 млн (повторно), до 18 млн (массовая утечка, или 3% выручки с 2025 г.). Обязательное уведомление Роскомнадзора в течение 24 часов + пострадавших в течение 3 дней. Архитектура, спроектированная без требований ФСТЭК/152-ФЗ, не проходит сертификацию. Переработка: 3–6 месяцев и 1.5–3 млн руб. — «экономия на специалистах» превращается в 10-кратные потери.

Критический риск

Попытка выполнить проект с регуляторными требованиями без соответствующих компетенций — это не экономия, а перенос расходов из фонда оплаты труда в категорию штрафов и переделок.

Кейс 8 · Миграция легаси-системы (COBOL/Oracle Forms → Java/Kotlin + React + Kubernetes)

Проект на 6–9 месяцев превращается в 18–24 месяца

Профессиональная команда: специалист по COBOL (реверс-инжиниринг существующего кода), инженер миграции данных ETL, архитектор целевой системы, 3–4 современных backend-разработчика, 2 frontend, DevOps, специалист по тестированию миграции. Срок: 6–9 месяцев.

Отдел: специалиста по COBOL нет, экспертизы Oracle Forms нет («слишком старые технологии, не нанимаем»). Архитектор предлагает «переписать всё с нуля по документации» — но документация в 80% случаев либо не существует, либо не соответствует коду, либо описывает 15-летнюю версию. DevOps/сисадмин не имеет опыта с Kubernetes или CI/CD для параллельных сред.

Результат: 4 недели на развёртывание тестового кластера, 2 недели диагностики сетевых политик, 3 недели на синхронизацию данных. Координация с 5 смежными отделами добавляет 1–2 недели на каждый интерфейс. Проект на 6 месяцев профессиональной командой растягивается на 18–24 месяца. Бюджет: 12–18 млн руб. вместо запланированных 4–6 млн. 20–30% бизнес-функций реализованы некорректно. Штрафные санкции: 5–15% стоимости контракта. Репутационный ущерб: 1–3 года на восстановление доверия рынка.

Структурная причина: Отсутствие специалистов по мигрируемой технологии. Нанять таких специалистов в штат неэкономично (технология умирает). Единственная рабочая модель — проектная команда с подрядчиками — структурно недоступна для отдела с бюджетом ФОТ.

Сводка: источники энтропии и способы её снижения

Табл. 4. Источники энтропии в замкнутой структуре и способы их устранения через сетевое взаимодействие.

Источник	Механизм	Модель	Сетевое решение
Топология	Потеря информации $\geq 66\%$	Теория графов	Прямая коммуникация ($\mathrm{diam}=1$)
Замкнутость	Нет обратной связи от реальности	Системная теория	$H(s)=H_{\text{реальность}}(s)$
Нечёткость	$\mu_{\tilde{B}} \ll \mu_{\tilde{A}}$ — структура не покрывает задачу	Нечёткие множества	Адаптивное $\mu_{\tilde{B}}(t) \approx \mu_{\tilde{A}}(t)$
Стимулы	Локальная оптимизация (3,3)	Теория игр	Общий критерий — результат продукта
Декомпозиция	Отбрасывание связей $g_{ij}$	Мат. программирование	Глобальная оптимизация
Разнообразие	$V_{\text{стр}} \lt V_{\text{зад}}$ после $t_{\text{крит}}$	Закон Эшби	$V_{\text{сети}}(t)=V_{\text{зад}}(t)$
Состав	Фиксированный набор компетенций	Практика платформ	Состав перестраивается по этапам
Не-вложимость	Горизонтальные связи вырождаются в вертикальные	Теория графов (теорема)	Прямые горизонтальные связи в сети
Многопроектность	$\eta(n) \lt 0.5$ при $n \geq 4$	Теория очередей	Команда под один проект
Экономика	Бюджет отдела ×2.96 от проектного	Экономическая модель	Переменные затраты под задачу

Выводы

Любая функциональная структура условно-постоянна. Действительность переменна. Соотношение постоянного и переменного неизбежно создаёт энтропию — шум, который съедает производительность и эффективность.

Энтропия возникает из десяти независимых источников: топология коммуникаций, замкнутость системы, нечёткость границ задачи, структура стимулов, декомпозиция, недостаточное разнообразие, фиксированный состав, не-вложимость сетевого графа в дерево (теорема), многопроектная перегрузка (теория очередей), несоответствие типа затрат (постоянные vs переменные). Ни один из них не может быть устранён в рамках замкнутой структуры.

Практика создания информационных платформ показывает: состав команды должен меняться на каждом этапе, связи между участниками должны перестраиваться вместе с задачей, критерий должен быть единым для всех. Это возможно только в сетевом взаимодействии.

Практическая рекомендация

Для инжиниринговых задач — и особенно для создания информационных платформ — необходимо сетевое взаимодействие: динамическая структура, которая перестраивается вместе с задачей. Состав команды определяется потребностями этапа, а не штатным расписанием. Коммуникация прямая, а не через иерархию. Критерий — результат продукта, а не показатели функции. Только так можно сделать структуру переменной, как и реальность, — и снизить энтропию до минимума.

Примечания

¹ Потеря информации $\alpha=0.3$ на уровень — консервативная оценка (Allen, 1977).

² Данные по трудоёмкости (табл. 2–3) — обезличенные данные реальных проектов.

³ Применение нечётких множеств к организационным структурам — авторская интерпретация на основе (Заде, 1965).

Литература

Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423.
Zadeh, L. A. (1965). Fuzzy Sets. Information and Control, 8(3), 338–353.
Ashby, W. R. (1956). An Introduction to Cybernetics. Chapman & Hall.
Allen, T. J. (1977). Managing the Flow of Technology. MIT Press.
Nash, J. F. (1950). Equilibrium Points in N-Person Games. PNAS, 36(1), 48–49.
Kullback, S., & Leibler, R. A. (1951). On Information and Sufficiency. Annals of Mathematical Statistics, 22(1), 79–86.
Wiener, N. (1948). Cybernetics. MIT Press.
Kleinrock, L. (1975). Queueing Systems, Vol. 1: Theory. Wiley.
Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28–31.
Brooks, F. P. (1975). The Mythical Man-Month. Addison-Wesley.
Mintzberg, H. (1979). The Structuring of Organizations. Prentice-Hall.
Kerzner, H. (2017). Project Management: A Systems Approach. Wiley.
U.S. GAO (2014). HEALTHCARE.GOV. GAO-14-354.
Liker, J. K. (2004). The Toyota Way. McGraw-Hill.
Browning, T. R. (2001). Applying the Design Structure Matrix. IEEE Trans. on Eng. Management, 48(3), 292–306.
Eppinger, S. D., & Browning, T. R. (2012). Design Structure Matrix Methods. MIT Press.
Goldratt, E. M. (1997). Critical Chain. North River Press.