Универсальный документ – кастомный механизм согласования в Directum RX

1000+

Количество пользователей, охваченных автоматизацией по проекту

Следующий проект

Предпосылки

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

Объем таких документов индивидуален и напрямую зависит от внутренних бизнес-процессов. Одни типы документов могут быть разовыми, другие — возникать с определенной периодичностью. Часто для них не критичны метаданные, а важен лишь сам факт согласования и подписания для продолжения или завершения бизнес-процесса. Преимущество Directum RX в том, что система позволяет оцифровать даже такие нестандартные кейсы — например, за счет механизмов свободного согласования.

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

Поскольку объем документооборота различен, каждая организация самостоятельно определяет порог целесообразности: стоит ли выделять документ в отдельный вид (с настройкой форм, журналов, регламентов/процессов и т.д.) или оставить его в рамках общих процессов. Это решение зависит не только от затрат на разработку и поддержку, но и от удобства использования системы конечным пользователем.

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

Чем крупнее организация и сложнее её бизнес-процессы, тем выше объем документов, неохваченных «коробочными» решениями Directum RX. Что делать, если оставлять их на бумаге не хочется? Нередко суммарный объем таких документов превышает автоматизированную часть, а значит, это направление становится приоритетным для оптимизации.

Задачи и цели

За два года эксплуатации Directum RX (и предшествующего опыта работы в Directum 5) собрана обратная связь от пользователей и владельцев бизнес-процессов. Главный запрос — создание единого простого механизма для согласования и подписания документов по произвольным маршрутам.

Ключевые требования к инструменту:

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

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

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

Описание и возможности решения

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

Сроки и трудозатраты:

  • Период разработки: декабрь 2025 года.
  • Запуск в ОПЭ: январь 2026 года.
  • Суммарные трудозатраты: не более 40 чел./час.

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

Техническая реализация:
Ключевой задачей было максимальное использование возможностей no-code. Работа велась на версии Directum RX 25.1. В среде разработки были созданы:

  1. Документ (наследник OfficialDocument, см. Рисунок 1).
  2. Справочник маршрутов.
  3. Отчет. Создание отчета было обусловлено пожеланием фокус-группы внести корректировки в стандартный отчёт «Лист согласования», поэтому детально этот этап не рассматривается.

Рис. 1. Карточка Универсального документа

В карточке документа также доступны действия "Создать из файла" и "Создать по шаблону". На Рисунке 1 они отсутствуют, так как снимок экрана сделан для документа с уже загруженным файлом.

Доступны следующие свойства: (развернуть подробнее)
  • Имя (тип: Текст). Обязательное. По умолчанию формируется из имени файла, доступно для редактирования.
  • Подписант (тип: Ссылка на Sungero.Company.Employee). Обязательное, если список согласующих пуст. В остальных случаях может оставаться незаполненным.
  • Срок подписания (дней) (тип: Целое). Обязательное, если выбран «Подписант». По умолчанию — 2 дня. Определяет количество рабочих дней на исполнение задания.
  • Разрешить делегирование подписанту (тип: Логическое). Обязательное, если выбран «Подписант». По умолчанию — «Истина». Управляет возможностью делегирования задания.
  • Категория документа (тип: Перечисление). Обязательное. Связано с внутренними регламентами категорирования информации; ограничивает права доступа к документу.
  • Рубрика и подрубрика. Стандартные свойства OfficialDocument. Необязательны для заполнения.
  • Конвертировать в PDF (тип: Логическое). Обязательное. По умолчанию — «Истина». Регулирует автоматическую конвертацию документа при завершении процесса.
  • Рег. №, Дата документа, Состояние регистрации. Стандартные свойства OfficialDocument. Заполняются автоматически при регистрации.
  • Журнал регистрации. Стандартное свойство OfficialDocument. По умолчанию подставляется журнал, созданный специально для универсального документа. Возможность выбора сохранена для гибкости настроек в будущем.
  • Этапы согласования (коллекция свойств этапов):
    • Номер этапа (тип: Целое). Обязательное. Заполняется автоматически и определяет порядковый номер этапа.
    • Тип этапа (тип: Перечисление). Обязательное. Значения: «Последовательный», «Параллельный», «Конкурентный». По умолчанию — «Параллельный».
    • Имя этапа (тип: Текст). Необязательное. Используется для идентификации и отображения названия этапа в системе.
    • Уменьшающийся круг согласования? (тип: Логическое). Обязательное. По умолчанию — «Ложь». Определяет состав участников при возврате на доработку. Всегда принимает значение «Ложь», если свойство «Пересогласовывать с начала?» имеет значение «Истина».
    • Пересогласовывать с начала? (тип: Логическое). Обязательное. По умолчанию — «Ложь». Регулирует необходимость полного повторного цикла согласования после доработки.
    • Срок согласования (дней) (тип: Целое). Обязательное. По умолчанию — 2 дня. Определяет количество рабочих дней на исполнение задания.
    • Разрешить делегирование? (тип: Логическое). Обязательное. По умолчанию — «Истина». Управляет возможностью согласующего делегировать выполнение задания.
  • Согласующие (коллекция участников согласования):
    • Этап (тип: Целое). Обязательное. Заполняется автоматически; соответствует порядковому номеру из коллекции «Этапы согласования».
    • Согласующий (тип: Ссылка на Sungero.Company.Employee). Обязательное.
    • Тип этапа (тип: Перечисление). Обязательное. Связано с соответствующим полем элемента коллекции «Этапы согласования».
    • Имя этапа (тип: Текст). Необязательное. Связано с соответствующим полем элемента коллекции «Этапы согласования».
    • Очередь (тип: Целое). Обязательное для типа «Последовательный». Определяет очерёдность при последовательном согласовании; заполняется автоматически в порядке добавления записей.

 

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

  • Добавить этап — открывает диалоговое окно создания этапа (см. Рисунок 2). Пользователь может скорректировать параметры по умолчанию и, при необходимости, указать «Имя этапа».
  • Добавить согласующего в этап — вызывает диалоговое окно (см. Рисунок 2), в котором пользователю необходимо выбрать номер этапа и сотрудника.
  • Вверх / Вниз — действия активны только для этапов с типом «Последовательный». Используются для изменения очередности согласующих внутри этапа.

Использование отдельных диалоговых окон для добавления записей реализовано на основе пожеланий фокус-группы. При этом удаление и редактирование данных (в пределах допустимой логики) осуществляется с помощью стандартных функций управления строками коллекций.

Рис. 2. Диалоги добавления этапов и согласующих

Реализована возможность сохранения, загрузки и очистки маршрутов с помощью соответствующих кнопок на панели инструментов (см. Рисунок 3).

Рис. 3. Действия с маршрутами

Действие «Заполнить из списка маршрутов» позволяет загрузить ранее сохраненный маршрут, выбрав его из перечня доступных (см. Рисунок 4).

Рис. 4. Список маршрутов

Действие «Сохранить маршрут» позволяет сохранить текущую схему согласования в справочник. При нажатии открывается карточка нового маршрута, в которую автоматически переносятся все параметры из документа (см. Рисунок 5). Пользователю остается лишь указать имя маршрута и, при необходимости, настроить права доступа к нему для других сотрудников. Настройка прав выполняется стандартными средствами Directum RX (кнопка доступа в виде замка в правом верхнем углу карточки).

Рис. 5. Карточка маршрута

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

После заполнения всех параметров документ отправляется в работу с помощью действия «На согласование» (см. Рисунок 1). На Рисунке 6 представлен один из двух вариантов процесса, по которому может быть направлен документ.

Необходимость разделения на два отдельных процесса стала первой сложностью при разработке. Это обусловлено ограничениями системы при работе со стандартным блоком «Подписание». Данная техническая особенность была устранена разработчиками платформы в версии 25.3. Более подробно о данном ограничении можно найти информацию на club.directum.ru (Не обязательный подписант? Возможно ли? | Вопрос).

Рис. 6. Процесс с подписантом.

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

  • Блоки №7 и №9 («Получить количество этапов» и «Получить свойства этапа»):

Вторая техническая сложность проекта. С помощью стандартных инструментов no-code не удалось реализовать подсчет количества элементов коллекции и последующий перебор элементов коллекции, а также обращение к свойствам конкретного элемента (Параметры процесса и коллекции | Вопрос | Сообщество Directum).

  • Блок №21 («Присвоение номера»):

Блок был разработан ранее для других задач. Поскольку он полностью закрывал текущую потребность, поиск альтернативных no-code решений не проводился. Анализ возможности переноса этого блока в no-code зафиксирован в бэклоге на развитие.

  • Блок №57 («Проставление отметки ЭП»):

Изначально рассматривался стандартный блок «Преобразование в PDF», однако его использование потребовало бы дополнительной low-code разработки для кастомизации штампов (Справка Directum RX 25.3 - Как изменить отметку об ЭП). Чтобы ускорить процесс, был применен готовый блок, ранее разработанный подрядной организацией.

Блок «Доработка»/«Расширенное задание».

Особого внимания заслуживает блок №56 («Доработка»). Несмотря на название, технически это стандартный блок «Расширенное задание».

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

При комбинированном маршруте (например, параллельное согласование, затем последовательное) блок «Доработка» вел себя не так, как от него ожидалось. Если на первом этапе документ отправляли на доработку, то после завершения всех последующих этапов система повторно направляла документ тем же согласующим с первого этапа, хотя они уже подтвердили изменения в рамках своего цикла.

Замена на блок «Расширенное задание» полностью устранила эту ошибку. Данный кейс зафиксирован в бэклоге для детального изучения. Позже в официальной документации (Справка Directum RX 25.3 - Как настроить согласование с уменьшающимся кругом) был найден пример реализации подобной логики, где использовался блок «Расширенное задание», а не более логичный из название «Доработка». Совпадение?

Результаты

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

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

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

Потенциал использования

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

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

 

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

Фомин Юрий – начальник отдела информационных систем АО «Востсибнефтегаз». Решение разрабатывалось, тестировалось и обеспечивалось методологически (подготовка инструкций) силами одного сотрудника.

Работаю в периметре ПАО НК «Роснефть» с 2008 года, в АО «Востсибнефтегаз» с 2017.

 

Пока комментариев нет.

Авторизуйтесь, чтобы написать комментарий

У вас похожая задача?

Обсудите реализацию с экспертом Directum

Обязательное поле
Обязательное поле
Обязательное поле
Обязательное поле
Обязательное поле
Обязательное поле

Благодарим за интерес! Мы свяжемся с вами.

Directum Awards 2026
Какой проект лучше?
Авторизуйтесь, чтобы оценить материал.
Авторизуйтесь, чтобы оценить материал.
Directum Awards 2026
Спасибо за активность!
Ваш голос принят