Какие бизнес-процессы стоит автоматизировать первыми
Первый процесс для автоматизации выбирают по повторяемости работы, цене ошибки и готовности правил. Хороший кандидат встречается регулярно, имеет понятное начало и результат, оставляет данные для проверки. У него есть сотрудник, который отвечает за исключения и сможет остановить ошибочный сценарий.
Содержание статьи
Найдите повторяющееся действие
Попросите команду несколько рабочих дней записывать действия, которые приходится повторять: переносить заявку, сверять адрес, отправлять номер доставки, искать свободное время, напоминать коллеге о заказе. Для каждой операции укажите частоту, затраченное время и последствия пропуска. Так появится список наблюдаемых задач для автоматизации.
Запись «работа с клиентами» слишком широкая. «После подтверждения оплаты перенести адрес и состав заказа в сообщение курьеру» уже подходит для разбора. У нее есть событие запуска, входные данные и получатель результата. Дальше можно выяснить, какие случаи требуют участия человека.
В Why Not? Flowers мы связали CRM с Telegram-группой курьерской службы. Заказ передавался на доставку, а изменения статуса возвращались в CRM. Отказ курьерской службы был предусмотрен в процессе: менеджер искал другой вариант. При выборе первого проекта стоит так же внимательно разбирать последствия отказа, как и успешное выполнение.
Иногда сначала нужно убрать лишний шаг
До настройки доставки в том же проекте разбирали восемь почти одинаковых воронок. Их свели в одну, распределили ответственность менеджеров и флористов. Если автоматизировать перенос данных между всеми прежними воронками, технических действий стало бы больше, а причина путаницы сохранилась бы.
Проверьте каждую ручную операцию на необходимость. Сотрудник может пересылать отчет руководителю потому, что у того нет доступа к системе. Или повторно заполнять таблицу, которую уже никто не читает. Исправление доступа и отказ от ненужного отчета обойдутся проще разработки нового обмена.
Но простое действие не всегда стоит автоматизировать первым. Если оно встречается редко, требует дорогой интеграции и занимает несколько минут, обслуживание решения может стоить больше сэкономленного времени. Отдельно рассматривайте ошибки с тяжелыми последствиями: им могут потребоваться контроль и подтверждение даже при небольшом числе операций.
Сравните кандидатов по одной таблице
Сопоставьте частоту работы с готовностью правил и последствиями ошибки. Заполняйте таблицу вместе с сотрудником, который выполняет работу, и человеком, который отвечает за результат. Ниже условный пример для небольшой компании; оценки нужно заменить своими наблюдениями.
| Процесс | Частота | Правила | Последствие ошибки | Предварительное решение |
|---|---|---|---|---|
| Напоминание о согласованной встрече | Ежедневно | Время и адрес известны | Клиент получает неверное время | Начать после проверки календаря и переносов |
| Передача новой заявки ответственному | Ежедневно | Правило распределения согласовано | Обращение остается без ответа | Кандидат для первого запуска с контролем ошибок |
| Согласование нестандартной скидки | Нерегулярно | Зависит от условий сделки | Потеря части прибыли | Автоматизировать сбор данных и уведомление; решение оставить человеку |
| Заказ товара у поставщика | Регулярно | Данные о запасах расходятся | Лишняя закупка или дефицит | Сначала сверить учет и правила расчета потребности |
| Подготовка отчета, который не используют | Еженедельно | Состав известен | Последствия не определены | Проверить необходимость и прекратить лишнюю работу |
Таблицу можно прокрутить вправо
Из этой таблицы видно, почему универсального списка «сначала продажи, потом склад» нет. Даже внутри одной компании готовность процессов различается. Для первого запуска выбирайте ограниченный участок, где можно проверить результат и быстро вернуть ручную работу при ошибке.
В центре «Сестры» такой задачей стала запись на интервью. Раньше заявки проходили через форму, таблицу, почту и ручную координацию. Мы подключили сервис записи с расписанием и напоминаниями. На странице проекта описан переход к прямой записи участниц и просмотру свободных слотов ведущими. Это пример автоматизации конкретной повторяющейся работы без переноса всей организации в новую систему.
Посчитайте доступное время и расходы
Возьмем условный расчет. Менеджер обрабатывает 120 однотипных уведомлений в месяц и тратит на каждое четыре минуты. Получается восемь часов. Если после настройки проверка исключений занимает два часа, освобождаются шесть часов. Это оценка времени, которое можно направить на другие задачи; сама по себе она не означает сокращения расходов на зарплату.
Рядом посчитайте стоимость настройки, подписок и дальнейшей поддержки. Учтите время сотрудников на описание процесса, тестирование и разбор сбоев. Разовые затраты сравнивайте с эффектом за выбранный период. Если данных для расчета мало, начните с короткого наблюдения и ограниченного запуска, затем уточните оценку.
Потери от ошибок считайте отдельно. Для этого нужны фактические отмены, повторная работа или расходы на исправление. Не записывайте всю выручку заказа в прибыль от автоматизации: заказ мог состояться и раньше, а часть денег уходит на товар и исполнение. Если задача связана с доступностью помощи или комфортом сотрудников, денежной оценки может быть недостаточно. Тогда заранее договоритесь о другом измеримом результате.
Опишите правило вместе с исключениями
У каждой автоматизации должен быть короткий паспорт. Его можно составить без разработчика, обычными предложениями.
- Событие запуска: что именно должно произойти и какая система это подтверждает.
- Условия: какие данные проверяются перед действием и при каких обстоятельствах оно отменяется.
- Действие: что создается, меняется или отправляется, кому и через какой канал.
- Защита от повторения: как распознать уже выполненную операцию.
- Исключения: кто получает ошибку, что проверяет и как продолжает работу вручную.
- Контроль: где хранится результат, кто его просматривает и как отключить сценарий.
В программных системах такое правило часто называют триггером. Например, документация RetailCRM описывает его через событие, проверку условий и действие. В проекте нужно дополнить эту логику ответственностью сотрудников и проверкой результата.
Детали события могут менять поведение всей цепочки. В инструкции об отправке трек-номера RetailCRM предупреждает, что номер может появиться позже нового статуса. Если письмо отправить раньше, данных в нем не окажется. До запуска проверьте, в какой момент необходимое поле уже заполнено.
Запустите один участок и сохраните возможность остановки
Сначала прогоните сценарий на тестовых данных: обычный случай, пустое поле, отмена, перенос срока и повторное событие. Затем выберите ограниченную группу операций для рабочей проверки. Назначенный сотрудник должен видеть ошибки и иметь понятный способ отключить автоматическое действие.
Для операций с клиентскими сообщениями заранее согласуйте содержание и условия отправки. Для изменения денег, запасов или условий сделки задайте дополнительные проверки. Если решение требует знания обстоятельств, система может собрать информацию и поставить задачу человеку. Полная автоматизация этого участка пока не обязательна.
После запуска сравните результаты с исходным наблюдением: время на операцию, количество исправлений, долю необработанных исключений. Подписка на сервис не доказывает, что работа стала легче. Если сотрудники ведут прежнюю таблицу параллельно и проверяют каждое автоматическое действие вручную, нужно найти причину недоверия и исправить процесс.
На следующем этапе выбирайте новую задачу с учетом уже полученных данных. Вопросы обмена между программами разобраны в статье о сайте, CRM и 1С, подготовка процессов продаж описана в материале о внедрении CRM. Для разбора процессов интернет-магазина подготовьте журнал повторяющихся операций и один заполненный паспорт. По ним можно предметно обсуждать первую автоматизацию и ее границы.