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

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

Что входит в задание бизнес-процесса и где его границы

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

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

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

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

Исходные данные и ответственные: кто за что отвечает

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

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

В настройках задания ответственных можно выбрать несколькими способами. Конкретный сотрудник, несколько в определённом порядке или любой из списка. Есть предустановленные варианты: очередь ответственных с опциями «любой из списка», «несколько любых сотрудников», «все по очереди», «все сразу»; а также руководители сотрудника по структуре, когда исполнители определяются автоматически. Для варианта с руководителями доступны пропуск отпусков, назначение заместителя и указание лиц, принимающих решение. Эти настройки зависят от прав доступа и конфигурации структуры компании.

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

Варианты заданий и критерии выбора

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

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

При настройке задания «утвердить или отклонить» открывается слайдер с вкладками «Основные» и «Поля, которые надо показать». В основных указывают название и описание действия, ответственных, кнопки и стадию перехода после выполнения. На вкладке полей выбирают, что увидит ответственный в карточке элемента. Это ключевой момент: если поле не показано, сотрудник не сможет принять решение.

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

Предметная последовательность действий на шаге

Сотрудник видит задание в списке бизнес-процессов. В мобильном приложении путь такой: Меню > Бизнес-процессы. Там отображаются процессы с участием: запущенные самостоятельно и те, по которым нужно выполнить задание. Когда появляются новые задания, загорается счётчик с общим количеством.

Чтобы выполнить одно задание, внизу нужного процесса выбирают действие или нажимают «Подробнее», чтобы посмотреть информацию о процессе. Если заданий несколько, их можно отметить в списке и выполнить действие сразу во всех. Задания одного типа — например, только утвердить или только ознакомиться — применяются ко всем выбранным процессам сразу. Задания разных типов открываются по очереди: после выполнения первого Битрикс24 предложит выполнить другие процессы с таким же заданием.

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

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

Матрица ролей и действий на шаге задания

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

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

Учебный пример: согласование заявки на закупку

Учебный пример. Компания «Ромашка» (название условное) настраивает процесс согласования заявки на закупку. Входные условия: заявку создаёт сотрудник отдела закупок, утверждает руководитель отдела, затем финансовый контролёр. Если сумма превышает лимит, добавляется шаг с директором. Всего четыре стадии: «Новая», «У руководителя», «У финансиста», «Утверждено». Финальная успешная стадия — «Утверждено».

На стадии «У руководителя» настраивается задание «утвердить или отклонить». Ответственный — руководитель отдела закупок. В карточке показываются поля: номер заявки, сумма, контрагент, обоснование. Кнопки: «Утвердить» и «Отклонить». При утверждении элемент переходит на стадию «У финансиста». При отклонении — возвращается на «Новую» с обязательным комментарием.

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

Проверка: запускаем тестовую заявку на сумму ниже лимита. Руководитель утверждает — процесс уходит финансисту. Финансист утверждает — заявка переходит на стадию «Утверждено». Затем тестовая заявка с суммой выше лимита: после финансиста появляется задание директору. Проверяем возврат: руководитель отклоняет заявку — она возвращается на «Новую», инициатор видит комментарий. Если комментарий не заполнен, процесс не должен пропускать возврат — это настраивается обязательностью поля.

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

Как вернуть шаг на доработку и что видит инициатор

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

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

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

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

Типичные ошибки при настройке заданий

Ошибка первая: не показаны поля, нужные для решения. Исполнитель видит задание, но не видит сумму или контрагента. Решение — вынести поля на вкладку «Поля, которые надо показать».

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

Ошибка третья: возврат ведёт не туда. Кнопка «Отклонить» переводит процесс на финальную стадию или удаляет элемент вместо возврата на предыдущую. Проверьте стадии перехода в настройках кнопок.

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

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

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

Ошибка седьмая: роли пересекаются. Один сотрудник одновременно и утверждает, и принимает результат. Это снижает контроль. Разделите роли там, где это возможно.

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

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

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

Ограничения и что проверить перед запуском

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

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

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

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

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