Автоматизация бизнес-процессов ломается на сложных местах

Почему автоматизация ломается на сложных местах

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

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

Поэтому рутинная работа идёт быстро ровно до первого исключения. Команды останавливаются, потому что не хотят принимать решение наугад. Один человек идёт к менеджеру. Менеджер спрашивает finance. Finance просит support дать контекст. Час спустя инструмент всё ещё ждёт ответа.

Часто винят софт. Говорят, что автоматизация слишком жёсткая или workflow tool не справляется с реальной работой. Обычно проблема не в инструменте. Проблема в ответственности.

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

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

Где обычно всплывают неудобные крайние случаи

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

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

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

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

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

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

Запутанные workflow редко ломаются на основном пути. Они ломаются там, где правила размыты, ответственность неясна, а один нестандартный запрос заставляет трёх человек импровизировать.

Назначьте владельца каждому исключению

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

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

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

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

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

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

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

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

Как разложить согласования, исправления и исключения по полкам

Начинайте с реальности, а не с красивой схемы процесса. Возьмите последние 20 случаев, где кто-то вмешивался через email, чат, таблицу или короткий звонок. Эта небольшая выборка обычно говорит больше, чем идеальная диаграмма workflow.

Разделите такие случаи на три группы. Согласование — это когда человек говорит да или нет до продолжения работы. Исправление — это когда кто-то чинит неверные или отсутствующие данные. Исключение — это случай, который вообще не вписывается в обычное правило, например особые условия для клиента или разовое обещание по договору.

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

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

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

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

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

Простой пример из обработки заказов

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

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

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

Задержка начинается сразу. Sales ждут, что finance скорректирует счёт. Finance хочет согласование до изменения условий оплаты. Support не понимает, нужно ли из-за исправления адреса останавливать отправку или можно пропустить его без проверки. Три команды работают с одним заказом, и каждая ждёт, пока кто-то другой примет следующий шаг.

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

Простая модель ответственности решает большую часть таких ситуаций. Sales могут запросить исключение по биллингу, но finance его утверждает или отклоняет. Support может исправить адрес доставки до начала комплектации. Один владелец, часто operations или менеджер по заказам, решает, готов ли заказ двигаться дальше.

Когда такие правила есть, система может направить заказ по нужному пути, а не оставлять его в командном чате или email. Finance получает задачу на согласование. Support фиксирует исправление адреса. Владелец видит оба изменения в одном месте и разрешает заказ к биллингу и доставке.

Заказ двигается за минуты, потому что у каждого исключения есть свой путь. Без этого даже простой заказ может висеть два дня, пока все задают один и тот же вопрос: «Кто вообще должен это решить?»

Что даёт техническое лидерство

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

Он превращает размытые исключения вроде «спроси Sarah», «исправь в таблице» или «отправь письмо клиенту» в правила, по которым команда может работать. Это менее эффектно, чем покупка нового инструмента, но гораздо важнее. Если клиент меняет заказ после согласования, кто может его редактировать? Если billing address не совпадает с налоговой записью, система должна остановиться, предупредить или отправить случай в finance? Кто-то должен принять эти решения и записать их.

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

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

Техническое лидерство видно и в связке между инструментами. Многие команды до сих пор переносят детали заказа из email в CRM, потом в биллинг, потом в чат поддержки. Такие передачи создают опечатки, пропущенные обновления и тихие задержки. Технический лидер связывает системы так, чтобы одно обновление проходило через весь процесс, а не порождало ещё три задачи.

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

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

Ошибки, из-за которых workflow остаются наполовину ручными

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

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

Правила согласований наносят большой ущерб, когда люди держат их в чатах или цепочках email. Один менеджер говорит: «Спросите меня про всё выше $5,000», другой пишет: «Я уже согласовал это на прошлой неделе», а потом никто не видит полной истории. Работа всё ещё движется, но только потому, что кто-то помнит, кто сказал да.

Хуже становится, когда каждый отдел придумывает свой обходной путь. Sales ведут таблицу специальных цен. Support фиксирует исключения в общем документе. Finance добавляет заметки в биллинг-инструмент. Operations отслеживают срочные случаи в чате. Теперь у компании есть четыре версии одного и того же процесса, и ни одна не совпадает с автоматизацией.

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

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

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

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

Быстрая проверка перед тем, как автоматизировать ещё больше

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

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

1. Когда появляется исключение, за него отвечает один человек или одна роль?
2. У каждого согласования есть понятный триггер?
3. Могут ли сотрудники исправить плохие данные внутри workflow, не уходя в чат или email?
4. Видит ли система, кто что изменил и почему?
5. Получает ли клиент понятное сообщение, если его случай выходит за рамки обычного правила?

Если на два или более вопросов ответ «нет», процесс слабее, чем кажется.

Простой пример с заказом это показывает. Заказ не проходит, потому что адрес доставки не совпадает со страной оплаты. Sales пишут finance в чат. Finance просит support отправить клиенту письмо. Support исправляет адрес в CRM, но склад так и не видит изменение. Заказ стоит два дня, и каждый думает, что это должен делать кто-то другой.

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

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

Что делать дальше

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

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

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

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

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

Через две недели реального использования снова пересмотрите процесс. Ищите ту же ручную работу под другим названием. Команды часто думают, что исправили проблему, но на самом деле просто переместили её из sales в operations или из support в finance.

Если команда застряла между процессом, софтом и ответственностью, внешняя помощь может быть полезна. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как fractional CTO и advisor по automation, infrastructure и AI-first software operations. Такая поддержка особенно полезна, когда согласования проходят через несколько команд и никто не хочет брать на себя сложные случаи.

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