Настройка BPMSoft: почему low-code - это больше, чем просто поля на карточке

Именно с этой фразы начинается большинство разговоров о low-code на планерках и в переговорных. Звучит она обычно с легкой иронией - мол, понятно нам, что за зверь этот ваш BPMSoft. Форму набросать, поля расставить, кнопку покрасить. Программист не нужен, тестировщик не нужен, за обедом закончим.

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

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

Пока вы воспринимаете low-code как конструктор форм, кто-то другой использует его для автоматизации всего цикла от заявки клиента до отгрузки и оплаты - без единой строчки кода.

Цель этой статьи - разобраться честно: что современный low-code умеет на самом деле, где его предел и как выглядит это в реальной работе аналитика или руководителя процессов.

Раньше low-code действительно был ближе к продвинутому LEGO: собрать быстрый прототип, показать заказчику, что «вот примерно так выглядит идея». На этом - всё. Дальше шла настоящая разработка с ТЗ, спринтами и тестированием.

Но рынок потребовал другого. Бизнесу нужна была не просто витрина с нарисованными процессами, а работающая машина, которая сама ведет заявку по маршруту, сама дергает данные из 1C, сама назначает исполнителей и следит за сроками. Запрос изменился - и платформы изменились вслед за ним.

Сегодня low-code - это прежде всего среда для визуального моделирования того, что происходит между интерфейсами. Не «как выглядит», а «как работает». Данные текут из одной системы в другую, правила срабатывают при изменении статуса, задача назначается нужному человеку в нужный момент - и всё это описывается визуально, без написания кода.

BPMSoft - хороший пример того, как эта эволюция реализуется на практике. Это не набор разрозненных конструкторов («здесь формы», «здесь кнопочки»), а единая цифровая среда, где все компоненты связаны через общий процесс:

• Процессный редактор - скелет и нервная система: маршрут, роли, сроки
• Конструктор форм - точки взаимодействия, адаптированные под контекст и роль
• Справочники и данные - единый источник правды для всех шагов
• Модуль интеграций - связь с реальным миром: 1C, CRM, склад, бухгалтерия, REST/SOAP API, вебхуки, готовые коннекторы и работа с базами данных через SQL
• Движок бизнес-правил - автоматические реакции на события: условия, формулы, проверки и действия, которые срабатывают при изменении данных

Каждый из этих блоков - не самостоятельный инструмент, а часть единого целого. Нажатие кнопки «Согласовать» в форме - это не просто смена статуса. Это запуск цепочки: проверить бизнес-правило, уведомить смежный отдел, обновить запись в CRM, поставить задачу следующему исполнителю. Всё это описывается один раз - в процессе.

Именно здесь low-code перестаёт быть метафорой и становится инструментом. В процессном редакторе BPMSoft аналитик работает как архитектор: рисует план здания - только вместо комнат там этапы процесса, вместо дверей - условия перехода, вместо несущих стен - бизнес-правила.

Принцип работы прост. Вы берёте элементы из палитры и перетаскиваете их на холст:

• Задача (Task) - шаг, который выполняет человек или система автоматически

• Событие (Event) - триггер: «пришла заявка», «истек срок», «получен ответ от API»

• Шлюз (Gateway) - развилка: «если сумма больше 100 тысяч - к директору, иначе - менеджеру»

• Подпроцесс - сложный этап, вынесенный в отдельную схему, чтобы основная оставалась читаемой

Каждый элемент настраивается через диалоговое окно без кода. Внутри элементы оперируют переменными процесса - данными, которые передаются между шагами и используются в условиях и действиях. Для задачи указываете исполнителя - конкретного человека, роль, группу или результат правила («назначить тому, у кого сейчас наименьшая загрузка»). Для шлюза - условие перехода. Для таймера - SLA и что делать при нарушении: уведомить, эскалировать, перевести на резервный маршрут.

Параллельное выполнение. «Отправить договор на проверку юристу и финансовому директору одновременно, и продолжить только после одобрения обоих». В редакторе это параллельный шлюз (AND-gateway): поток разветвляется и потом сходится. Ни строчки кода - только элемент на холсте. В процессе можно создать несколько веток выполнения и настроить так, что процесс будет ждать завершения выполнения всех веток перед походом дальше или наоборот - не ждать и выполнять каждую ветку отдельно.

Цикл с условием выхода - пока не выполнено правило (например, «утверждено»), задача возвращается на предыдущий шаг. «Возвращать задачу исполнителю на доработку, пока руководитель не примет результат». Циклическая связь на схеме плюс условие выхода. Этот паттерн покрывает добрую половину задач контроля качества в производстве, логистике и закупках.

Обработка исключений. «Если API 1C не ответил за 10 секунд - уведомить администратора и запустить резервный процесс ручного формирования документа». Обработчик граничного события на задаче - и у вас есть план Б, который сработает сам, когда что-то пойдёт не так.

Эскалация по SLA. «Если задача не выполнена за 2 рабочих дня - автоматически уведомить руководителя и добавить его как соисполнителя». Это не какая-то особенная магия - это таймерное событие, настроенное через пару кликов.

Из практики: один из наших клиентов, производственная компания, автоматизировал процесс согласования производственных заданий - 12 этапов, 4 отдела, параллельные ветки технического и коммерческого контроля. Аналитик собрал схему за 3 дня. Разработка «с нуля» заняла бы не меньше двух месяцев.

Конструктор форм - второй по важности инструмент в арсенале BPMSoft. И здесь тоже стереотип мешает: многие думают, что «форма» - это набор полей «введите имя», «введите телефон». Реальность устроена иначе.

Формы в BPMSoft - контекстно-зависимые интерфейсы. Они меняются в зависимости от того, кто открыл форму и на каком этапе процесса находится заявка. Юрист видит одни поля, финансовый директор - другие, а инициатор заявки - третьи. Это не отдельные формы, а одна - с правилами видимости.

Все поля формы привязаны к единой модели данных процесса. Это значит, что данные, введенные на одном этапе, автоматически доступны на всех последующих — без дублирования и ручной передачи.

Что умеет конструктор форм

1. Зависимость полей. Поле «Тип оборудования» появляется только если в «Категории заявки» выбрано «Ремонт». Поле «Реквизиты для оплаты» - только если выбрана форма расчета «Безналичный перевод». Никакого кода - визуальное правило в редакторе форм.
2. Расчётные поля. Стоимость позиции пересчитывается автоматически при изменении количества или цены. Итоговая сумма с учётом скидки - тоже. Формула пишется в поле настройки, синтаксис похож на Excel: понятно любому аналитику.
3. Валидация. Поле «ИНН» не даст сохранить запись, если введено не 10 и не 12 цифр. «Дата окончания» не может быть раньше «Даты начала» - система покажет ошибку прямо в форме, не дав пользователю двигаться дальше. Правило настраивается за минуту.
4. Таблицы и вложенность. В форму заявки на закупку можно добавить таблицу позиций, которую пользователь сам дополняет: товар, количество, единица измерения, цена. Это не хардкод - это настраиваемый компонент «вложенный список».

Дашборды: процесс как на ладони

Формы - это точка входа. Дашборды - это вид с высоты птичьего полёта на всё, что происходит в процессах прямо сейчас.

Руководитель открывает дашборд и видит: 47 заявок в работе, 8 просрочены, этап «Проверка юриста» занимает в среднем 3 дня - вдвое дольше норматива. Это не ощущения, это цифры. И принять решение на основе цифр - совсем другой разговор, чем на основе «кажется, что-то затянулось».

Для каждого отдела - своё рабочее место. Юрист видит документы на визировании. Менеджер по закупкам - график поставок. Директор - сводку по KPI. Всё настраивается визуально, без разработчика.

Самый частый аргумент против low-code: «У нас 15 критериев для назначения ответственного и формула расчёта скидки на три страницы. Это не опишешь без программиста».
Опишешь. Потому что BPMSoft не просит тебя писать код - он просит тебя ответить на вопросы. «Кому назначить задачу, если сумма больше 500 тысяч?» - выбираешь условие из списка, указываешь значение. «Как рассчитать итоговую стоимость?» - пишешь формулу, как в Excel. Всё. Именно так работают визуальные конструкторы правил: ты формализуешь то, что и так знаешь, - просто не в слова, а в поля и условия.

В бизнес правилах можно создавать условия оперируя значениями в поле/полях текущего или связанного объекта, константы, указываемые прямо внутри бизнес правила, отдельно настраиваемые в системе константы, а также системные переменные - то, что может динамически изменяться, например: "Контакт текущего пользователя" или "Значение текущей даты и времени".

Для настройки условий используются следующие типы элементов:

• Поле - колонка текущего или связанного объекта.
• Константа - значение, которое является постоянным. Значениями могут быть любой текст, в том числе с неограниченным количеством символов, целое или дробные числа, дата и/или время, справочник, логическая константа;
• Системная настройка - значение, которое является постоянным. Системные настройки также настраиваются с помощью Low-code.
• Системная переменная - значение системной переменной, которое динамически изменяется. Например: "Контакт текущего пользователя" или "Значение текущей даты и времени".

В бизнес правиле можно добавить несколько условий и использовать необходимый оператор «И» или «ИЛИ»

В BPMSoft доступны следующие действия, определяющие тип бизнес-правила:

• Показывать элемент на странице - действие, которое отображает или скрывает выбранный элемент в зависимости от настроенных условий бизнес-правила. Для выбора доступны элементы: поле, деталь, модуль, атрибут, группа полей, вкладка (то есть, все элементы настроенной карточки);

• Делать поле обязательным - действие, которое делает поле обязательным для заполнения при выполнении настроенных условий бизнес-правила.

• Делать поле редактируемым - действие, которое делает поле доступным для редактирования или блокирует его для изменений в зависимости от настроенных условий бизнес-правила.

• Добавлять фильтр значений в поле - действие фильтрует справочные значения доступные для выбора в поле.
  
  
• Заполнять значение поля - действие, которое копирует значение другого поля или заполняет рассчитанным значением с помощью формулы.

Вы можете добавить несколько действий в одном бизнес-правиле.

1. Правила маршрутизации. Если заявка из региона Восток и сумма превышает 500 тысяч рублей - направить региональному директору, иначе - менеджеру отдела. Настраивается через условие на шлюзе в редакторе правила. Две минуты работы.
   
   
2. Правила расчётов. «Итоговая стоимость = Количество × Цена × (1 − Скидка). Скидка = 5%, если клиент входит в список VIP». Формула в расчетном поле формы. Синтаксис - как в Excel, только вместо ячеек - названия полей процесса.
   
   
3. Правила валидации. Поле Email должно содержать символ @. Дата окончания не может быть раньше даты начала. Настраивается в свойствах поля. Система сама покажет ошибку пользователю - аналитик не пишет ни одного условного оператора.
   
   
4. Правила цветового выделения. Можно выделить цветом элемент на странице, чтобы пользователь обратил внимание. Например: выделить запись спецификации зеленым цветом, чтобы сотрудник понимал, что спецификация прошла согласование.

Ниже - честная картина того, что делает аналитик сам, а когда действительно нужен разработчик:

Вывод простой: 80% бизнес-правил в типовых процессах закупок, продаж, сервиса, логистики - аналитик описывает сам. Разработчик нужен для оставшихся 20%, которые в большинстве компаний встречаются раз в год.

«Хорошо, - говорят обычно на этом месте, - процесс в BPMSoft красивый и умный. Но наши данные живут в 1C, складской системе, CRM и почте. Придётся всё переписывать вручную?»

Нет. Современный low-code не живёт в вакууме. BPMSoft изначально проектировался как интеграционный хаб - система, которая соединяет всё, что уже есть в компании, и добавляет сверху слой управляемой бизнес-логики.

Как BPMSoft взаимодействует с внешним миром

Готовые коннекторы. Набор адаптеров к популярным системам: 1C, Microsoft Dynamics, Salesforce, Bitrix24, JIRA, почтовые серверы, мессенджеры. Хотите при поступлении новой заявки от клиента автоматически создавать сделку в Bitrix24? Выбираете коннектор, авторизуетесь, настраиваете маппинг полей. Код не нужен.

Универсальные HTTP-запросы (REST/SOAP API). Практически любая современная система имеет API. В BPMSoft есть визуальный конструктор: указываете URL, метод (GET, POST), заголовки и тело запроса. Ответ системы - партнёра автоматически разбирается и нужные поля записываются в процесс.

Вебхуки. Это «слушатели» - BPMSoft ждёт сигнала от внешней системы. Настроили вебхук - и ваша WMS или 1C могут мгновенно запускать нужный процесс при наступлении события: «документ проведен», «заказ отгружен», «статус изменён».
Прямое подключение к базам данных (JDBC/ODBC). Для чтения справочников или записи результатов напрямую в SQL-базу - без API, просто через подключение. Это удобно для работы со справочниками и массовыми данными без необходимости поднимать отдельный API.

BPMSoft берёт на себя всю рутину: сетевые запросы, авторизацию (OAuth, токены), форматы (JSON, XML). Вам остается только суть: что отправить и куда.

Граница возможностей честная: если внешняя система работает по закрытому бинарному протоколу или у неё нет никакого API - потребуется разработчик для написания кастомного коннектора. Но таких случаев - меньшинство. Подавляющее большинство корпоративных систем сегодня имеют REST или SOAP.

Теория понятна. Посмотрим на конкретные случаи из практики - не синтетические демо, а задачи, которые реально решались на BPMSoft.

Сценарий 1. Тендерный процесс: от сигнала до заявки

• Проблема. Компания участвует в десятках тендеров в месяц. Информация о новых тендерах появлялась в разных местах - мессенджерах, почте, специализированных сервисах. Ответственные не всегда были определены, дедлайны пропускались, а тендерная документация собиралась вручную по кусочкам из разных отделов.
• Решение. BPMSoft стал центральным диспетчером. При появлении нового тендера (событие из внешней системы через API) процесс автоматически назначал задачи коммерческому, финансовому и юридическому отделам с конкретными дедлайнами. Каждый видел свою часть работы в своём рабочем месте. Контекст передавался автоматически: реквизиты, номенклатура, история переписки - всё в одном месте.
• Результат. Время на подготовку тендерной заявки сократилось примерно на треть. Главное - ни один дедлайн больше не пропускался: платформа сама эскалировала задачу руководителю, если исполнитель не успевал.

Сценарий 2. Комплексное коммерческое предложение с логистикой

• Проблема. Подготовка крупного КП требовала участия нескольких отделов. Данные собирались вручную по почте и мессенджерам, цены могли быть неактуальными, а стоимость доставки рассчитывалась постфактум - уже после того, как клиенту озвучили цифру.
• Решение. Процесс в BPMSoft параллельно запрашивал данные у всех задействованных отделов через адаптированные формы. Интеграция с системой ценообразования обеспечивала актуальные скидки. Логистический расчёт стал отдельным этапом в процессе: на основе адреса клиента система через API картографического сервиса автоматически рассчитывала параметры доставки и добавляла их в итоговое КП.
• Результат. КП формировалось за одну итерацию, включало актуальные цены и стоимость доставки «в одном окне». Менеджер тратил время на работу с клиентом, а не на координацию отделов.

Сценарий 3. Процесс согласования договоров

• Проблема. Классика жанра: договор ходил по почте, версии путались, кто согласовал - непонятно, кто ещё нет - тоже. Юрист ждал финансиста, финансист ждал коммерческого директора. Время согласования - 2–3 недели.
• Решение. В BPMSoft выстроили многоуровневый процесс с параллельными ветками. Юридическая и финансовая проверки шли одновременно. При превышении суммы выше порога автоматически добавлялся этап согласования у генерального директора. Подписанный договор автоматически уходил в архив и создавал счёт в 1C.
• Результат. Среднее время согласования - 3 рабочих дня. Все версии, комментарии и история - в одном месте. Никаких «я не видел этого письма».

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

• Видеть, что происходит прямо сейчас

Дашборд показывает: на каком этапе сейчас больше всего задач, кто из исполнителей перегружен, сколько процессов нарушило SLA и почему. Это не отчёт «по итогам квартала» - это живая картина. Руководитель видит узкое место сегодня утром и к обеду уже принял решение: перераспределить нагрузку, добавить соисполнителя, изменить правило маршрутизации.

• Управление версиями: менять процесс без остановки

Бизнес меняется. Регламент обновился, добавился новый этап согласования, сменился ответственный отдел. В BPMSoft это не катастрофа и не заявка в IT на два месяца вперёд.

Аналитик открывает редактор, создает новую версию процесса, вносит изменения, тестирует на тестовых данных и публикует. Новые экземпляры процесса запускаются уже по обновленным правилам. Старые - продолжают идти по своей версии, ничего не ломается. Это занимает часы, не недели.

• Оптимизировать на данных, а не на ощущениях

Раньше, чтобы понять, почему согласование затягивается, нужно было проводить опросы и строить догадки. Теперь - открыть аналитику.

1.  «Этап "Проверка юриста" занимает в среднем 3,4 дня - вдвое больше норматива. Добавляем параллельного исполнителя»
2. «80% заявок идут по маршруту A. Делаем для них отдельный упрощённый процесс»
3. «Интеграция с системой Y даёт сбои каждую пятницу после 18:00. Разбираемся с коннектором»

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

Подведем честный итог без маркетинговых обещаний. Вот что меняется, когда low-code используется не для рисования карточек, а для автоматизации реальных процессов:

Скорость внедрения

Не месяцы на ТЗ, разработку и отладку, а недели на описание логики и сборку. Аналитик видит результат своей работы сразу - и может его тут же скорректировать. Это особенно важно, когда требования меняются в процессе: в классической разработке каждое изменение - это новый цикл. Здесь - просто обновить схему.

Независимость от IT-очереди

Рынок изменился, регламент обновился, добавился новый тип заявки. Аналитик сам вносит изменения в процесс, и через несколько часов он уже работает по-новому. Это не значит, что IT не нужен - значит, что его ресурс идёт туда, где он действительно нужен: на сложные архитектурные задачи, а не на бесконечные правки форм согласования.

Единая логика вместо «зоопарка» инструментов

Все процессы - на одной платформе, используют общие справочники, работают по единым правилам. Исчезают «коридоры нестыковок», когда продажи говорят одно, склад - другое, а логистика вообще в Excel. Есть один источник правды - и все его видят.

Прозрачность на всех уровнях

Исполнитель видит свои задачи с четкими дедлайнами. Руководитель видит загрузку команды и статусы процессов. Топ-менеджер - KPI по всем направлениям на одном дашборде. Управление перестаёт быть интуитивным и становится основанным на данных.

Low-code - это не про то, чтобы сделать дешевле. И не про то, чтобы обойтись без разработчиков вообще. Это про то, чтобы дать бизнесу прямой и управляемый доступ к собственной автоматизации: без посредников в виде IT-очереди на полгода вперед, без зависимости от знания конкретного фреймворка, без ситуации «хотели одно, получили другое, правим уже третий месяц».

BPMSoft - это пример того, каким low-code бывает, когда его проектируют не для демонстраций, а для реальной работы. Когда за красивым интерфейсом стоит серьезный процессный движок, нормальные инструменты интеграции и возможность описать 80% бизнес-правил без программиста.

Перестаньте смотреть на low-code-платформы как на конструктор для карточек. Начните видеть в них то, чем они стали: технологическую среду, где бизнес-эксперты описывают, как работает компания, - и это описание само начинает работать.

Если хотите посмотреть, как это выглядит на ваших конкретных процессах - запросите демо. Не презентацию с красивыми слайдами, а живую сессию с вашим реальным кейсом.