Две недели назад проводил аудит портала Битрикс24 у клиента — дистрибьютор стройматериалов, коробочная версия, семь лет эксплуатации. Открыл дизайнер бизнес-процессов на сделках и увидел схему, которая не влезала на экран даже при масштабе 25%. Я посчитал: 94 блока, 37 условий, 12 обработчиков пауз, связи петляют через всю схему. Никто в компании не мог ответить, что произойдёт, если счёт оплачен частично. Включая меня — после часа разбора. Процесс работал, пока его автор не уволился два года назад; с тех пор его боялись трогать, а баги в нём чинили обходными роботами, которые я нашёл в соседней вкладке — ещё 18 штук, часть из которых дублировала логику основной схемы. Это лучший пример антипаттерна, о котором я хочу поговорить: бизнес-процесс-«спагетти». И объяснить, почему я считаю, что большой БП в дизайнере Битрикс24 — это почти всегда ошибка архитектуры, а не «серьёзный подход к автоматизации».
Что именно я называю процессом-спагетти
Признаки, по которым я диагностирую проблему за первые пять минут аудита. Первое: схема не помещается на экран целиком — если процесс нельзя увидеть без прокрутки и зума, его нельзя понять, а значит, нельзя безопасно менять. Второе: в одном процессе смешаны разные жизненные циклы — квалификация лида, выставление счёта, логистика и постпродажный контроль живут одной схемой, хотя у них разные владельцы и разная частота изменений. Третье: условия ссылаются на поля, которые заполняются в трёх разных местах схемы, и ответ на вопрос «почему сделка пошла не туда» требует археологии по логам. Четвёртое — самый надёжный маркер: вокруг большого процесса обросли роботы и вебхуки, которые «подправляют» его результат. Это значит, что схема уже неуправляема, и команда чинит её снаружи, потому что зайти внутрь страшно.
Почему так происходит, я знаю хорошо — сам раньше так строил. Дизайнер бизнес-процессов создаёт иллюзию простоты: блоки перетаскиваются мышкой, логика рисуется стрелочками, и кажется, что сложность бесплатна. Но каждый добавленный блок — это код, просто визуальный. А код подчиняется тем же законам: через два года и десять правок система без рефакторинга становится наследием, которое все боятся. Только визуальный код ещё и нельзя нормально версионировать, покрыть тестами и отревьюить diff — три вещи, без которых текстовый код на продакшене никто не считает приемлемым.
Что я ставлю вместо: разрезать по стадиям и по владельцам
На том самом портале мы за шесть недель разрезали схему из 94 блоков на девять маленьких процессов и набор роботов. Принципы, которыми я руководствуюсь.
Правило одного экрана. Процесс должен помещаться на экран при масштабе 100%. Это грубый, но работающий критерий сложности: 15–20 блоков максимум. Всё, что не влезает, режется на отдельные процессы, которые запускаются по смене стадии или по событию. На практике это почти всегда совпадает со сменой ответственного подразделения: квалификация — один процесс, коммерческое предложение — второй, отгрузка — третий.
Роботы вместо блоков там, где логика линейная. «Поставить задачу при переходе на стадию», «напомнить через два дня», «сменить ответственного» — это не бизнес-процесс, это триггер-действие. У роботов есть два убийственных преимущества перед блоками БП: их видно прямо в канbanе на стадии, где они сработают, и их список читается менеджером без меня. После переделки у клиента 60% автоматизаций — это роботы, и заявок «объясните, почему это сработало» больше нет.
Сложную логику выносить из дизайнера в код. Если внутри условия нужно сходить во внешнюю систему, посчитать скидку по матрице или проверить остатки — визуальный блок превращается в мучение. Я выношу это в небольшое приложение на том же подходе, который описывал в статье про связку сайта с Битрикс24 через вебхуки и REST: процесс дёргает исходящий вебхук, сервис считает, возвращает результат. Код на Python или PHP тестируется, версионируется и читается. А если нужна гарантированная доставка событий без потерь — я сравнивал три схемы транспорта в материале про вебхук, поллинг и очередь сообщений для передачи заявок в CRM, там же цифры по надёжности каждого варианта.
Владелец у каждого процесса — человек, а не «отдел продаж». У девяти новых процессов в карточке описания записано, кто отвечает и когда схема пересматривалась последний раз. Звучит бюрократично, но именно отсутствие владельца превратило старую схему в наследие: семь лет её меняли пять подрядчиков, и никто не был обязан понимать её целиком.
Как резать монстра, не останавливая продажи
Порядок, который я отработал на трёх таких переделках и который ни разу не уронил рабочий процесс. Шаг первый — инвентаризация: выгружаю список всех процессов и роботов на сущность, и по логам за три месяца смотрю, какие ветки реально срабатывали. На портале из вступления выяснилось, что из 37 условий восемь не срабатывали ни разу за год — мёртвые ветки, которые рисовали «на будущее» и которые можно не переносить вообще. Это сразу убрало почти четверть схемы без единого решения.
Шаг второй — выбираю самый больной жизненный цикл (обычно тот, где больше всего обходных роботов) и выношу его в отдельный процесс на отдельную воронку или на стадии. Новый процесс включается только для новых сделок — старые доезжают по старой схеме. Это ключевое правило: никогда не конвертирую сделки «на лету», потому что половина из них стоит в обработчиках паузы, и перенос превращается в лотерею. Шаг третий — месяц наблюдения: новый процесс работает, обходные роботы для него отключены, откат — это выключить новый и включить старый, пять минут. И только после месяца берусь за следующий кусок.
Отдельная деталь для коробочной версии: перед любой переделкой снимаю полный бэкап портала и проверяю его восстановление — по чек-листу проверки резервных копий, который я недавно публиковал. Процессы-спагетти чинятся именно в проде, потому что адекватного тестового стенда для БП с реальными сделками почти ни у кого нет, — и цена ошибки без рабочей копии слишком высокая.
Цифры после переделки
Что изменилось через два месяца после рефакторинга. Среднее время разбора инцидента «автоматизация сработала не так» упало с двух-трёх часов моей археологии до пятнадцати-двадцати минут: маленькую схему можно просто прочитать. Количество обращений ко мне по автоматизации сделок — с восьми-десяти в месяц до двух, причём оба последних были доработками, а не «у нас что-то сломалось и мы не знаем что». И косвенный показатель, который я ценю больше всего: руководитель отдела продаж сам добавил два робота на новую стадию и не сломал ничего — раньше к дизайнеру БП никто из бизнеса не подходил в принципе.
Когда большой бизнес-процесс всё-таки оправдан
Чтобы не быть голословным максималистом: я знаю два случая, где длинный процесс — нормальное решение. Первый — жёстко регламентированные сквозные согласования: тендеры, договоры с юристами, допуски. Там ценность как раз в том, что весь маршрут виден целиком и неизменен, а меняется он раз в год и по решению сверху. Второй — онбординг сотрудников: линейный длинный маршрут без ветвлений, который рисуется прямой линией и читается сверху вниз. Общее у этих случаев — мало ветвлений и редкие изменения. Как только появляется «если клиент оплатил частично, а если в рассрочку, а если менеджер Иванов» — длинный процесс начинает умирать.
И ещё одно наблюдение про новые инструменты. Полгода назад я разбирал AI-агентов и CoPilot в Битрикс24 и заметил: генерация процессов по текстовому описанию производит ровно те же схемы-спагетти, только быстрее. AI рисует связный большой процесс, потому что вы описали задачу целиком — а надо было сначала разрезать её на стадии и владельцев, и только потом автоматизировать куски. Инструмент не решает архитектуру.
Как понять, что вашему порталу это грозит
Простой тест, который я теперь даю клиентам: откройте самый большой бизнес-процесс и задайте трём людям один вопрос — «что произойдёт со сделкой, если счёт оплачен частично?» Если ответы различаются, если ответа нет, если единственный знающий — это тот, кто уже не работает у вас, — схема начала свой путь в наследие. Хорошая новость: резать её не нужно в один день. На всех моих проектах это делалось итерациями: сначала выносится один жизненный цикл в отдельный процесс, живёт месяц, потом следующий. Старый монстр при этом продолжает работать и не требует остановки продаж ни на один день.
А как выглядит самая страшная схема в дизайнере бизнес-процессов на вашем портале — сколько в ней блоков и есть ли человек, который понимает её целиком? Мой текущий антирекорд — те самые 94 блока; сомневаюсь, что он уникальный.
