Канбан в Битрикс24: как управлять задачами с роботами и WIP-лимитами

Настройка канбан досок Битрикс24: где ломается поток задач

Канбан-доска в Битрикс24 выглядит рабочей ровно до момента, когда на стадии «В работе» одновременно висит тридцать карточек. Исполнитель берётся за всё сразу, сроки сдвигаются, а руководитель узнаёт о проблеме по факту просрочки — прозрачность потока остаётся только на бумаге.

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

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

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

Эффект от перестройки потока: сроки, потери, прозрачность

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

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

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

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

Форматы представления задач: что выбрать под свой процесс

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

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

Что чем закрывается

Переключение вида не пересоздаёт данные: задачи, стадии и поля общие, меняются только правила. Шаблоны досок фиксируют структуру колонок, права и автоматизации, поэтому новый проект поднимают копией, а не собирают с нуля.

Этапы внедрения: от аудита потока до передачи регламентов

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

1. Аудит потока задач. Выгружаем историю по стадиям: сколько времени карточка висит в каждой колонке, где скапливается основная масса, кто чаще других возвращает назад. На выходе — перечень узких мест с числами.
2. Схема стадий. Собираем колонки под реальные шаги работы: что разносим, что объединяем, какую стадию делаем финальной с автоматическим закрытием. Здесь же закладываем WIP-лимиты — предел одновременных задач на исполнителя.
3. Роботы и триггеры. На каждую стадию назначаем робота: постановка следующей задачи, уведомление клиенту, смена ответственного, дедлайн этапа. Триггеры привязываем к событиям доски — переход срабатывает при смене стадии, а не вручную.
4. Правила переходов. Определяем обязательные поля, запрещаем проскок стадий, разграничиваем права: кто двигает карточку, кто только смотрит. Доска перестаёт зависеть от одного администратора.
5. Приёмочная проверка. Прогоняем контур на реальных задачах — от постановки до закрытия, с возвратами и отклонениями. Смотрим, где робот не сработал, где лимит мешает нужному, и правим до передачи.
6. Передача регламентов. Отдаём схему доски, карту роботов и триггеров, памятку по обязательным полям, чек-лист администратора. Плюс короткое обучение команды, чтобы правила жили, а не остались в документе.

Артефакты проекта: схема потока, правила, инструкции

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

• Схема канбан-доски — перечень стадий, порядок их прохождения, WIP-лимиты по каждой колонке и условия, при которых задача считается завершённой, а не просто перетащенной.
• Матрица прав доступа — кто из ролей создаёт задачи, кто двигает карточки, кто меняет справочники и настройки стадий; отдельно отмечены операции, доступные только администратору.
• Регламент работы с задачами — что делает исполнитель, если задача стоит в колонке дольше оговорённого срока, куда эскалируется блокировка и кто снимает лимит при перегрузке.
• Карта автоматизаций — на каких стадиях висят роботы и триггеры, какие поля и ответственных они меняют, какие действия отрабатывают при ошибке.
• Инструкция для сотрудников — короткий документ на 4–6 сценариев: постановка задачи, взятие в работу, передача, закрытие, возврат из проверки.
• Чек-лист сопровождения — регулярные проверки: рост числа карточек в колонке, задачи без движения и без ответственного, дубли, сработавшие роботы с ошибкой, расхождение фактических стадий со схемой.
• Журнал изменений и точки отката — перед каждой правкой сохраняется рабочая конфигурация, поэтому неудачное изменение откатывается к предыдущему состоянию за минуты.

Кейс: как убрали потерянные задачи и сократили сроки

Проект с двумя потоками работ: заявки от бизнес-подразделений и внутренние доработки продукта. И то и другое шло по одной доске — заявки, инциденты, согласования и технический долг стояли в общих колонках. Лимитов не было, роботы на переходах не настроены, поэтому карточки накапливались в статусах «в работе» и «на проверке» и уходили в отчёт как зависшие.

Что было до перестройки

Медианный срок прохождения задачи — 19 рабочих дней, почти треть задач висела дольше двух недель без движения. Просрочки по задачам с дедлайном — около 40 %, при этом на двух исполнителях одновременно держалось по 14–16 активных карточек. Учёт смешанный: заявка клиента, доработка и внутренняя задача считались одной метрикой, поэтому руководитель не видел, где именно теряется время.

Что изменили и что получили

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

В результате медианный срок прохождения сократился до 11 рабочих дней, доля зависших задач — с 25–30 % до 5–6 %. Число просрочек упало примерно втрое. Загрузка выровнялась: лимит не даёт взять новую задачу, пока не закрыта текущая, поэтому разброс по исполнителям сократился, а перегруз виден прямо на доске, а не по итогам квартала.

Технические сомнения: лимиты, роли, отчёты, интеграции

Канбан в Битрикс24 редко бывает «просто доской»: он опирается на стадии, права ролей, роботов и отчётность, и просчёт в одном слое всплывает через неделю-две — задачи копятся в одной колонке, часть сотрудников видит лишние сделки, а руководитель не может собрать срез по нагрузке. Ниже — то, что чаще всего уточняют перед началом работ.

Как права доступа сочетаются с ролями в подразделениях?

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

Какие отчёты реально строятся по канбану?

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

Как канбан связывается с учётом сделок?

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

Что происходит с уже накопленными задачами при переходе?

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

Обсудим задачу: что прислать для оценки и плана

Чтобы вернуться с оценкой и планом работ, а не с общими формулировками, нам нужен минимальный набор вводных. Достаточно описать текущий процесс своими словами — схему потока, лимиты по стадиям и порядок запуска мы соберём сами. Чем конкретнее вводные, тем точнее оценка.

• Задача и команды. Какие подразделения работают в Битрикс24, сколько человек в каждом, какие типы задач преобладают — регулярные, проектные, обращения клиентов.
• Текущие доски. Скриншоты или выгрузка существующих канбан-досок: стадии, ответственные, на каком шаге задачи застревают дольше всего.
• Примеры досок. Если ориентируетесь на чужой опыт — пришлите образцы, которые нравятся. Разберём, что из них переносится на ваш процесс, а что останется красивой картинкой.
• Точки боли. Где теряются задачи, какие этапы простаивают, кто перегружен. Именно это определяет, каких роботов и правил автоматизации не хватает.
• Перечень доступов. Портал Битрикс24 с правами администратора, доступ к 1С при необходимости синхронизации, рабочая почта для уведомлений и роботов.
• Ограничения. Внутренние регламенты, требования к хранению данных, запреты на внешние сервисы — от них зависит итоговая схема.
• Порядок запуска. Что важнее закрыть первым: одну команду или сразу все, и к какому сроку нужен рабочий контур.

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

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

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

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

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