Какие бизнес-процессы стоит автоматизировать в первую очередь

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

Составьте карту ручной работы

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

Ищите признаки:

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

Не ограничивайтесь формальным регламентом. Фактический процесс часто живет в чатах и личных таблицах.

Оцените кандидатов по пяти критериям

Для каждого процесса поставьте простую оценку.

Частота

Чем чаще повторяется действие, тем быстрее заметен эффект. Ежедневная обработка заявок обычно важнее редкого ежегодного отчета.

Потери и риск

Что происходит при ошибке: задержка, потерянная продажа, штраф, повторная работа или недовольство клиента? Процесс с высокой ценой ошибки получает приоритет.

Стабильность правил

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

Доступность данных

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

Измеримость результата

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

Начните с процесса средней сложности

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

Примеры хорошего первого контура:

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

Опишите процесс «как есть»

Зафиксируйте вход, участников, шаги, решения, исключения и результат. Не исправляйте схему сразу — сначала покажите реальность.

Для каждого шага спросите:

1. 1Кто выполняет действие?
2. 2Какие данные нужны?
3. 3Откуда они берутся?
4. 4Как принимается решение?
5. 5Кому передается результат?
6. 6Что бывает при ошибке?
7. 7Как фиксируется завершение?

После этого удаляют дублирующие действия и лишние согласования. Иначе система лишь ускорит плохой порядок.

Определите границу первого релиза

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

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

Не забывайте исключения

Автоматизация ломается не на обычном пути, а на возврате, отмене, дубликате и отсутствии данных. Для первого релиза перечислите хотя бы самые частые отклонения:

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

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

Назначьте владельца процесса

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

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

Измерьте результат

До разработки зафиксируйте базовые показатели:

• среднее время прохождения;
• время ожидания между этапами;
• количество ручных действий;
• долю возвратов;
• число потерянных или просроченных задач;
• время подготовки отчета;
• количество обращений о статусе.

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

Что не стоит автоматизировать первым

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

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

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

Нужно ли сначала описать все процессы компании?

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

Как учитывать сопротивление сотрудников?

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

Можно ли начать с таблицы?

Да, если процесс небольшой и данные не чувствительные. Таблица помогает проверить поля и статусы. Когда появляются роли, история, интеграции и одновременная работа, нужен управляемый сервис.

Когда расширять первый контур?

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