директор и машина · операционное управление · запись № 009 · 21 июня 2026 · Давид Герштейн

Регламенты, которые читают: от полки к инструменту

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

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

Регламенты в компании: почему документ не работает без расписания

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

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

Механика по шагам: как регламент проходит путь от сбоя до инструкции

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

1. Фиксация сбоя. Руководитель или сам сотрудник замечает повторяющуюся проблему — перебивания, разные цифры в отчётах, зависшую задачу. Источник — жалоба, наблюдение на планёрке, разбор конкретного провала.
2. Первая попытка действия без инструкции. Сотрудник выполняет задачу как умеет. Результат почти всегда неидеальный — это ожидаемо, а не повод для штрафа.
3. Фиксация действия. Каждое новое действие либо документируется текстом, либо записывается на диктофон для расшифровки. Формат неважен — важно, что попытка не исчезает бесследно.
4. Повторение и разбор ошибок. Формула трёх итераций: неправильно — неправильно — правильно. После третьего раза, когда результат устраивает, действие проверяют ещё раз на воспроизводимость.
5. Закрепление инструкцией. Если третья попытка сработала — действие фиксируют как регламент и не проверяют его вручную каждый раз заново. Дальше его соблюдение можно передать на автоматическую проверку.
6. Точка контроля. Кто-то — руководитель, проект-менеджер, бот — периодически сверяет, что регламент всё ещё выполняется так, как закреплён, а не «как удобнее сегодня».

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

Стандартизация процессов: когда данные и роли расходятся

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

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

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

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

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

Где регламент подменяют профилем личности

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

ИИ-связка: автоматическая проверка соблюдения регламента

Ручная проверка регламентов — та же проблема, что и ручное заполнение отчётов: она съедает время того, кто мог бы заниматься содержательной работой. В одной из команд её решили так же, как проверку контента: автор загружает документ на Google Диск, триггер запускает скрипт, отчёт о соответствии приходит в Telegram. Теперь не нужно вручную перечитывать многостраничные документы ради формальных пунктов.

Логика переносится на регламенты почти без изменений. Схема конвейера:

Google Диск (папка «Регламенты на проверку») → триггер Apps Script → запрос к модели с текстом документа и чек-листом → результат в Google Таблицу и Telegram-чат ответственного → раз в неделю руководитель просматривает сводку отклонений.

Для этой задачи не нужна дорогая модель. В одной из команд заметили, что дорогая модель (Opus) и более дешёвая (Sonnet) дали идентичный результат на одном и том же промпте — разница была только в цене токенов. Проверка регламента по чек-листу — задача классификации, а не творческого рассуждения, поэтому дешёвая модель здесь справляется так же надёжно. Прикинуть свою экономию можно так: число проверяемых документов в месяц × разница в цене токенов между моделями на один прогон = экономия в месяц. Если прогонять несколько десятков регламентов в месяц, а разница в цене между дорогой и дешёвой моделью на один прогон невелика (оценка, зависит от длины документа), суммарная экономия на токенах будет скромной. Основной эффект здесь не в деньгах на токены, а в том, что дешёвую модель не жалко гонять чаще и по большему числу документов.

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

Входные данные (JSON):
{
  "document_text": "полный текст регламента или инструкции",
  "role": "название должности или процесса",
  "checklist": [
    "время выполнения действия указано явно",
    "ответственный за выполнение назван по роли",
    "точка контроля обозначена (кто и когда проверяет)",
    "результат сформулирован измеримо"
  ]
}

Задача:
1. Проверь текст построчно на соответствие каждому пункту чек-листа.
2. Если пункт отсутствует или сформулирован расплывчато — укажи,
   в каком разделе документа его нужно добавить или уточнить.
3. Не переписывай документ целиком — только точечные замечания.
4. Не придумывай пункты, которых нет в чек-листе.
5. Ответ верни строго в формате JSON, без пояснений вне JSON.

Формат ответа:
{
  "pass": true/false,
  "missing_points": ["..."],
  "comments": [
    {"point": "...", "location": "...", "suggestion": "..."}
  ]
}

На практике здесь достаточно модели уровня Sonnet или GPT-4o-mini — при регулярных проверках экономия на токенах ощутима именно за счёт объёма, а качество результата не проседает.

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

{
  "pass": false,
  "missing_points": ["точка контроля обозначена"],
  "comments": [
    {
      "point": "точка контроля обозначена",
      "location": "раздел «Оплата счетов»",
      "suggestion": "указать, кто и в какое время проверяет факт оплаты"
    }
  ]
}

Инженерная обвязка. Скрипт крутится на Google Apps Script, привязан к папке на Google Диске, срабатывает по событию добавления или изменения файла. Результат пишется в Google Таблицу (журнал проверок по датам) и дублируется сообщением в Telegram-чат ответственного за регламент. Если вызов модели падает — таймаут или лимит квоты — файл помечается тегом «ошибка проверки», в Telegram уходит текст ошибки, повторный запуск можно поставить по расписанию раз в час или запускать вручную кнопкой в таблице. Никакой самостоятельной эскалации бот не делает — решение о доработке документа всегда принимает человек.

Где регламенты ломаются: разрыв между тем, кто пишет, и тем, кто строит

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

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

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

Экономика регламентов: что это стоит и что даёт

Стоимость внедрения одного формального регламента невысокая: 1–2 часа на разбор сбоя и формулировку правила, ещё 1–2 часа на настройку автоматической проверки, если она нужна. Основные затраты — не деньги, а дисциплина: кто-то должен зафиксировать первую попытку, разобрать три итерации и довести дело до закреплённой инструкции.

Отдельно считается цена отсутствия регламента — там, где есть конкретные цифры из практики. Общая логика одна: время потерь в день × ставка часа × число рабочих дней в месяце = потери в месяц (оценка); ставку и часы потерь стоит подставлять свои, взяв консервативную оценку.

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

Последняя строка таблицы — отдельный сюжет: за месяц число оплаченных коммуникационных каналов выросло в несколько раз, хотя число сотрудников, которые реально ими пользовались, за это время почти не изменилось. При типичной цене подписки за каждый подключённый канал (WhatsApp или Telegram на сотрудника) формула простая: число каналов × цена канала = месячные затраты на связь. Прирост затрат от такого бесконтрольного роста легко доходит до суммы, сопоставимой с месячным окладом сотрудника, — при том что реальных пользователей почти не прибавилось. Причина — не злой умысел, а отсутствие регламента: подключение нового канала не требовало согласования, поэтому каждый добавлял себе WhatsApp и Telegram по мере желания. Такой риск не виден в моменте — он всплывает только на аудите.

Более крупный пример — из документооборота. Два специалиста, готовящие договоры, работают на износ, включая выходные, потому что менеджеры сами не готовят документы, а поток лидов растёт. Формула для своего случая: число менеджеров × доля зависших из-за документов сделок × средний чек = потери выручки в месяц. Если условно взять отдел из нескольких менеджеров с типичным для отрасли средним чеком сделки и предположить, что заметная доля сделок зависает именно из-за задержки в подготовке документов — не из-за клиента, а из-за отсутствия регламента приоритизации в документообороте, — набегает риск незакрытой или отложенной выручки, сопоставимый по масштабу с фондом оплаты труда всего отдела за месяц (оценка). Регламент здесь не отменяет нехватку рук, но переводит вопрос из «все горят» в конкретное решение: выделенный сотрудник с оплатой за задачу-результат либо распределение между свободными людьми по чёткому правилу очерёдности.

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

Регламент соответствия: правило, которое не пишут в должностной инструкции

Есть ещё один тип регламента, который редко формулируют письменно, но который держит всю систему. Собственник одной компании сформулировал его так: «Вы должны развиваться с бизнесом. В тот момент, когда бизнес вас обогнал — всё. В тот момент, когда вы не соответствуете бизнесу — всё». Это не про должностные обязанности, а про условие, при котором вся остальная стандартизация имеет смысл: сотрудник, который перестал расти вместе с процессами, рано или поздно станет узким местом, сколько бы инструкций для его роли ни было написано.

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

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

Чек-лист: с чего начать в понедельник

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

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

Частые вопросы

Чем должностная инструкция отличается от регламента?

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

Как понять, что регламент не работает?

Если один и тот же запрос к системе или отделу даёт разные ответы — три версии списка клиентов, три трактовки одной задачи — регламента фактически нет, даже если документ существует на бумаге.

Можно ли проверять соблюдение регламента с помощью ИИ?

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

#автоматизация #контроль и надёжность #ошибки и провалы