Для этого недостаточно нарисовать несколько прямоугольников со стрелками и подписать исполнителей. В описании нужны границы, роли, данные, сроки, исключения и критерии приемки. Ниже разберем, как собрать их в один рабочий документ.
Начните с владельца процесса
Владелец отвечает за результат процесса целиком, включая сроки, качество, показатели и согласованность действий между подразделениями. Это не обязательно руководитель проекта автоматизации и не обязательно сотрудник, который чаще всех работает в Битрикс24.
Выбирайте владельца по реальным полномочиям менять процесс и утверждать общие правила. Он должен иметь возможность изменить порядок работы, договориться со смежными подразделениями, утвердить правила и принять итоговую схему. Если такого человека нет, заказчику сначала нужно его назначить. Иначе спор о маршруте возникнет уже во время настройки, а решение будет некому принять.
Рядом с владельцем зафиксируйте остальные роли и границы ответственности каждой из них:
- исполнитель выполняет конкретный шаг;
- принимающий решение выбирает ветку маршрута;
- согласующий подтверждает результат;
- администратор поддерживает справочники, права и настройки;
- заместитель принимает работу при отсутствии основного сотрудника.
Один человек может совмещать несколько ролей в разных точках одного маршрута. В таком случае укажите, при каких условиях он действует в каждой из них. Формулировка «ответственный отдел продаж» слишком широкая. Для автоматизации нужно правило назначения по региону, продукту, очереди, клиентскому сегменту или другому признаку.
Определите границы и результат
У процесса должны быть однозначные и проверяемые точки начала и завершения. Начало лучше описывать через конкретное событие, например поступление заявки, переход сделки на этап, подписание документа или запрос сотрудника. Конец тоже выражают наблюдаемым результатом, например принятым решением, согласованным документом, оказанной услугой или обращением с указанной причиной закрытия.
В карточке процесса зафиксируйте пять параметров, которые задают его рабочий контур:
- Событие запуска.
- Условие, при котором процесс не запускается.
- Результат процесса и признак его достижения.
- Объект учета: сделка, заявка, договор, обращение или другой элемент.
- Системы и подразделения на границе процесса.
Такой контур защищает проект от незаметного расширения во время обсуждений и настройки. Например, задача «автоматизировать согласование договора» может включать подготовку шаблона, юридическую проверку, согласование цены, подписание и передачу в учетную систему. Если границы не назвать, участники будут ждать разный результат.
Разложите основной маршрут по шагам
Начните с основного сценария, который проходит без исключений и ручных обходов. Для каждого шага ответьте на одинаковый набор вопросов, собрав ответы в таблицу.
| Поле | Что зафиксировать |
|---|---|
| Вход | Какие данные или документы нужны для начала шага |
| Действие | Что именно делает сотрудник или система |
| Ответственный | Роль и правило назначения |
| Решение | Какие варианты возможны и кто выбирает |
| Результат | Что должно появиться или измениться |
| Срок | Когда шаг должен быть завершен |
| Следующий шаг | Куда идет объект при каждом результате |
Используйте наблюдаемые действия, которые можно проверить по результату шага. Вместо «обработать заявку» напишите, что нужно проверить обязательные поля, связаться с клиентом, записать результат разговора, выбрать причину отказа или перевести заявку на следующий этап. Такой уровень детализации помогает увидеть, каких данных не хватает и где решение остается в голове сотрудника.
На этом этапе не требуется сразу описывать каждый клик в интерфейсе системы. Бизнес-описание фиксирует правила и контрольные точки. Интерфейсные действия уточняют в техническом задании после того, как маршрут согласован.
Если вы хотите пройти этот этап вместе с аналитиком, посмотрите услугу внедрения Битрикс24: команда поможет собрать требования и перевести их в рабочую настройку.
Перечислите данные, документы и права
У каждого решения должно быть понятное участникам и проверяемое информационное основание. Укажите обязательные поля, формат значений, источник данных и того, кто отвечает за их актуальность. Для документов добавьте шаблон, версию, место хранения и условие, при котором документ считается принятым.
Отдельно проверьте права доступа для каждой роли и каждого значимого действия. Сотрудник может видеть карточку, но не иметь права изменить нужное поле. Заместитель может получить задачу, но не видеть вложение. Руководитель может согласовать результат, но не иметь доступа к истории. Такие разрывы обнаруживаются, если для каждого шага записать, кто создает, читает, изменяет и подтверждает данные.
Для спорных понятий полезно составить короткий словарь с проверяемыми определениями. Если «квалифицированная заявка», «готовый договор» или «просроченная задача» допускают разные толкования, автоматическое условие тоже будет спорным.
Добавьте исключения и возвраты
Основной маршрут не охватывает работу целиком, поэтому отдельно разберите ситуации, в которых процесс меняет направление:
- обязательных данных или документов нет;
- сотрудник или клиент отказался продолжать;
- результат вернули на доработку;
- согласующий не ответил вовремя;
- основной ответственный отсутствует;
- один шаг нужно выполнить повторно;
- несколько действий идут параллельно;
- внешняя система недоступна;
- объект оказался дублем или был создан ошибочно.
Для возврата укажите причину, этап назначения и перечень того, что нужно исправить. Возврат «на предыдущий шаг» без комментария создает бесконечный цикл и не дает анализировать причины доработок.
Для согласования перечислите все допустимые варианты решения и дальнейшие переходы. Одного «согласовано / отклонено» может быть мало, если требуется доработка, запрос дополнительных данных или передача другому согласующему. Для замещения задайте момент включения, полномочия заместителя и доступ к истории. Для эскалации опишите событие, адресата, сообщение и действие после уведомления.
Неизвестные исключения можно вынести в отдельный список вопросов с ответственными за ответы. Важно, чтобы они не растворились в переписке и получили владельца решения до приемки.
Настройте сроки и правила паузы SLA
Общий срок процесса полезен для руководителя, но для настройки нужны сроки значимых шагов. Зафиксируйте, когда начинается отсчет, учитываются ли рабочие часы, от чего зависит норматив и что происходит при приближении к сроку.
Особое внимание уделите внешнему ожиданию, на длительность которого исполнитель напрямую не влияет. Например, менеджер отправил клиенту форму и ждет ответ. Если SLA продолжает идти, сотрудник получит просрочку за событие, на которое не влияет. Если счетчик останавливается, должны быть определены причина паузы, подтверждающий статус, дата следующей проверки и условие возобновления.
Для каждого контрольного срока заранее опишите последовательную цепочку реакции на задержку:
- Напоминание ответственному.
- Повторное уведомление или задача заместителю.
- Эскалация руководителю.
- Изменение маршрута, если ожидание превысило предел.
Срок без реакции на нарушение остается только справочной цифрой в карточке процесса. Автоматизация начинается там, где система понимает, что делать при приближении к нормативу и после его нарушения.
Проверьте описание на сценариях
Согласованный текст еще не гарантирует готовность процесса к технической настройке и приемке. Пройдите его на примерах до начала настройки. В минимальный набор проверок включите следующие ситуации:
- основной сценарий с корректными данными;
- запуск без обязательного поля или документа;
- отказ и возврат на доработку;
- просрочку исполнителя или согласующего;
- отсутствие ответственного и включение заместителя;
- повторный запуск для того же объекта;
- параллельные действия;
- сбой обмена с внешней системой;
- разные решения согласующего и проверку прав.
Для каждого сценария запишите исходные условия, ожидаемые шаги и конечный результат. Это станет основой приемочных тестов. Если участники не могут договориться, что должно произойти в одном из сценариев, настройку этой ветки начинать рано.
Соберите требования в единый комплект
После обсуждений могут остаться схема в одном файле, сроки в переписке, таблица полей в другом документе и устные договоренности о замещении. Такой набор ненадежен для оценки: аналитику непонятно, какое правило актуально, заказчик не может проверить полноту.
Соберите согласованную версию в единый комплект для оценки, настройки и последующей приемки. В состав комплекта включите следующие элементы:
- краткая карточка процесса с владельцем, целью, началом и результатом;
- схема основного маршрута и исключений;
- таблица шагов, ролей, сроков и переходов;
- перечень полей, документов, справочников и интеграций;
- матрица прав доступа и правила замещения;
- список уведомлений, напоминаний и эскалаций;
- приемочные сценарии с ожидаемым результатом;
- реестр открытых вопросов с ответственными и сроками решения.
Укажите версию документа, дату согласования и владельца актуальной редакции требований. Если правило меняется, обновляйте сам документ вместе с сообщением в чате. Рядом с изменением полезно записать причину и влияние на маршрут, сроки или оценку. Такой порядок снижает риск настройки устаревшего варианта.
До передачи проверьте комплект с представителями всех затронутых ролей. Исполнитель подтвердит, что шаг можно выполнить на практике. Руководитель проверит точки контроля. Администратор оценит доступы и справочники. Владелец примет спорные решения. Аналитик соберет из согласованной модели техническое задание и отделит бизнес-правила от деталей настройки.
Не смешивайте обязательные требования первой версии с идеями на будущее. Для каждой последующей идеи укажите ожидаемую пользу и зависимость, но не включайте ее молча в текущий объем. Это помогает сравнивать оценку с согласованными границами и принимать именно тот результат, который был заказан.
Пример: процесс опроса после завершения работы
Рассмотрим обезличенный пример из проекта по сбору обратной связи. После завершения сделки менеджер проверяет контактные данные и переводит объект на контрольный этап. Система определяет, проходил ли клиент опрос ранее.
Если ответа еще нет, клиенту отправляют форму, а в карточке фиксируют дату и статус отправки. Через заданный интервал система проверяет результат и выбирает дальнейшую ветку. При получении ответа создается запись в реестре обратной связи, а ответственному сотруднику ставится задача разобрать оценку. Если ответа нет, отправляется повторное приглашение. После предельного срока маршрут завершается отдельным статусом и задачей на ручную проверку. Для ошибочного или преждевременного запуска предусмотрен возврат в исходное состояние с возможностью повторить процесс.
Этот пример показывает, какие детали нужны кроме стрелок: источник контактных данных, признак уже заполненного опроса, интервалы проверок, число повторов, конечный статус без ответа, ответственный за разбор оценки и правило ручного перезапуска. Сроки здесь являются параметрами конкретного процесса, их утверждает владелец.
Чек-лист готовности к автоматизации
Описание можно передавать в оценку и техническое задание, если выполнены все условия:
- назначен владелец с полномочиями принимать решения;
- определены событие запуска, результат и границы;
- основной маршрут разложен на проверяемые шаги;
- для каждого шага заданы вход, действие, роль, срок и выход;
- перечислены обязательные данные, документы и источники;
- зафиксированы варианты решений и права доступа;
- разобраны возвраты, отказы, отсутствие данных и сбои;
- настроены замещение, напоминания и эскалации;
- для SLA указаны правила старта, паузы и возобновления;
- подготовлены приемочные сценарии;
- открытые вопросы вынесены отдельно и имеют ответственных.
Итоговое описание не обязано быть большим или перегруженным техническими деталями. Его качество определяется тем, можно ли по нему одинаково ответить на три вопроса: что настраивать, как оценить объем работ и по каким сценариям принимать результат.
Перед финальным согласованием проведите короткую встречу по нерешенным вопросам и зафиксируйте ответы прямо в комплекте. После этого владелец подтверждает бизнес-логику, а аналитик отмечает допущения и зависимости оценки. Если во время настройки появляется новое правило, его сначала согласуют и добавляют в описание вместе с новым тестовым сценарием. Такой порядок сохраняет связь между договоренностью, реализацией и приемкой.
Если процесс затрагивает несколько подразделений, данные из разных систем или сложные согласования, запросите консультацию по внедрению Битрикс24. До оценки специалисты Соль помогут уточнить границы, роли и спорные ветки.
Часто задаваемые вопросы
Нужно ли рисовать BPMN-схему?
Для первого согласования достаточно понятной блок-схемы и таблицы шагов. BPMN полезна для сложных маршрутов с событиями, параллельными ветками и большим числом участников, но сама нотация не заменяет правила назначения, сроки, данные и критерии приемки.
Кто должен описывать процесс: руководитель или аналитик?
Владелец процесса определяет правила и принимает решения, сотрудники дают фактуру о реальной работе, аналитик помогает убрать противоречия и перевести договоренности в однозначную модель. Полностью делегировать содержание аналитику рискованно, поскольку он не может самостоятельно утвердить бизнес-правила.
Можно ли автоматизировать процесс, который пока меняется?
Можно выделить устойчивую часть и отдельно перечислить правила, по которым еще нет решения. Сначала стоит автоматизировать согласованный контур, а изменяемые ветки оформить как последующие итерации. При этом границы первой версии и критерии ее приемки должны быть однозначными.
Насколько подробно описывать действия сотрудников?
Детализации достаточно, когда для каждого шага понятны входные данные, действие, роль, результат, срок и следующий маршрут. Описание каждого клика обычно появляется позже, в техническом задании или инструкции пользователя.
Что делать с SLA во время ожидания клиента?
Заранее выберите, продолжает ли счетчик идти или ставится на паузу. Для паузы нужны основание, статус, дата следующей проверки и событие возобновления. Тогда ожидание не скрывает просрочки и не создает ложные нарушения.
Как понять, что описание готово к оценке?
Передайте его человеку, который не участвовал в обсуждении, и попросите пройти основной, ошибочный и просроченный сценарии. Если он понимает роли, переходы, данные и ожидаемый результат без устных пояснений, описание можно переводить в техническое задание и оценку.
