Периодические поручения в страховой компании

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

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

Анализ ситуации ("как было")

Общее число действующих шаблонов, которое было требовалось перенести в новую систему составило 407 шт.

По типам периода они распределялись так

• 5% – «Ежедневно»;
• 1% – «Еженедельно»;
• 36% – «Ежемесячно»;
• 53% – «Ежегодно»;
• 5% – «Произвольный».

Карточка справочника «Шаблоны поручений» в DIRECTUM 5 состояла из 4 вкладок со следующими блоками параметров (см. рис.1):

1. Вкладка «Расписание» – блок параметров определения периода (цикличности) запуска;
2. Вкладка «График» – была представлена табличной частью, позволяющей вручную задавать точки запуска (даты) для типа периода = «Произвольный».
3. Вкладка «Параметры» – блок определения параметров поручения.
4. Вкладка «Контроль» – в отличие от остальных вкладок, по сути, не несла никакого полезного функционала.

Рисунок 1. Вкладки «Расписание» и «Параметры» карточки справочника «Шаблоны поручений» в старой системе

Проблемы использования

На этапе анализа было выявлено, что Заказчика путает обилие параметров в блоке определения периода запуска на вкладке «Расписание», и одни и те же настройки им часто выполняются по-разному.

Например, необходимость формирования периодического поручения 1 раз в год 15 января на карточке шаблона он мог задать тремя разными способами (см. рис.2):

1. указав конкретное число и месяц для типа периода «Ежегодно»;
2. проставив отметку повторять каждые 365 дней для типа периода «Ежедневно», а параметр «Начало» предела повторения установив на 15 Января соответствующего года;
3. ручным заполнением всех соответствующих дат на ближайшие годы в табличной части на вкладке «График» для типа периода «Произвольный».

Рисунок 2. Пример разных способов указания Заказчиком одной и той же настройки в старой системе

Также случалось, что, не сумев определить, как правильно задать несколько точек запуска (дат) на карточке одного шаблона, сотрудник просто копированием создавал несколько однотипных записей по одному поручению. Например, чтобы обозначить необходимость формирования периодического поручения в начале и в середине каждого месяца он создавал сразу две записи с типом периода = «Ежемесячно» и указанием следующих параметров: повторять каждое 1 и 16 число месяца соответственно (см. рис.3).

Рисунок 3. Пример создания нескольких однотипных записей по одному поручению в старой системе

Кроме того, при настройке шаблонов периодических поручений сотрудники заказчика не использовали относительные параметры, например, повторять в 1-й (2-ой, посл. и т.д.) понедельник каждого месяца. Т.е. все настройки периодов запуска имели четкую привязку к дням недели и числам месяца.

Отдельно были проанализированы шаблоны с типом периода «Произвольный» и выяснилось, что точки запуска (даты), заданные в их табличных частях на вкладке «График» тоже не являются хаотичными и их можно повторить, используя оставшиеся 4 типа периода.

Выводы по итогам анализа

Таким образом, было сделано 2 ключевых вывода:

1. Если карточка справочника «Шаблоны поручений» в старой системе слишком сложная, путает Заказчика и несет в себе более обширный функционал, чем требуется, то в новой системе ее необходимо упрощать, максимально исключая «лишний» функционал и неиспользуемые параметры.
2. Если у заказчика отсутствует единый стандарт с описанием рекомендаций о том, как лучше задавать точки запуска (даты) в тех или иных случаях, то необходимо совместными усилиями выработать единый стандарт и рекомендации по настройке шаблонов периодических поручений на конкретных, понятных примерах.

Проектные решения ("как должно быть")

Итерационный подход к решению благодаря low-/no-code

Поскольку реализация данной задачи была ограничена не только временными рамками самого проекта, но и общим объемов часов модификаций, для ее решения ориентир был взят на максимальное соблюдение принципов Low-code и No-code. Версия системы Directum RX 4.7 позволяла это сделать.

Визуальная форма карточки справочника «Шаблоны периодического поручения» была полностью настроена с использованием представлений форм.

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

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

По просьбе пользователей также была скорректирована схема варианта процесса для типа задачи «Задача на исполнение поручения» (см. рис.5), по которой производится запуск периодических поручений:

• в блоке задания «Исполнение поручения» была скорректированная тема;
• исключены лишние уведомления исполнителю, а также сотруднику, выдавшему поручение.

Рисунок 4. Реализованная карточка справочника «Шаблоны периодических поручений» в новой системе

Рисунок 5. Конечная схема варианта процесса для типа задачи «Задача на исполнение поручения»

Функциональность модуля

Полученное в результате решение оформлено как отдельное, в новый модуль разработки, и состоит из 3 элементов:

1. Справочник «Шаблоны периодических поручений»;
2. ФП «Запуск периодических поручений»;
3. Асинхронное событие.

Справочник «Шаблоны периодических поручений»

Как уже упоминалось выше, форма карточки справочника «Шаблоны периодических поручений» содержит 2 блока параметров, объединенных на одной форме (см. рис.4):

• блок определения параметров поручения;
• блок определения периода запуска.

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

Из 5 типов периода второго блока параметров в новой системе осталось только 4: «Ежедневный», «Еженедельный», «Ежемесячный», «Ежегодный». И табличная часть данного блока видоизменяется, в зависимости от того, какое значение принимает параметр «Тип периода» (см. рис.6):

1. для типа периода = «Еженедельно» – в табличной части появляется и становится обязательной для заполнения колонка «День недели»;
2. для типа периода = «Ежемесячно» – в табличной части появляется и становится обязательной для заполнения колонка «Число месяца»;
3. для типа периода = «Ежегодно» – в табличной части появляются и становятся обязательными для заполнения колонки «Число месяца» и «Месяц».

Рисунок 6. Видоизменение табличной части, в зависимости от значения параметра «Тип периода»

Точки запуска (даты) вычисляются системой автоматически на основании параметров «Тип периода», «Переносить с выходного», а также значений колонок «День недели», «Число месяца», «Месяц» и хранятся в колонке «Ближайшая дата запуска» табличной части шаблона (см. рис.5).

Причем в рамках одного шаблона можно задать сразу несколько точек запуска (дат), например, указав необходимость формирования периодического поручения 2 раза в месяц: 1-го и 16-го числа. Если ближайшая дата запуска попадает на выходной день, а значение параметра «Переносить с выходного дня» = «Назад» или «Вперед», то система автоматически переносит ее на предыдущий, либо первый рабочий день после выходных, соответственно, согласно производственного календаря.

ФП «Запуск периодических поручений» и асинхронное событие

Ежедневно в 06:30 выполняется запуск фонового процесса «Запуск периодических поручений», который запускает асинхронное событие. Система проверяет каждую запись справочника «Шаблоны периодических поручений», находит записи, у которых Состояние = «Действующая» и проверяет значение колонки «Ближайшая дата запуска» табличной части шаблона на равенство Текущей дате.

Если равенство истинно, то:

• по данному шаблону автоматически формируется поручение и отправляется в работу по ранее настроенной схеме варианта процесса для типа задачи «Задача на исполнение поручения» (см. рис.5);
• после чего на основании параметров «Тип периода», «Переносить с выходного», а также значений колонок «День недели», «Число месяца», «Месяц» табличной части шаблона рассчитывается уже новая точка запуска (дата) и записывается в колонке «Ближайшая дата запуска» на месте соответствующего значения. Причем, если по каким-то причинам в колонке «Ближайшая дата запуска» табличной части одного шаблона окажется два одинаковых значения, то, в рамках работы ФП будет создано и отправлено в работу только одно поручение, однако значение поля «Ближайшая дата запуска» будет актуализировано для обоих значений.
• фиксирует в поле «Дата посл. созд. поруч.» Текущую дату.

Если равенство ложное, то ФП переходит к другому шаблону далее по списку.

Ключевые ограничения/особенности решения

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

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

Результаты

Главным показателем качественно реализованной доработки стал тот факт, что перенос шаблонов периодических поручений был произведен Заказчиком самостоятельно, не прибегая к дополнительным консультациям по работе решения. Всего за 2 дня, опираясь всего лишь на ранее разработанную инструкцию, Заказчик смог самостоятельно перенести из старой системы в новую все шаблоны! В service desk не было зафиксировано ни единого вопроса по данному функционалу, что означает достижение ключевой цели – решение оказалось простым, понятным для Заказчика и полностью закрывает его потребности.

Показатели эффективности

На сегодняшний день в системе Directum RX по шаблонам создано порядка 300 периодических поручений, а к концу года их число превысит 5 000!

В новой системе создавать шаблоны периодических поручений стало намного проще. По предварительным замерам в новой системе у Заказчика на 70% сократилось время на их настройку за счет:

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

Перспективы развития решения

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

Состав команды проекта

• Виктория Кока – Руководитель проекта
• Наталья Фокина – Администратор проекта
• Михаил Наумов – Куратор проекта
• Алмаз Гатауллин – Руководитель разработки
• Александр Архипов – Ведущий разработчик
• Анна Горбунова – Ведущий аналитик
• Татьяна Ганбарова – Ведущий аналитик
• Кирилл Неверов – Разработчик
• Юлия Измайлова – Разработчик

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

Виктория Кока – Руководитель проекта

Около 6 лет работаю в сфере ИТ и давно слежу за развитием ряда платформ. Продукт DirectumRX – в их числе.

Еще с версии 4.6 я отметила для себя концепцию «No-code настройка в сочетании с Low-code разработкой», которую сейчас активно транслирует вендор, и буквально влюбилась в нее! На своих проектах там, где есть такая возможность, я пропагандирую ее использование. Ведь концепция «Low-code» – это не только простота и удобство настройки, но и дальнейшая возможность Заказчику практически безболезненно обновляться на новые версии, а значит быстрее других получать актуальный функционал.