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