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

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

Это как устроен мир.

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

Почему изнутри это не видно. Три механизма.

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

Второй — функциональная модель умеет объяснять свои провалы своими же словами. Заявка зависла — «нагрузка на поддержку». Документ потерял юридическую силу — «пользователь ошибся». Стратегия не реализуется — «нет ресурсов». У каждого провала есть удобное локальное объяснение, которое не требует смотреть на архитектуру. Модель сама выдаёт себе оправдательные документы. Система, которая ошибается по своей структуре, получает отчёты, в которых ошибся конкретный человек.

Третий — метрики сделаны из той же оптики. KPI закрытых заявок, SLA по функциям, загрузка отделов — все показатели прекрасно выглядят. Заявки закрываются. Отделы работают. Панели светятся зелёным. И пока метрики зелёные, у руководителя нет ни одного числа, которое говорило бы: «у вас уничтожено 2400 документов с юридической силой за год» — потому что эта цифра в функциональной модели не считается. Она не входит ни в один отчёт. Система учёта не умеет считать несозданное и незакрытое — а всё остальное у неё в порядке.

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

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

В функциональной модели ответ на этот вопрос — тишина. Не потому, что никто не хочет отвечать. Потому что за целое не отвечает никто — по конструкции.

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

Я видела оба. 26 лет управляю критическими информационными системами — и прошла путь от функциональной модели, где заявки ходят по кругу, до интегративной, где тяжёлый сбой на стыке сетей, криптографии и документооборота решается за 15 минут, а система работает без единого инцидента с правовыми последствиями. Разница — не в людях. Люди те же. Разница — в точке, где сходятся все функции и вся ответственность.

Подробный разбор обеих моделей — с цифрами двух кейсов (20 000+ пользователей в госсекторе, 15 000+ в бизнесе) — в моей статье: Борисовская И. В. Модели управления критически важными информационными системами: факторы эффективности и причины деградации. Zenodo, 2026. DOI: 10.5281/zenodo.23186355. https://doi.org/10.5281/zenodo.23186355

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

#управление #функциональнаямодель #бизнес-процессы #ITменеджмент #критическиесистемы #экспертизаборисовской