Антон Дегтярёвпроекты vs задачи vs смарт-процессы в битрикс24: когда что использовать
В 6 из 10 аудитов вижу одну и ту же картину: смарт-процесс настроен там, где хватило бы обычной задачи с чек-листом, а рядом простаивает модуль «Проекты», в который никто не заходит вторую неделю. Путаница объяснима — три инструмента в интерфейсе выглядят похоже, а решают разные вещи. Разбираю, что для чего, и даю матрицу выбора, которой пользуюсь сам на аудитах.
три инструмента — и почему их в битрикс24 вообще три
Задачи, Проекты и Смарт-процессы решают на первый взгляд одно и то же — организуют работу людей. На деле у каждого своя единица учёта. У Задачи единица — одно поручение одному ответственному с дедлайном. У Проекта единица — группа задач и людей вокруг одной инициативы с датой начала и конца. У Смарт-процесса единица — типовой объект, который повторяется десятками в месяц и проходит через одни и те же стадии.
Путаница возникает, потому что визуально всё похоже: канбан-доска, стадии слева направо, комментарии, файлы. На моих аудитах примерно в половине случаев компания выбрала инструмент не по задаче, а по тому, что «на демонстрации показалось похоже на Trello» — и потом полгода живёт с неудобной схемой, потому что переносить накопленные данные в другой модуль никто не хочет.
когда хватает обычных задач
Задачи закрывают разовые поручения и небольшой поток работы одного человека или команды до 5–7 человек, где не нужно отслеживать поток однотипных объектов. Внутри задачи уже есть подзадачи, чек-лист, учёт затраченного времени, повторяющиеся задачи по расписанию (еженедельный отчёт, ежемесячная сверка) и делегирование с контролем срока.
Работает правило: если поручений в месяц меньше 15–20 и у них нет общей воронки стадий — задач достаточно. Например, «подготовить презентацию для клиента», «согласовать макет баннера», «выгрузить отчёт по продажам за квартал» — это разовые вещи с одним ответственным, для них смарт-процесс избыточен, а модуль «Проекты» просто не нужен.
когда нужен модуль «проекты»
Проект — это не просто список задач, а инициатива с датой начала и конца, несколькими участниками и результатом, который нельзя измерить одной галочкой «сделано». У проекта есть диаграмма Ганта с зависимостями между задачами, распределение нагрузки по участникам и общий срок, который двигается, если сдвигается хотя бы одна веха.
Типичные примеры из практики: запуск нового филиала (юрлицо, аренда, найм, реклама — 40+ задач с зависимостями), ремонт офиса перед переездом, внедрение нового продукта в линейку. У меня есть отдельный разбор, как быстро собрать такой проект с ролями и шаблонами — про модуль «Проекты AI». Признак, что вам нужен именно проект, а не пачка задач: если руководитель на планёрке спрашивает «а мы вообще успеваем к сроку» — и на этот вопрос по разрозненным задачам ответить нельзя, потому что нет общей картины зависимостей.
когда нужен смарт-процесс
Смарт-процесс нужен, когда объектов много, они однотипны и проходят по стадиям с CRM-логикой — но не являются продажей. Заявки на ремонт оборудования, согласование договоров, обращения в поддержку, заказ пропусков. У каждого объекта — свои поля, своя воронка, свои роботы на переходах между стадиями.
Я подробно разбирал устройство смарт-процессов, три рабочих сценария из практики и стоимость настройки в отдельной статье — смарт-процессы в Битрикс24: что это и когда они нужны. Здесь коротко: смарт-процесс окупается, когда поток стабильный и превышает 15–20 объектов в месяц на процесс. Меньше — обычно хватает доработанной задачи с дополнительными полями.
матрица выбора — 4 вопроса, которые я задаю на аудите
Вопрос 1 — сколько однотипных объектов проходит через процесс в месяц? Меньше 15 — задача, больше — смарт-процесс.
Вопрос 2 — есть ли у активности дата начала и конца, после которой она закрывается навсегда? Да, и участников больше трёх — проект.
Вопрос 3 — нужна ли отдельная карточка со своими полями, не похожими на поля сделки? Да — смарт-процесс, нет — задачи или проект.
Вопрос 4 — нужна ли автоматика на переходах между стадиями (уведомления, назначение ответственного)? Да, а поток разовый — бизнес-процесс, а не смарт-процесс. Про разницу между БП и смарт-процессом у меня есть отдельный материал — бизнес-процессы в Битрикс24.
ошибка из практики: проект вместо смарт-процесса
У клиента с сервисным центром заявки на ремонт вели как отдельные проекты в диаграмме Ганта — на каждую заявку заводили новый проект с задачами «диагностика», «заказ запчасти», «ремонт», «выдача». При 30+ заявках в месяц список проектов превратился в нечитаемую портянку, а Гант показывал зависимости, которых там не было — заявки друг от друга не зависят.
Перенесли на смарт-процесс с теми же стадиями за один день: стадии стали воронкой, отчёт по среднему времени закрытия заявки появился сам собой из статистики по стадиям, а Гант убрали за ненадобностью. Экономия на отчётности — не в деньгах, а в том, что руководитель перестал вручную сводить статус по 30 открытым «проектам» раз в неделю.
ошибка из практики: смарт-процесс для разовой активности
Обратный случай — компания настроила смарт-процесс «согласование бюджета» для двух согласований в квартал. Стадии, поля, роботы — вся механика смарт-процесса под поток, которого физически не существует. На поддержку такой конструкции уходит больше времени, чем на сами согласования: раз в три месяца кто-то вспоминает, как в ней вообще работать.
Для двух-трёх согласований в квартал хватает обычной задачи с чек-листом «согласовал финансист → согласовал директор» и файлом бюджета во вложении. Правило простое: не заводите постоянную инфраструктуру под нерегулярный поток, даже если один раз показалось, что «так солиднее».
как я переношу процесс при смене инструмента
Если поток вырос и задачи перестали справляться, перенос делаю в три шага. Шаг 1 — фиксирую реальные стадии текущего процесса, глядя на то, что люди уже делают, а не как должно быть по инструкции. Шаг 2 — переношу активные объекты вручную: для 10–20 штук это быстрее, чем писать скрипт миграции, для полусотни и больше — выгружаю списком и завожу через импорт с привязкой полей. Шаг 3 — две недели веду параллельно старый и новый инструмент, чтобы не потерять объект, который случайно забыли перенести, и только потом закрываю доступ к старому месту.
Обратный перенос — из смарт-процесса в задачи — делаю крайне редко: если поток объектов упал ниже 15–20 в месяц, обычно проще оставить смарт-процесс как есть и просто не усложнять его новыми полями, чем тратить время на демонтаж работающей схемы.
Если самостоятельно разбираться со сменой инструмента некогда — обычно это разовая работа на 1–3 дня в рамках регулярного сопровождения, а не отдельный проект внедрения с нуля.
какую отчётность даёт каждый инструмент
У задач отчётность минимальна — список выполненных и просроченных по сотруднику, без сводной аналитики по потоку. Для разовых поручений этого достаточно, но пытаться построить на задачах отчёт «сколько объектов в стадии X» бессмысленно — там просто нет понятия стадии как такового.
У проекта отчётность строится вокруг сроков — сколько задач выполнено от плана, где отставание от диаграммы Ганта, кто из участников перегружен. Это отчётность про время и людей, а не про поток однотипных объектов.
У смарт-процесса отчётность — про воронку: сколько объектов в каждой стадии сейчас, среднее время прохождения стадии, процент объектов, которые закрылись без результата. Именно эта отчётность чаще всего нужна руководителю, который спрашивает «сколько заявок мы обрабатываем в месяц и где узкое место» — и её физически нельзя получить из задач или из диаграммы Ганта, какой бы подробной она ни была.