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

«Если бы я не пришёл, ничего бы не произошло»: внедрение автоматизации процессов без надзора

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

У меня есть личный тест на настоящую автоматизацию, и я собираюсь им поделиться, потому что он экономит деньги ещё на этапе постановки задачи. Тест звучит так: что произойдёт, если про этот процесс все забудут на две недели?

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

Как я к этому пришёл

История, после которой тест появился. Автоматическая публикация контента: процесс собирает материалы, готовит посты, выкладывает по расписанию. Работал прекрасно — пока однажды не упёрся в ошибку и молча не встал. Утром выясняется: ничего не вышло. Запускаю руками, чиню. Через неделю — то же самое, по другой причине.

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

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

Арифметика, которую никто не считает

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

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

Три свойства процесса, который можно оставить одного

1. Сам перезапускается

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

2. Громко зовёт, когда не справился

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

3. Отвечает на вопрос «ты живой?»

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

Три ошибки, которые сводят надзор на нет

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

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

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

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

Экономика надзора: во что обходится «просто поглядывать»

В компании из 40 человек у нас 10 автоматизированных процессов; доработка недостающих свойств у 6 из них заняла ≈18 часов разовой работы, эксплуатация не добавила затрат — используются существующие каналы уведомлений, а эффект — снижение скрытого надзора с ≈39 000 ₽/мес до ≈2 000 ₽/мес, то есть чистая экономия ≈37 000 ₽/мес (оценка при ставке ~1 000 ₽/час).

Один из этих 10 процессов — ежедневный отчёт для 8 менеджеров отдела продаж, которые в сумме закрывают около 50 сделок в месяц при обороте 9 млн ₽ и среднем чеке 180 тыс. ₽. Формально отчёт автоматический: цифры сами приходят в чат каждое утро. Фактически раз в одну-две недели он расходится с CRM на несколько сделок — обычно из-за тех, что двигают статус в выходные, — и тогда менеджеры по неделе работают по неверным цифрам, пока кто-то не заметит нестыковку и не поднимет её вручную. Это ровно третий тип из таблицы ниже: процесс работает, но требует регулярной проверки, потому что сам не умеет сказать «я соврал».

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

Что мы не считаем эффектом: если сотрудник раньше тратил час в день на ручной шаг, а теперь тратит те же 39 часов в месяц на присмотр за автоматикой — это не экономия, а другая работа под старым названием. Экономией мы называем только то, что освобождается сверх текущего надзора после доработки — то есть разницу между 39 000 ₽/мес и 2 000 ₽/мес, а не разово выигранное время на старте проекта.

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

Ежедневная ручная проверка 10 процессов занимает 15–20 минут в день; промпт ниже сводит это к чтению одной сводки, которую модель собирает из логов и вебхука Bitrix24 за 10–15 секунд, а не к обходу каждого процесса по отдельности.

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

Ты — дежурный по автоматизациям. На вход получаешь JSON-массив со статусами процессов за сутки (данные из вебхука Bitrix24 и логов сервера).

Для каждого процесса определи:
1) статус: "ok" / "warn" (перезапустился сам, но были ошибки) / "fail" (не справился);
2) человекочитаемую причину сбоя (если есть) одним предложением;
3) нужно ли действие человека сегодня (true/false).

Собери итог в JSON для отправки в Telegram-бота: короткая сводка (не длиннее 5 строк текста) и список процессов, требующих внимания.

Входные данные:
{
  "date": "2026-07-24",
  "processes": [
    {"name": "публикация_постов", "last_run": "2026-07-24T09:00:00", "retries": 2, "status_raw": "success_after_retry", "error_log": null},
    {"name": "сбор_лидов_bitrix", "last_run": "2026-07-23T22:14:00", "retries": 3, "status_raw": "failed", "error_log": "timeout: crm.deal.list"},
    {"name": "отчёт_менеджерам", "last_run": "2026-07-24T08:00:00", "retries": 0, "status_raw": "success", "error_log": null}
  ]
}

Ответ верни строго в формате JSON без пояснений вне него.

Пример ответа модели на этот вход:

{
  "date": "2026-07-24",
  "summary": "2 из 3 процессов в порядке, 1 требует внимания.",
  "attention_required": [
    {
      "name": "сбор_лидов_bitrix",
      "reason": "не отвечает CRM (timeout), 3 попытки не помогли",
      "action_needed": true
    }
  ]
}

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

Куда это масштабируется

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

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

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

Чек-лист на понедельник

• Выпишите все автоматизированные процессы компании — обычно их оказывается больше, чем помнят вслух.
• Для каждого проверьте три свойства: сам перезапускается, сам сообщает о сбое, отвечает на «жив?» за 10 секунд.
• Посчитайте, сколько из них требуют регулярной ручной проверки (третья категория из таблицы) — это ваш реальный, а не декларируемый, объём надзора в часах.
• Переведите часы в деньги по ставке ~1 000 ₽/час и сравните с тем, сколько будет стоить доработка (в разборе — ≈18 часов разово на 6 процессов).
• Начните с процесса, чья цена ошибки выше всего — как отчёт для отдела продаж, который расходится с CRM молча.

Ваш способ проверить, не попали ли вы в эту ловушку: посчитайте, сколько времени в неделю у вас уходит на присмотр за автоматикой. Если больше, чем экономит, — вы построили себе вторую работу.

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

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

Как понять, что автоматизация на самом деле требует надзора?

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

Сколько стоит добавить самовосстановление и оповещение в уже работающий процесс?

В разборе доработка 6 из 10 процессов заняла ≈18 часов разовой работы и окупилась меньше чем за месяц за счёт экономии ≈37 000 ₽/мес (оценка).

Внедрение автоматизации процессов — это то же самое, что автоматизация производства?

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

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