Штатные бизнес-процессы Битрикс24 хорошо решают задачу автоматизации отдельных действий: отправить документ на согласование, поставить задания нескольким сотрудникам, дождаться решения, вернуть документ на доработку, сохранить историю.
Проблема начинается позже — когда таких процессов становится много.
У сотрудника задания находятся в одном месте, инициированные процессы — в другом, документы — в списках или CRM, комментарии и уведомления — в живой ленте. Руководителю еще сложнее: чтобы понять, где сейчас находится конкретный документ и на каком этапе возникают задержки, приходится собирать картину из нескольких разделов портала.
В одном из проектов мы столкнулись именно с такой задачей. Саму логику согласования можно было реализовать штатными средствами Битрикс24. Но пользователям требовался не еще один бизнес-процесс, а полноценный рабочий интерфейс поверх него.
Так появился отдельный кабинет документооборота в виде локального приложения Битрикс24.
Содержание
- Задача: не просто согласовать документ
- Что нормально делает штатный бизнес-процесс Битрикс24
- Почему стандартного интерфейса бизнес-процессов оказалось недостаточно
- Решение: локальное приложение внутри Битрикс24
- Один экран вместо пяти разделов
- Дашборд сотрудника
- Блок «Требуют моего решения»
- Мои запущенные процессы
- История в человеческом виде
- Версии документов
- Умная форма запуска
- Матрица согласования
- Дашборд руководителя
- Воронка документов
- Узкие места
- Разрез по организациям и направлениям
- Входящая корреспонденция
- Свободные документы
- Почему приложение не должно заменять бизнес-процессы
- Почему такой подход удобен для развития
- Как мы обычно идем от прототипа к production
- Что стоит определить до начала разработки
- Итог
Задача: не просто согласовать документ
На первый взгляд схема стандартная:
- Пользователь создает исходящий документ.
- Система определяет маршрут согласования.
- Несколько сотрудников одновременно получают задания.
- Каждый может согласовать документ, отклонить его или делегировать задание.
- При отклонении документ возвращается инициатору на доработку.
- После исправлений запускается новый цикл согласования.
- После полного согласования документ передается на финальный этап.
- Готовый документ поступает дальше в процесс исполнения.
Отдельно работает контур входящей корреспонденции:
- регистрация документа;
- присвоение входящего номера;
- назначение ответственного;
- контроль срока ответа;
- фиксация результата;
- связь входящего документа с исходящим ответом.
Кроме этого, маршрут согласования может зависеть сразу от нескольких параметров документа.
Например:
- выбранной организации;
- типа документа;
- дополнительного классификационного признака;
- региона;
- категории договора.
Для разных комбинаций должен автоматически использоваться разный набор согласующих.
Добавим сюда собственную нумерацию, версии документов, историю согласований и несколько параллельных процессов — и задача быстро перестает быть простой.
Что нормально делает штатный бизнес-процесс Битрикс24
Сам процесс согласования мы не стали заменять собственной системой. Это принципиальный момент. Штатный движок бизнес-процессов Битрикс24 уже умеет:
- запускать задания согласующим;
- отправлять их параллельно;
- фиксировать результат;
- сохранять комментарии;
- управлять правами;
- возвращать документ на доработку;
- вести историю;
- запускать последующие этапы.
То есть заново программировать workflow engine нет никакого смысла. Проблема была не в движке. Проблема была в интерфейсе.
Почему стандартного интерфейса бизнес-процессов оказалось недостаточно
Представим обычного сотрудника. Сегодня ему нужно ответить на четыре вопроса:
- какие документы сейчас ждут моего согласования;
- какие из них уже просрочены;
- что происходит с документами, которые запустил я;
- какие входящие документы ждут моего ответа.
Штатно эти данные могут находиться в нескольких разделах Битрикс24.
Для одного-двух процессов это терпимо.
Для полноценного документооборота — уже нет.
Руководителю нужен еще более широкий взгляд:
- сколько документов сейчас в работе;
- сколько просрочено;
- на каких стадиях возникает очередь;
- сколько в среднем занимает согласование;
- у кого из сотрудников накопилось больше всего заданий;
- какие процессы постоянно возвращаются на доработку;
- где нарушаются сроки работы с корреспонденцией.
Сам бизнес-процесс способен выполнить маршрутизацию, но не дает удобного управленческого интерфейса для всей системы.
Решение: локальное приложение внутри Битрикс24
Мы решили оставить бизнес-процессы в качестве backend-логики, а поверх них сделать отдельное локальное приложение.
В результате в Битрикс24 появляется отдельный пункт меню, например:
Документооборот
Пользователь открывает его и видит не технический список процессов, а единый рабочий кабинет.
Приложение встраивается непосредственно внутрь портала и визуально воспринимается как его часть.
Для интеграции можно использовать стандартный механизм локальных приложений Битрикс24 и JavaScript SDK.
На этапе прототипа достаточно даже очень простой реализации:
- один HTML-файл;
- CSS;
- JavaScript;
- без React, Vue и сложной сборки;
- небольшая серверная обертка для корректной работы внутри портала.
Это позволяет сначала быстро показать заказчику UX и бизнес-логику, а уже потом подключать реальные данные через REST API.
Один экран вместо пяти разделов
Главная идея кабинета — собрать весь контур документооборота в одном интерфейсе. В приложении можно разместить:
- дашборд;
- запуск нового исходящего документа;
- регистрацию входящего документа;
- мои задания;
- мои процессы;
- единый реестр документов;
- историю;
- контроль сроков.
Дашборд сотрудника
Для обычного пользователя важна не общая аналитика, а конкретный ответ на вопрос: Что мне сейчас нужно сделать? Поэтому верхнюю часть экрана лучше строить вокруг персональных KPI.
Например:
На согласовании у меня
Показываем общее количество документов и отдельно количество просроченных.
Мои запущенные процессы
Сколько документов пользователь сам отправил в работу.
Дополнительно можно показывать:
- сколько находятся на согласовании;
- сколько вернулось на доработку;
- сколько ожидают финального этапа.
Корреспонденция на ответе
Сколько входящих документов требует реакции пользователя.
Особенно полезно отдельно выделять:
срок ответа сегодня
Ожидают финального согласования
Отдельная категория документов, которые прошли основной маршрут и находятся на заключительном этапе.
Блок «Требуют моего решения»
Это один из самых полезных элементов интерфейса.
Вместо перехода в отдельный список заданий пользователь сразу видит карточки документов:
- название;
- инициатора;
- тип;
- срок;
- текущую стадию;
- комментарии;
- кнопки действий.
Для простых сценариев кнопку «Согласовать» можно разместить прямо в списке.
При отклонении открывается форма комментария.
Причем интерфейс можно сделать строже, чем стандартную форму Битрикс24.
Например:
кнопка подтверждения отклонения физически неактивна, пока пользователь не написал комментарий.
Это мелкая UX-деталь, но в реальном документообороте она сильно снижает количество ситуаций вида:
Отклонено.
Без объяснения причин.
Мои запущенные процессы
Инициатору документа важно видеть не техническое состояние workflow, а понятную стадию.
Например:
На согласовании — 3 из 4
или:
На доработке
или:
Финальное согласование
или:
Передан на исполнение
При этом сама логика может оставаться внутри стандартного бизнес-процесса.
Фронтенд просто преобразует технические состояния в понятные пользователю статусы.
История в человеческом виде
Для каждого документа полезно показывать единую хронологию.
Например:
10:12 — Иван Петров согласовал документ
10:37 — Анна Соколова отклонила документ
Комментарий:
Требуется уточнить условия в разделе 4.
11:05 — инициатор загрузил новую версию
11:06 — согласование запущено повторно
В стандартной системе подобная информация тоже может храниться.
Но когда она собирается в одном месте и оформляется как нормальная timeline-лента, документ становится гораздо проще сопровождать.
Версии документов
Цикл согласования редко заканчивается с первой попытки.
Поэтому версия должна быть самостоятельной частью интерфейса.
При отклонении:
- текущая версия сохраняется;
- инициатор получает замечания;
- загружает новую;
- предыдущая остается доступна в архиве;
- запускается новый цикл.
В карточке документа пользователь может открыть:
Версия 1
Версия 2
Версия 3
и посмотреть, на каком этапе и почему появился каждый вариант.
Для production-решения файлы можно хранить на Диске Битрикс24 либо в отдельном связанном реестре версий.
Умная форма запуска
Это один из тех элементов, где собственный интерфейс дает особенно заметный выигрыш.
В стандартном бизнес-процессе пользователь чаще всего видит набор параметров:
- организация;
- вид документа;
- регион;
- согласующие;
- дополнительные признаки.
Но эти поля практически не взаимодействуют между собой.
В собственном кабинете можно сделать динамическую форму.
Например, пользователь меняет организацию — и интерфейс сразу:
- перестраивает доступные виды документов;
- пересчитывает маршрут;
- показывает будущую группу согласующих;
- меняет дополнительные поля;
- пересчитывает номер документа.
Условно:
126 / ДОГ / 50
пользователь видит еще до запуска процесса.
Если какой-то параметр нужен только для одной категории документов, он появляется только тогда, когда действительно требуется.
В итоге пользователю не приходится разбираться в логике маршрутизации.
Система сама показывает только релевантные параметры.
Матрица согласования
В реальной системе маршруты лучше не зашивать непосредственно в код интерфейса. Правильнее создать отдельный справочник. Например:
| Организация | Вид документа | Дополнительный признак | Согласующие |
|---|---|---|---|
| Компания 1 | Договор | Вариант A | Группа 1 |
| Компания 1 | Договор | Вариант B | Группа 2 |
| Компания 2 | Приказ | — | Группа 3 |
Тогда администратор может менять маршруты без доработки приложения.
Для хранения такой матрицы можно использовать:
- универсальные списки;
- смарт-процессы;
- отдельный справочник;
- собственную таблицу приложения.
Приложение при запуске документа просто определяет нужную строку и передает найденных сотрудников в бизнес-процесс.
Дашборд руководителя
Руководителю уже не нужно видеть отдельные задания. Ему нужна картина всего процесса. Поэтому интерфейс можно переключить в управленческий режим.
Процессы в работе
Общее количество активных документов.
Среднее время согласования
Полезно не только само значение, но и динамика:
- за текущий месяц;
- за прошлый месяц;
- по типам документов;
- по подразделениям.
Просроченные задания
Количество документов, где нарушен SLA.
Документы на доработке
Если их слишком много, проблема может быть не в скорости сотрудников, а в качестве документов на входе.
Воронка документов
Один из самых наглядных управленческих блоков:
Черновик → Согласование → Доработка → Финальный этап → Исполнение
По каждой стадии видно количество документов.
Если в каком-то месте постоянно накапливается очередь, это становится заметно сразу.
Узкие места
Еще один важный блок — нагрузка на согласующих.
Например:
| Сотрудник | В очереди | Просрочено | Максимальная просрочка |
|---|---|---|---|
| Сотрудник 1 | 12 | 4 | 3 дня |
| Сотрудник 2 | 7 | 0 | — |
| Сотрудник 3 | 18 | 6 | 5 дней |
Такая таблица переводит документооборот из режима:
Почему договоры долго согласовываются?
в режим:
На конкретном этапе накопилось 18 заданий, шесть из них просрочены.
Это уже данные, на основании которых можно менять процесс.
Разрез по организациям и направлениям
Если в одном портале работают несколько компаний или подразделений, полезно сравнивать:
- количество активных процессов;
- количество просрочек;
- среднее время согласования;
- количество возвратов на доработку.
В стандартных бизнес-процессах подобная аналитика обычно не является частью интерфейса.
В собственном кабинете она становится обычным фильтром или виджетом.
Входящая корреспонденция
Тот же кабинет удобно использовать и для обработки входящих документов.
Например, сотрудник видит:
- новые входящие;
- документы на ответе;
- срок сегодня;
- просроченные;
- закрытые.
Руководитель — агрегированную картину:
В срок / Срок сегодня / Просрочено
Если исходящий документ является ответом на входящий, между ними создается связь.
Тогда в карточке можно видеть весь цикл:
входящий документ → задача → подготовленный ответ → исходящий документ
Свободные документы
Не все документы требуют сложного маршрута.
Например, некоторые внутренние документы могут согласовываться по упрощенной схеме.
Для этого не обязательно создавать отдельный интерфейс.
В той же форме можно добавить режим:
Свободный документ
После его выбора система:
- отключает стандартную матрицу;
- позволяет выбрать согласующих вручную;
- убирает ненужные этапы;
- запускает более простой workflow.
Для пользователя это по-прежнему один кабинет.
Почему приложение не должно заменять бизнес-процессы
Можно было бы написать собственную систему согласования целиком.
Но в большинстве случаев это лишняя сложность.
Лучше разделить ответственность.
Битрикс24 отвечает за:
- workflow;
- задания;
- права;
- события;
- историю;
- автоматизацию;
- уведомления.
Локальное приложение отвечает за:
- удобную форму запуска;
- единую точку входа;
- визуализацию;
- дашборды;
- аналитику;
- быстрые действия;
- понятные статусы.
Получается архитектура:
Интерфейс → REST API → штатные бизнес-процессы Битрикс24
Например, приложение может использовать методы для:
- запуска workflow;
- получения заданий;
- чтения списков;
- работы со смарт-процессами;
- загрузки документов.
При этом существующая бизнес-логика остается внутри Битрикс24.
Почему такой подход удобен для развития
Еще одно преимущество — интерфейс и бизнес-процесс можно развивать независимо.
Допустим, заказчик захотел:
- новый дашборд;
- темную тему;
- дополнительный фильтр;
- быстрый поиск;
- другую форму карточки;
- новые KPI.
Для этого не нужно переделывать сам шаблон бизнес-процесса.
И наоборот, можно изменить маршрут согласования, не меняя большую часть интерфейса.
Это сильно снижает стоимость дальнейшего развития системы.
Как мы обычно идем от прототипа к production
Для подобных проектов удобно начинать не с полной интеграции, а с интерактивного прототипа.
Сначала собирается интерфейс на тестовых данных:
- рабочий дашборд;
- форма запуска;
- карточки документов;
- роли;
- статусы;
- история;
- аналитика.
Заказчик может открыть его прямо внутри Битрикс24 и пройти реальный пользовательский сценарий.
Только после согласования UX начинается интеграция.
Следующий этап обычно включает:
- перенос матрицы согласований в справочник;
- подключение реальных сотрудников;
- автоматическую нумерацию;
- REST-интеграцию с бизнес-процессами;
- работу с файлами;
- реестр версий;
- передачу документов в следующий процесс.
Такой подход позволяет сначала согласовать, как система должна работать для человека, и только потом вкладываться в backend.
Что стоит определить до начала разработки
Есть несколько организационных вопросов, которые лучше решить заранее.
Например:
- кто может менять маршруты согласования;
- кто является владельцем справочников;
- как работает замещение отсутствующих сотрудников;
- может ли инициатор самостоятельно выбрать заместителя;
- кто контролирует просрочки;
- как формируется уникальный номер;
- какие версии документов должны храниться;
- когда документ считается окончательно завершенным.
Эти вопросы обычно сильнее влияют на архитектуру, чем выбор между конкретными UI-компонентами.
Итог
Бизнес-процессы Битрикс24 хорошо подходят для выполнения маршрутов согласования.
Но когда документооборот становится полноценным рабочим контуром, одного workflow уже недостаточно.
Пользователям нужен интерфейс, который отвечает на простые вопросы:
- что требует моего внимания;
- где находится мой документ;
- кто его задерживает;
- что было изменено;
- когда истекает срок.
А руководителю нужен другой уровень:
- где возникают узкие места;
- сколько длится согласование;
- где появляются просрочки;
- какие маршруты работают плохо.
Локальное приложение поверх штатных бизнес-процессов позволяет решить эту задачу без создания собственной workflow-системы с нуля.
В результате Битрикс24 продолжает выполнять то, что умеет хорошо, — процессы и задания. А сотрудники получают нормальный кабинет документооборота вместо набора разрозненных экранов.
