Организация как код: почему автоматизация есть, а эффективности нет

Год назад CEO NVIDIA Дженсен Хуанг заговорил об автоматизации с помощью ИИ-агентов — цифровых сотрудников, которые могут выполнять рутинные действия менеджера среднего звена. Сейчас NVIDIA перевела уже 30 тыс. инженеров на инструменты с ИИ-поддержкой — по данным компании, объем выполненной работы утроился при тех же затратах. Это уже не эксперименты, а новая реальность, в которой выигрывает тот, кто умеет делать больше теми же ресурсами.

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

Три правды одной компании

В любой организации работа описана в трех местах — и эти описания не совпадают между собой.

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

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

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

И дело не в том, что сотрудники — плохие профессионалы, а руководители их недостаточно контролируют. Это проблема формата. Регламент в текстовом документе не может быть одновременно актуальным, проверяемым и исполнимым. Он устаревает в тот момент, когда его закончили писать.

Правила вместо задач: как перейти на новый уровень управления

Представьте холодильник. Можно каждый день записывать себе задачу «купить молоко». А можно ввести простое правило: «молоко в холодильнике есть всегда». Если молока нет — срабатывает триггер, на смартфон приходит куча уведомлений, звучит сирена и не успокаивается, пока пакет не появится. Если есть — все спокойно.

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

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

Такие правила называют инвариантами — от латинского invariantis, «неизменный». Это записанные в системе алгоритмы, которые должны соблюдаться как абсолютная истина, эталон. Задачи при таком подходе — уже не цель, а следствие: инвариант нарушен — появилась задача. Такой подход позволяет перейти от реактивного управления («случилось — разбираемся») к проактивному («система следит, чтобы не случилось»).

Два слоя работы любой компании

Любое подразделение делает два типа работы.

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

Второй — работа-гарантия. Это работа невидимая и часто рутинная — ее никто не заказывает, но она должна выполняться. Отдел продаж должен следить, чтобы ни один лид не остался без ответа. HR — чтобы ни один кандидат не ждал обратной связи неделями. Закупки — чтобы ни один контракт не истек незаметно. Эта работа живет в голове конкретного человека, который «просто знает», что каждый понедельник нужно проверять реестр. Когда этот человек уходит — знание пропадает вместе с ним.

Я называю этот подход Organization as Code — «организация как код» — попыткой записать оба слоя работы каждого подразделения в формате, который будет понятен и человеку, и корпоративной системе. Так, чтобы если правило не выполняется, можно было эскалировать ситуацию, а не узнавать о проблеме постфактум.

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

Это разница между «в доме стоит огнетушитель» и «в доме работает пожарная система: датчики, оповещение, план эвакуации, и мы точно знаем, что все проверено». Огнетушитель — полезная вещь, но он стоит там, где кто-то однажды догадался его поставить. А пожарная система покрывает здание целиком.

Что видит руководитель, когда правила записаны

Когда все обязательства подразделения оцифрованы и заведены в системе, руководитель видит не размытое «у нас все ок», а конкретный статус по каждому правилу. Зеленый — правило выполняется. Желтый — есть отклонение, но в допустимых рамках. Красный — нарушение, система уже реагирует.

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

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

Когда в эту модель вписывается ИИ

Если правила подразделения описаны, проверяемы и исполнимы, в модели появляется естественное место для ИИ-агентов. Не «внедрить нейросеть и посмотреть, что получится», а делегировать агенту конкретную работу с понятными границами.

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

Важно, что уровень делегирования определяет не разработчик ИИ-решения, а сама компания — исходя из своих правил, рисков и готовности доверять автоматизации. Organization as Code дает для этого конкретную рамку: правила описаны, границы понятны, ответственность закреплена. Без такой рамки делегирование превращается в лотерею.

Как понять, что компании пора менять подход

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

Первый: вы не можете за пять минут ответить на вопрос «какие обязательства выполняет каждое подразделение и все ли они сейчас в порядке?» — без звонков, писем и совещаний.

Второй: при увольнении ключевого сотрудника команда несколько недель восстанавливает, «как он это делал», а часть знаний теряется безвозвратно.

Третий: вы периодически узнаете о проблемах постфактум — истек контракт, потерялся лид, просрочена проверка, — хотя все данные были в системе.

Четвертый: у вас есть регламенты, но никто не может гарантировать, что они описывают реальность, а не позапрошлогоднюю версию процесса.

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

Не новая бюрократия, а замена старой

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

Цифровая зрелость компании определяется не количеством систем и не суммой, потраченной на ИТ. Она определяется тем, насколько быстро компания может дать точный ответ на простой вопрос: «Что у нас сейчас происходит на самом деле?» Если для ответа нужны три совещания, два отчета и звонок тому, кто «в теме», — зрелости пока недостаточно. Если ответ на экране за пять минут — компания готова к следующему шагу, включая ИИ-агентов.

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