Как выбрать первый процесс для автоматизации и проверить окупаемость

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

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

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

Определите, за счёт чего появится польза

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

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

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

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

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

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

Проверьте, готов ли процесс к автоматизации

Для сравнения достаточно выбрать три-четыре кандидата и рассмотреть каждый по шести вопросам. Итогом должен стать понятный выбор с отмеченными неизвестными, а не формальный рейтинг с баллами.

1. Как часто повторяется работа

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

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

2. Можно ли объяснить правила решений

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

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

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

3. Доступны ли нужные данные

Нужно понять, откуда система получит сведения и куда запишет результат. Например, из рекламного кабинета, Яндекс Метрики, amoCRM, Битрикс24 или 1С данные можно получать через API, программный интерфейс обмена, либо через выгрузки и другие доступные механизмы.

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

Если в исходных материалах есть сведения о клиентах, до передачи во внешнюю языковую модель нужно определить допустимый состав обработки и требования к защите, в том числе с учётом 152-ФЗ. Правовые основания определяют профильные специалисты; технические меры затем реализуют в системе.

4. Можно ли заметить ошибку и исправить последствия

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

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

5. Кто отвечает за процесс со стороны компании

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

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

6. Как и когда можно проверить пользу

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

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

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

Считайте денежный эффект отдельно от освободившихся часов

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

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

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

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

Условный пример расчёта

Допустим, четыре сотрудника суммарно тратят на процесс 80 часов в месяц. После автоматизации ожидается 15 часов на контроль и разбор спорных случаев. Стоимость часа с налогами составляет 1 200 ₽.

Сейчас ошибка происходит дважды в месяц и обходится в 40 000 ₽. Предположим, после внедрения она будет возникать примерно раз в два месяца. Дополнительных продаж в примере нет. Сервер, API модели и необходимое сопровождение вместе условно стоят 15 000 ₽ в месяц. Разработка, перенос данных и обучение обходятся в 600 000 ₽. Все эти числа служат для объяснения расчёта и не являются ценами моих услуг.

Получаем следующие значения:

Расчётный срок окупаемости составляет 600 000 / 123 000 ≈ 4,88 месяца, то есть чуть меньше пяти месяцев.

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

Тот же процесс без денежной оценки времени

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

Тогда месячный эффект составит 60 000 - 15 000 = 45 000 ₽, а срок окупаемости: 600 000 / 45 000 ≈ 13,33 месяца.

Теперь изменим ещё одно допущение: исходная ошибка происходит лишь раз в квартал. Даже если система полностью её предотвратит, средний эффект составит 40 000 / 3 ≈ 13 333 ₽ в месяц. Это меньше 15 000 ₽ эксплуатационных расходов. Если время по-прежнему не даёт денежного результата, финансовой окупаемости при таких вводных нет.

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

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

Включите в бюджет переход на систему и её дальнейшую работу

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

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

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

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

Когда лучше отложить собственную разработку

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

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

Иногда объём работы слишком мал для отдельной системы. Когда я организовывал выпуск программ, созданных сотрудниками с ИИ, прототипов было немного, они различались между собой и взаимодействовали с разными системами. Я не стал создавать автоматическое ревью: оно потребовало бы собственной разработки и поддержки. Разумнее было привлечь разработчика на неполную занятость. Сотрудник готовит доступную ему часть по регламенту, а технический ответственный проверяет программу и выполняет необходимые доработки.

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

Проверьте выбранный процесс на небольшом запуске

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

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

До основной разработки согласуйте, как проверить предложенную логику. Иногда достаточно схемы и презентации, иногда нужен демонстрационный прототип. Для конструктора лендингов я заранее показывал заказчику логику и интерфейс на презентациях и демонстрациях. Объём такой подготовки нужно включать в согласованный этап работ.

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

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

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