Привет! Кажется, что не так давно мы впервые рассказывали о нашей работе с платформой BPMSoft в департаменте корпоративных систем ЛАНИТ, где я выполняю задачи аналитика. Но год прошел, календарь перевернут и пришло время добавить новые главы к описанию нашего взаимодействия с этой low-code системой.
В этой статье мне хотелось бы поделиться не только внутренним опытом по настройке и внедрению решения на платформе, но и обратной связью от тех, кто использует систему каждый день.

Сервисные договоры: версия из коробки и кастомная версия
К моменту написании статьи актуальной для работы является версия платформы BPMSoft 1.9, но начинали знакомство с системой и делали свои пробные наработки мы еще на версии 1.5.
Одним из первых для нас был проект технической поддержки – работы с клиентскими обращениями (Service Desk). Стартовая версия с минимальным набором функций для сбора обратной связи от пользователей (MVP) была выполнена на версии 1.6 и очень (очень-очень) долго именно на ней и реализовывалась, тестировалась и использовалась.
В той далекой 1.6 возможности готовых разделов из коробки по настройке работы с сервисными договорами были минимальными. А вот техническое задание заказчика наоборот включало целую главу о том, что, как и кем должно настраиваться для обеспечения сроков обработки обращений пользователей.
На сегодняшний день платформа включает в себя функциональность, которая позволяет контролировать качество, сроки обслуживания и фиксировать договоренности с клиентами (раздел «Сервисные договоры»).
В модуле «Управление сервисом» платформы доступна функциональность расчета плановых сроков реакции и разрешения по обращению и автоматической фиксации фактического времени. Возможно использовать уже настроенную логику или переопределить критерии и правила для вычисления сроков в соответствии с бизнес-задачами компании. Например, для расчета сроков можно использовать такие критерии, как приоритет обращения, тип предоставляемого сервиса или условия, указанные в сервисном договоре. В свою очередь каждый критерий – это справочник, легко доступный для администрирования из интерфейса платформы (рисунок 1).

В начале пути мы понимали, что под техническое задание заказчика придется настраивать кастомные разделы: запуски и остановки счетчиков времени предполагали сложные комбинации условий с различными операторами (И / ИЛИ). Когда не хватило возможностей настройки, было принято решение написать отдельный модуль, который в итоге представляет из себя комбинацию вычислений на C#, работу с базой данных и последующую интерпретацию на UI с помощью JS.
В нашем решении работа с соглашениями об уровне обслуживания с точки зрения администратора BPMSoft сводится к изменению настроек модуля «Конфигурация SLA» (здесь мы говорим о пользователе с правами администратора, с пониманием структуры разделов, особенностей настройки бизнес-правил и бизнес-процессов, который может вносить изменения, не влияющие на общую логику). После первичной настройки более чем 40 вариантов сервисных договоров (рисунок 2) по запросам на изменение либо корректируются существующие правила, либо создаются новые конфигурации.

Вносить изменения в настройки модуля может и служба сопровождения, поскольку при наличии технического описания кодов полей и базовой пошаговой инструкции платформа вполне дружелюбна и интуитивно понятна (рисунок 3). В нашем случае параллельно с эксплуатацией всегда велись разработки новой функциональности, поэтому аналитики управляли конфигурациями в модуле.

Также мы на своей шкуре проверили тиражирование кастомного раздела и его встраивание в другие (похожие, но все же имеющие принципиальные отличия) проекты. Разумеется, не обошлось без хорошего ревью, зато пакет с модулем получился универсальным и успешно прижился уже в четырех проектах.
Ретроспективная оговорка, или где мы забыли соломы подстелить
Помимо реализации основных бизнес-процессов, обеспечивающих работу решения «как запланировано», в реальности обычно приходится добавлять что-то, чтобы работало «хоть как-нибудь».
Первые сложности начались на этапе тестирования и переноса доработок между стендами (тест/препрод/прод): расчет времени прерывался или даты отличались от реального (целевого) значения. Так появились «обслуживающие» вспомогательные бизнес-процессы регенерации SLA: в зависимости от проблемы для конкретных объектов или для выборки расчет перезапускался и даты приводились в удобоваримый вид (рисунок 4). Основные кейсы использования – внесение изменений в сервисный договор в модуле «Конфигурация SLA» и пересчет с заданной даты, а также некоторые поставки обновлений в настройках разделов, бизнес-правил или бизнес-процессов, затрагивающих задействованные в модуле поля.

Если говорить о Service Desk в целом, то для работы с клиентскими обращениями соблюдение соглашений об обслуживании является ключевым, принципиальным фактором, влекущим за собой реальные материальные, репутационные и юридические последствия. Длительность регламентных работ, возможная сетевая недоступность, накладки в работе железа или любые другие нештатные ситуации – все это критически важно. Нам потребовалось довольно много времени для подбора оптимальных конфигураций для своего высоконагруженного решения.
Пара слов об обновлениях версии платформы (шучу, пара абзацев – не меньше)
Обновление версии ПО – процесс тривиальный, базово понятный и желанный: в новой версии мы ждем, что починят баги, выкатят новые возможности, если повезет, то и те, о которых просили лично мы. Но по ряду причин в нашем проекте обновление откладывалось, отменялось и в итоге случилось с гигантским разрывом 1.6-1.9.
Для всех, кто работал в проекте, переход с 1.6 на 1.9 не смог остаться незамеченным. Кто-то приветствовал новые модули Angular, кто-то обновленный UI-дизайн страниц и дизайнер системы. Да мы даже темной теме были рады. А дальше предстояло «причесать» свой кастом и перенести его на прод.
Когда я попросила коллег «вкруг» оценить время, потраченное ими на подготовку обновления и его реализацию, числа у всех очень разнились. Для одних необходимость перенастроить то, что не работало совсем или работало с ошибками, свелась к одному рабочему дню. Для других череда проб и ошибок «запустили – упало», «поправили – упало», «ушли просить совета – переписали – опять упало» вылилась в очень тяжелую рабочую неделю.
Главный урок, который мы извлекли для себя, – преемственность обеспечивает совместимость. Не следует пренебрегать возможностью обновить версию в момент ее выпуска вендором. Также следует закладывать в проект этапы, связанные с обновлениями и временем на адаптацию своего решения: чем больше у вас кастомных разделов, чем больше модулей и собственноручно написанных изменений, чем ответственней ваши обязательства по доступности, по отказоустойчивости, тем «жирнее» должны быть эти этапы (по длительности и по трудоемкости).
Вместо заключения
За прошедшее время мы неоднократно убеждались, что функциональность, недоступную в модулях платформы из коробки, вполне возможно реализовать, используя модуль для свободного проектирования бизнес-процессов, разделов, бизнес-логики («Конструктор»). Магазин приложений (дополнения, которые можно устанавливать бесплатно или приобретать у разработчиков) основательно пополнился как за счет разработок вендора, так и за счет представителей сообщества.
Импонирует, что разработчики платформы развивают свой продукт в ногу со временем, и она оценивается экспертами как одна из российских платформ с наибольшим уровнем функциональной готовности.
Если на первых порах инициатива реализации некоторых плюшек платформы в решении клиента исходила от нашей команды, и порою приходилось писать «мотивационное письмо», чтобы согласовать бюджет под первичную настройку или адаптацию решения, то сейчас заказчик уже сам приходит к нам с вопросом, можно ли реализовать ту или иную функцию в ближайшей перспективе.
Также есть гласные и негласные установки оптимизации процессов с использованием ИИ, а новая версия платформы позволяет нарастить функционал или перенести наш рукописный кастом в плоскость low-code настроек.
Сейчас по результатам успешного переезда на 1.9 в Service Desk наша команда готовится обновлять решения и на других проектах, реализованных на базе BPMSoft.