Абсолютная актуальность регламентов

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

Они устаревают к моменту согласования. ИТ-системы почти никогда не задокументированы. Описания бизнес-процессов AS IS — в лучшем случае на треть. А то, что описано, пылится в вики и никому не нужно, пока не пришёл аудит. В крупных компаниях это тысячи документов.

Но мир изменился, и P6 — прямое следствие предыдущих принципов. Регламенты — это часть единого контекста (P2). А значит, они доступны агентам и улучшаются агентами.

Три роли агентов по отношению к регламентам

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

Улучшатель анализирует процесс и предлагает изменения (P5). Ему нужно видеть текущие правила, чтобы понять, что работает, а что нет.

Методолог фиксирует изменения в регламентах. То, на что раньше уходили месяцы подготовки, выверки и согласований, теперь занимает минуты генерации плюс проверку ответственным сотрудником (P1) — вероятно, тоже со своим агентом.

Экономика переворачивается:

Раньше	Теперь
Дорого создавать	Дёшево создавать
Бесполезно использовать	Критично для работы

Что я делаю на практике

В PM-системе при закрытии инкремента агент автоматически обновляет документацию, реестры и решения — команда /close-increment. Документация живая ровно потому, что обновляется тем же действием, что и сама работа, а не отдельным этапом «потом задокументируем».

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

Команда OpenAI пошла дальше: CI автоматически проверяет структуру и актуальность базы знаний, а специальный агент doc-gardening открывает PR на коррекцию устареваний. Документация там — не побочный продукт, а инфраструктура.

Ключевое наблюдение

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

Значит, проблема не в отсутствии знания о процессе. Проблема в том, что оно не оцифровано.

Создание договорённости о работе — это тоже акт изменения, артефакт деятельности, который должен стать доступным контекстом (P2). Это помогает не только агентам, но и людям.

Регламент и спецификация — один жанр

Есть ещё один поворот, который становится виден только в агентном контуре.

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

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

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

Что это значит на практике

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

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

Артефакты: автопроверки регламентов, SLA обновления, карта связей между процессами и документами.

Показатели: время от изменения процесса до обновления регламента; доля артефактов, прошедших проверки; объём обнаруженного drift.

Анти-паттерны: «документ написан = вопрос закрыт»; редкие ручные ревизии без автоматизации.

Со стороны ценности

В чём выгода. Исчезает скрытая переделка из-за устаревших инструкций и снимается недоверие к документам («там всё равно неправда»). Живой регламент дешевле поддерживать маленькими шагами, чем разгребать накопленный долг.

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

Что легко переоценить. Что регламенты можно дописать потом. Долг здесь копится незаметно и дорожает.

Дёшево проверить. Откройте три ключевых регламента и сверьте с тем, как процесс идёт на самом деле.

Итог и переход

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

Без актуальных регламентов автоулучшение (P5) превращается в хаос: агент оптимизирует процесс, который уже не существует.

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