Бизнес-процессы в Битрикс24: как согласовать скидку, договор и заявку

Результат согласования виден в работе отдела

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

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

• Предмет назван. В скидке это сумма и условия заказа, в договоре — определённая версия файла, во внутренней заявке — запрос с понятным результатом выполнения.
• Окончание определено. «Руководитель нажал кнопку» ещё не описывает результат отдела. Цена попала в нужную запись, документ получил статус или исполнитель принял задачу.
• Есть владелец правила. Один ответственный объясняет, кто принимает решение и когда требуется повторное рассмотрение.

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

Доступность инструмента и право менять шаблон

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

• Версия и тариф названы. В смете указано, где будет работать процесс и какие дополнительные расходы нужны именно для выбранного варианта.
• Запуск показан. Сотрудник понимает, нажимает ли он кнопку самостоятельно или процесс начинается после конкретного события.
• Редактирование ограничено. Менять правила могут назначенные люди, а обычный участник получает доступ к своему заданию.
• Копия шаблона передана. В дизайнере есть экспорт и импорт. Исполнитель поясняет, что сохранено и какие связи с полями портала потребуются при восстановлении.

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

Задание содержит всё для решения

Получатель должен понять просьбу без поиска в переписке. В действии «Утверждение документа» Битрикс24 позволяет задать название, описание и подписи кнопок подтверждения и отказа. Это описано в справке действий. Возможность заполнить описание полезна лишь тогда, когда в него действительно попадают сведения для решения. Пустое поле — отдельный исход. На приёмке полезно отправить запрос без существенного вложения или основания, чтобы увидеть, остановится ли процесс с понятным объяснением либо заставит руководителя разбираться в заведомо неполном задании.

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

Лучше собрать обязательные сведения до отправки на решение, чем добавлять руководителю ещё одно действие «уточнить у автора». Так очередь содержит просьбы, которые уже можно рассмотреть, а заявитель сразу понимает причину задержки.

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

В Битрикс24 у утверждения документа есть варианты «Все сотрудники», «Любой сотрудник» и «Голосование сотрудников». При выборе всех один отказ ведёт по ветке «Не утверждён», а вариант с любым участником допускает решение одного из назначенных. Различия зафиксированы в документации задания. Подписи похожи, последствия различаются.

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

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

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

Скидка меняет сумму там, где её увидит клиент

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

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

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

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

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

Договор привязан к определённой версии

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

• Файл открывается участнику. Приёмку проводят с его правами, иначе администратор может не заметить закрытый доступ.
• Редакция различима. Сотрудник понимает, что изменилось после возврата, и не принимает прежний текст за исправленный.
• Правка запускает нужное действие. Компания заранее определила, когда требуется повторное рассмотрение и кому направить изменённый документ.
• Итог хранится отдельно и понятно. После подписания сотрудники находят финальный документ, а не один из промежуточных вариантов переписки.

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

Задержка не оставляет заявителя без ответа

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

• Текущее место видно. Инициатор понимает, у кого находится запрос и ждут ли от него уточнений.
• Просрочка имеет адресата. Назван сотрудник, который замечает задержку и вправе назначить замену или изменить срок.
• Возврат объяснён. Автор видит, что нужно исправить, а повторная отправка сохраняет связь с исходной заявкой.
• Отмена обработана. Когда потребность исчезла, запрос можно закрыть по принятому правилу, не оставляя исполнителям бессмысленных заданий.

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

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

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

Испытание проходит по всем существенным исходам

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

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

После каждого испытания сохраняют номер тестового запроса, выполненное действие, ожидаемое поведение и фактический исход.

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

Сотрудники повторяют процесс без разработчика

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

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

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

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