Автоматизация бизнес-процессов: где окупается, а где нет

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

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

Эта статья — про то, как отличить одно от другого до того, как потрачены деньги.

Считаем до старта

Сначала посчитайте, потом выбирайте платформу

Есть старый комикс xkcd №1205 «Is It Worth the Time?» (29 апреля 2013 года). Он о том, сколько времени разумно потратить на автоматизацию рутины, прежде чем эта автоматизация окупится за пять лет.

Формула простая: суммарная экономия за 5 лет = 5 × (число выполнений задачи в год) × (экономия за одно выполнение). Из неё получается таблица порогов — ключевые ячейки дословно из комикса:

Экономия за раз	Ежедневно	Еженедельно	Ежемесячно	Ежегодно
5 секунд	2 часа	21 минута	5 минут	25 секунд
1 минута	1 день	4 часа	1 час	5 минут
5 минут	6 дней	21 час	5 часов	25 минут
30 минут	5 недель	5 дней	1 день	2 часа
1 час	2 месяца	10 дней	2 дня	5 часов

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

Мы прогоняем через эту арифметику каждую задачу на автоматизацию. Вот тот же расчёт в виде кода:

def hours_budget(times_per_year, seconds_saved, years=5):
    """Сколько часов разумно потратить на автоматизацию (модель xkcd 1205)."""
    total_seconds_saved = years * times_per_year * seconds_saved
    return total_seconds_saved / 3600

# Заявки, которые менеджер размечает вручную: 40 раз в день, экономим 90 секунд
print(round(hours_budget(40 * 250, 90), 1))   # ~225 часов — автоматизировать стоит

# Редкий отчёт: раз в квартал, экономим 30 минут
print(round(hours_budget(4, 1800), 1))        # ~10 часов — на грани

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

Реальность жёстче таблицы. Настоящая стоимость автоматизации — это не разработка, а то, что происходит после неё.

30–50% первых проектов не дают эффекта

Четыре независимых замера за девять лет отвечают на один вопрос: какая доля проектов не дала ожидаемого эффекта. Числа получены по-разному, складывать их нельзя.

• Ernst & Young, 2016. Провал как минимум у 30–50% первых проектов роботизации. Консультанты отдельно оговаривают: дело в методологии и в непонимании, что именно автоматизируется, а не в технологии.
• Deloitte, 2018, опрос свыше 400 компаний. Роботизацию начали 53% опрошенных, до промышленного масштаба — полсотни роботов и больше — довели 3%. Более половины проектов не выходят за пределы десяти роботов: большинство застревает на пилоте.
• McKinsey, 2018, опрос 1793 руководителей. 16% респондентов говорят, что их организации улучшили показатели и вдобавок удержали результат надолго.
• BCG, 2020, 825 организаций. 70% цифровых трансформаций не достигают целей: 30% попали в «зону выигрыша», 44% — в «зону тревоги», 26% дали меньше половины запланированной ценности.

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

Ernst & Young, «Get ready for robots», 2016

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

Где автоматизация проигрывает ручной работе

Есть три типа процессов, где мы почти всегда отговариваем от автоматизации.

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

Часто меняющиеся правила. Автоматизация фиксирует процесс в коде или в настройках робота, и каждое изменение правила — это работа разработчика.

Илон Маск в биографии Уолтера Айзексона ставит автоматизацию последним шагом из пяти:

1. Поставить под сомнение само требование.
2. Удалить лишнее.
3. Упростить оставшееся.
4. Ускорить.
5. И только теперь автоматизировать.

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

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

Отдельно — правило Билла Гейтса из книги «The Road Ahead» (1996):

Первое правило любой технологии в бизнесе: автоматизация эффективной операции усилит эффективность. Второе: автоматизация неэффективной операции усилит неэффективность.

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

Как посчитать до начала: пять вопросов

Перед тем как открыть дизайнер бизнес-процессов, мы задаём заказчику пять вопросов и требуем числа, а не «часто» и «редко»:

1. Частота. Сколько раз в день, неделю, месяц выполняется процесс?
2. Объём. Сколько элементов проходит через процесс за период?
3. Доля исключений. Какой процент случаев идёт не по типовому сценарию?
4. Цена ошибки. Что стоит один неверный прогон робота — потерянный лид, неправильный счёт, недовольный клиент?
5. Частота изменения правил. Как часто меняется логика процесса?

Первые три можно не спрашивать, а посчитать по данным CRM: если процесс уже идёт вручную в 1С-Битрикс, история сделок лежит в базе.

Вот запрос, который оценивает частоту создания сделок и распределение по стадиям — то есть отвечает на «частоту» и «объём» напрямую из данных:

-- Частота создания сделок по месяцам и распределение по текущим стадиям
SELECT
    DATE_FORMAT(D.DATE_CREATE, '%Y-%m') AS month,
    S.NAME AS stage,
    COUNT(*) AS deals
FROM b_crm_deal AS D
JOIN b_crm_status AS S
    ON S.STATUS_ID = D.STAGE_ID
   AND S.ENTITY_ID = 'DEAL_STAGE'
WHERE D.DATE_CREATE >= DATE_SUB(NOW(), INTERVAL 12 MONTH)
GROUP BY month, stage
ORDER BY month, deals DESC;

А этот оценивает долю исключений — сделки, которые ушли с типового маршрута:

-- Доля сделок с «нетиповым» финалом как оценка доли исключений
SELECT
    ROUND(
        100.0 * SUM(CASE WHEN D.STAGE_SEMANTIC_ID = 'F' THEN 1 ELSE 0 END)
        / COUNT(*), 1
    ) AS lost_percent,
    COUNT(*) AS total_deals
FROM b_crm_deal AS D
WHERE D.DATE_CREATE >= DATE_SUB(NOW(), INTERVAL 12 MONTH);

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

Что автоматизируют и сколько это стоит

Что реально автоматизируют в CRM — и где выигрыш измерим

В 1С-Битрикс и Битрикс24 автоматизация CRM строится на двух вещах. Роботы срабатывают, когда элемент — лид или сделка — попадает на стадию. Триггеры отслеживают внешние события: переход по ссылке, входящий звонок, оплату, — и двигают элемент на другую стадию.

Разложим типовые задачи по тому, измерим ли выигрыш:

Что автоматизируют	Выигрыш измерим?	Чем измерить
Распределение заявок между менеджерами	Да	Время до первого ответа, доля потерянных лидов
Смена стадии по событию (оплата, подпись)	Да	Время в стадии, число «зависших» сделок
Документы по шаблону (счёт, договор)	Да	Время на подготовку, число ошибок в реквизитах
Напоминания менеджеру	Частично	Легко замерить факт отправки, трудно — влияние на выручку
Согласования по цепочке	Спорно	Время согласования измеримо, качество решения — нет
«Прогрев» клиента письмами	Редко	Атрибуция к продаже почти всегда спорная

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

Стоимость владения: что вы платите после внедрения

Главная ловушка — считать стоимость автоматизации как стоимость разработки. Разработка — меньшая часть.

25–30% полной стоимости приходится на лицензии, остальное — внедрение, интеграции, обучение и цикл «сломалось — починили». Это оценка HFS Research из заметки «Making Sense of Nonsensical RPA Software Pricing»; там же сказано, что расчёт окупаемости по одним лицензиям вводит в заблуждение.

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

Что приходится поддерживать после внедрения, по нашему опыту:

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

Что ломается на практике

Технические грабли 1С-Битрикс, о которых не пишут в документации

Документация описывает, как настроить робота. Она не описывает, что ломается. Вот то, на что мы натыкались.

Робот на первой стадии сделки зависает. Повесили сложного робота на стадию New — бизнес-процесс может не найтись: робот через REST пытается вернуть результат, а CRM ещё не успела создать бизнес-процесс для новой сделки. Возвращается ошибка «404 Бизнес-процесс не найден». Лечится тем, что тяжёлую логику не вешают на самую первую стадию, а при 404 делают паузу и повторяют попытку.

Штатная пауза не рассчитана на секунды. Механизмы ожидания в бизнес-процессах Битрикс24 работают на минутах и часах. Сценарий «пауза на несколько секунд, потом действие» через стандартные средства приводит к зависшим процессам. Нужны сторонние активити или другая архитектура.

Зависшие процессы копятся молча. На форуме 1С-Битрикс описан случай, где с 2017 года накопилось около 2000 зависших бизнес-процессов по лидам, при том что счётчик портала показывал 232. Зависшие процессы не всегда видны и продолжают висеть в базе.

Лимит REST. Битрикс24 ограничивает интенсивность запросов: стандартно два в секунду, по алгоритму Leaky Bucket — короткий всплеск можно, постоянную нагрузку нельзя. При превышении приходит ошибка со статусом 503 и кодом QUERY_LIMIT_EXCEEDED. Робот, который в цикле дёргает интерфейс без учёта лимита, ляжет сам и уронит соседей.

Идемпотентность: почему робот делает работу дважды

Самая коварная ошибка — не «робот не сработал», а «робот сработал дважды».

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

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

<?php
// /local/php_interface/init.php
use Bitrix\Main\Loader;

\AddEventHandler('crm', 'OnAfterCrmDealAdd', 'onDealAddCreateTask');

function onDealAddCreateTask($dealId, array $fields): void
{
    if (!Loader::includeModule('crm') || !Loader::includeModule('tasks')) {
        return;
    }

    $dealId = (int)$dealId;

    // Ключ идемпотентности: одна сделка — одна задача.
    // Пишем маркер в пользовательское поле UF_TASK_CREATED.
    $deal = \CCrmDeal::GetByID($dealId, false);
    if (!$deal || !empty($deal['UF_TASK_CREATED'])) {
        return; // задача для этой сделки уже создавалась — выходим
    }

    $task = new \CTasks();
    $taskId = $task->Add([
        'TITLE'            => 'Связаться по сделке #' . $dealId,
        'RESPONSIBLE_ID'   => (int)$deal['ASSIGNED_BY_ID'],
        'UF_CRM_TASK'      => ['D_' . $dealId],
        'DEADLINE'         => \ConvertTimeStamp(time() + 3600, 'FULL'),
    ]);

    if ($taskId) {
        // Ставим маркер только после успешного создания.
        (new \CCrmDeal(false))->Update($dealId, ['UF_TASK_CREATED' => 1]);
    }
}

Ключевая мысль здесь не в интерфейсе, а в маркере UF_TASK_CREATED. Он превращает «создай задачу» в «создай задачу, если её ещё нет». Без такого маркера повторное срабатывание события создаёт дубль, и человек потом разбирает завалы.

Итоги

Четыре ошибки, которые мы видим чаще всего

1. Автоматизация поверх неотлаженного процесса. Правило Гейтса в действии: сначала наведите порядок вручную, потом автоматизируйте. Робот не чинит процесс, он его закрепляет.
2. Правила, зашитые в код вместо настроек. Когда логика вроде «скидка 10% при сумме от полумиллиона» живёт в коде, а не в настройках, каждое изменение — задача разработчику. Выносите изменяемые правила туда, где их правит бизнес.
3. Нет способа отключить робота. Робот, которого нельзя быстро выключить, когда он мешает, — это авария, ожидающая своего часа. Всегда должен быть рубильник.
4. Автоматизация ради метрики активности. Считать число настроенных роботов вместо того, стало ли компании лучше, — путь к «99+» в счётчике задач и раздражению вместо помощи.

Когда всё-таки стоит

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

Распределение входящих заявок, смена стадии по факту оплаты, генерация типовых документов — классические кандидаты, где выигрыш измерим и живёт долго.

Gartner в обзоре «Top 10 Strategic Technology Trends for 2020: Hyperautomation» прогнозировал:

К 2024 году организации снизят операционные издержки на 30%, сочетая технологии гиперавтоматизации с перепроектированными операционными процессами.

Обратите внимание на «перепроектированными»: сначала процесс, потом автоматизация. Это прогноз, а не подтверждённый факт, но направление он задаёт верное.

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