Автоматизация бизнес-процессов: что описать до всякой программы

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

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

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

Что такое бизнес-процесс на самом деле

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

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

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

Отсюда важное различие, которое путают постоянно. Задача — это разовое поручение конкретному человеку. Функция — это то, чем занимается отдел. Процесс — это маршрут, по которому работа идёт через людей и отделы. Автоматизируют именно маршруты; отдельные задачи автоматизировать нечего.

Почему нельзя автоматизировать то, что не описано

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

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

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

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

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

Три уровня описания

Описывать процесс можно по-разному, и глубина должна соответствовать задаче. Универсальная ошибка — сразу лезть в сложные нотации.

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

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

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

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

Какие процессы автоматизируют чаще всего

Продажи разбирают отдельно, а вот список за их пределами почти одинаков у всех компаний.

Согласование документов и счетов. Классический маршрут: инициатор, руководитель, финансист, подпись. Автоматизация даёт сроки на каждом шаге и видимость, у кого документ лежит третий день.

Внутренние заявки. Отпуск, командировка, закупка, доступ к системе, ремонт техники. Процессы простые, повторяются часто, а без системы живут в переписке и теряются.

Приём и распределение обращений. Заявка попадает к ответственному по правилу, вместо принципа «кто первый увидел». Механика та же, что и в воронке продаж, но применима к любым входящим — от жалоб до заявок в поддержку.

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

Контроль сроков и эскалация. Система следит за временем на шаге и передаёт выше, если срок вышел. Это то, что человек делать не может физически: помнить про сорок задач и вовремя дёргать сорок человек.

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

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

Где проходит граница

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

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

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

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

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

Один процесс до и после: согласование счёта

Абстрактные рассуждения плохо доносят суть, поэтому вот типичная картина в компании человек на сорок.

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

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

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

Обратите внимание, чего в этом примере нет. Система не решает, платить счёт или нет, — это остаётся людям. Она отвечает за маршрут, сроки и видимость.

Кто такой владелец процесса

Роль, которую забывают назначить, и из-за этого проекты разваливаются через полгода.

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

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

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

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

Инструменты: от роботов до отдельной системы

Три уровня, и переходить на следующий стоит, только упёршись в предыдущий.

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

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

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

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

Что здесь делает искусственный интеллект

Запрос про ИИ в автоматизации процессов стал массовым, и вокруг него много путаницы. Разделим по-честному.

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

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

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

Как измерять эффект

Без этого проект превращается в бесконечное улучшение. Считать нужно до, а не после.

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

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

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

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

Что мерить бесполезно: число настроенных процессов. Оно растёт, а работа лучше не становится. Как читать отчёты и не обманываться цифрами, разбирали в статье про аналитику.

Как это выглядит по шагам

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

Что чаще всего идёт не так

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

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

Не назначили владельца процесса. Настроили, сдали, ответственного нет. Через полгода маршрут не совпадает с реальностью, а менять его некому.

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

Начали с самого сложного процесса. Логика понятна: где больнее всего, там и чиним. На практике первый проект должен быть простым и быстрым — он даёт команде опыт и доверие к инструменту.

Сколько это стоит и сколько занимает

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

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

Настройка. Простой маршрут внутри CRM — дни. Процесс с ветвлениями, интеграциями и согласованиями — недели.

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

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

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

С какого процесса начать?

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

Обязательно ли рисовать схемы в специальной нотации?

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

Чем бизнес-процесс отличается от робота в CRM?

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

Что делать, если сотрудники обходят настроенный процесс?

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

Можно ли автоматизировать процесс без CRM?

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

Сколько процессов стоит автоматизировать в первый год?

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

Заменит ли ИИ настроенные процессы?

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

Итог

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

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