Масштабная оптимизация процессов согласования договорных документов судоходной компании с помощью инструментов no-code

Бизнес-контекст

Заказчик проекта — судоходная компания, оказывает услуги на реках и морях России, а также на международных морских направлениях.

Прежде ИТ-инфраструктура перевозчика была организована на базе устаревшей системы, которая объединяла все структуры холдинга.

Ранее компания приняла решение перейти на Directum RX, совместно с нашей командой внедрения выполнила этот проект. Текущий проект стал развитием цифровизации.

Предпосылки

На первом этапе нашей работы с компанией была внедрена версия RX 4.9, которая ещё не предоставляла широких возможностей оптимизации согласований с помощью технологии no-code. В связи с этим было принято решение о переводе процесса согласования договорных документов на регламенты согласования.

На протяжении полутора лет с момента внедрения Directum RX заказчик использовал регламенты согласования. Со временем появлялись новые процессы по согласованию, которые внедрял сам заказчик. Схемы корректировались, появлялись новые условия для вычисления исполнителей и прочее.

На момент второго этапа внедрения системы действующих записей регламентов согласования договоров насчитывалось уже 36 шт. Было создано около 700 блоков согласования только с обязательными согласующими. Кроме того в схеме могли быть блоки Согласование с руководителем, Подписание, Отправка контрагенту и т.д.

Сразу может возникнуть вопрос, откуда столько блоков согласования? Дело в том, что вычисление сотрудников происходит строго по конкретным условиям в схеме, при том, что в одном условии может быть дополнительное условие и не одно.

На примере можно продемонстрировать, как выглядит 1/7 часть самой объемной схемы согласования в системе.

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

1) соответствовала всем требованиям законодательства;

2) покрывала потребности организации в документообороте.

В связи с этим в середине 2025 года руководство компании приняло решение об обновлении Directum RX с версии 4.9 до версии 25.2. Не менее приоритетной задачей стал перевод согласования договорных документов с регламентов согласования на варианты процессов с помощью no-code, так как сопровождать схемы согласования со временем стало критично трудоемко.

Цели и задачи проекта

В рамках проекта были выделены следующие ключевые задачи:

1. Обновление системы с 4.9 до 25.2.

2. Исследование и анализ, на сколько эффективным будет переход из текущих процессов по регламентам согласования на варианты процессов.

3. Переход на варианты процессов с минимальным участием разработчика.

4. Другие задачи, связанные с обновлением версии.

Описание реализации

Анализ

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

Дополнительным позитивным фактом было то, что Заказчик своевременно вносил изменения в матрицу согласования параллельно с изменениями, вводившимися в схемах согласования.

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

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

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

Порядок действий для переноса регламентов в варианты процессов

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

Параллельно с созданием вычисляемых ролей я уже наглядно стал понимать, насколько сократятся масштабы схемы согласования. Все условия, которые были разработаны в регламентах согласования (в том числе базовые), можно было за несколько минут перенести вычисляемыми выражениями "из коробки". Ниже пример вычисляемой роли.

В среднем количество строк (то есть вариативность вычисления) в вычисляемых выражениях достигает 2-3 шт. Встречаются роли (называю их "сложными для понимания"), в которых вариативность доходит и до 7 шт.

Участие разработчика

Для разработчика же стояла задача - перенести все проверки, реализованные для регламентов согласования, а также несколько скриптов (сценариев) на варианты процесса.

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

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

Сложности и минусы

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

Если внимательно читать, то можно обратить внимание, что мы обновляли систему с 4.9 до 25.2. При этом в промежуточной версии 4.11 появилась новинка, с помощью которой добавилась возможность создавать Дополнительное соглашение к Дополнительному соглашению. Конечно, заказчик был рад увидеть эту новинку, но она критично повлияла на мою реализацию вычисляемых выражений, так как изначально мною планировалось, что для всех договоров будет одна схема. При этом вычисления критериев/условий по Дополнительному соглашению я планировал брать из атрибутов Договора (т.е. из карточки документа, на основании чего было создано Дополнительное соглашение).

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

Посоветовавшись с внутренней командой, а также с человеком, который знает no-code больше, чем мы все (огромный ему привет!), мы приняли решение добавить еще одно поле в карточку Дополнительного соглашения, в котором будет заполнен "самый первый" договор из иерархии. Этим мы решили проблему, когда в Доп. соглашении в поле "Договор" указано Доп. соглашение, т.к. теперь ориентируемся на то поле, в котором точно будет Договор (из карточки это поле мы скрыли, чтобы пользователя не смущало новое поле, а в исторических документах просто заполнили его "правильным" запросом).

Самая сложная работа при переходе

Больше всего времени ушло на то, чтобы создать вычисляемые роли с самого нуля, смотря на таблицу. Информации по таблице было очень много и важно было не запутаться.

Итоги

Мне удалось перенести всю информацию из таблицы в вычисляемые роли без особого труда. Было создано 48 вычисляемых ролей (отдельно для карточки Договора и отдельно для Доп. соглашений). Более того, 12 ролей, которые ранее невозможно было вычислить в регламентах согласования (сотрудники указывали их как доп. согласующие), удалось также перенести на вычисляемые роли, что также обеспечивает дополнительный позитивный эффект от проделанной работы, т.к. теперь пользователям, отправляющим договоры на согласование - не нужно задумываться, кого указывать в поле Дополнительные согласующие. 

Новый процесс позволяет удобнее отслеживать маршрутизацию пройденных этапов по кнопке "Показать схему". Можно настроить процесс на одном стенде, а после успешного тестирования легко перенести его экспортом/импортом на рабочую базу.

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

Можно с уверенностью заявить, что мы добились заметного успеха в оптимизации процессов по договорным документам. Количество схем согласования сократили с 36 всего до 2: один процесс для договоров, второй процесс для доп. соглашений. Если переводить в наглядные проценты, то удалось избавиться от 94% схем согласования.

На примере можем наблюдать, как сильно изменилась схема до момента с согласованием с обязательными согласующими:

Об авторе заявки

Григорьев Артур Игоревич - сертифицированный консультант по внедрению Directum RX.

На должность консультанта по внедрению я пришел в августе 2022 года после получения диплома.

Со слов моих коллег тогда — 3,5 года назад — их заинтересовало во мне то, что я очень много разговаривал, поэтому при каждом удобном случае мне до сих пор напоминают, что меня взяли в команду только потому, что я был чрезвычайно болтлив во время собеседования :) С этими опытными коллегами сейчас я работаю в одной команде внедрения.

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

Далее я прошел обучение по курсу RX-23, RX-22 (очень советую, если Вы действительно хотите погрузиться в no-code) и смотрел обучающие видеоролики представителя Вендора - Виталия Томко (в одном из разделов я его "скрытно" упоминаю :) ). В целом, все полученные знания действительно помогли мне быстро освоиться и качественно погрузиться в мою задачу на проекте.