Как устроена автоматизация стипендий и других выплат студентам

Со стороны может показаться, что автоматизация стипендий — это довольно простой сценарий: проверить условия, назначить выплату и сформировать приказ. На практике не всё так просто.

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

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

Именно такой подход реализован в сервисе «ЮНИВУЗ-3. Назначение на стипендии и другие формы материальной поддержки». На его примере разберём, какие этапы процесса можно автоматизировать и где проходит граница между настройками системы и программной логикой.

Как отмечает Владислав Агапов, ведущий аналитик ООО «ЮНИСИСТЕМС», даже при электронной подаче заявления часть работы может по-прежнему оставаться на сотрудниках:

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

Поэтому сквозная автоматизация должна охватывать весь процесс:

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

При этом сами сценарии различаются в зависимости от вида материальной поддержки.

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

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

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

Бизнес-правила вместо жёстких сценариев

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

Как поясняет Владислав Агапов, бизнес-правила в данном случае — это условия и ограничения, определяющие, кому, при каких обстоятельствах, в каком размере и на какой срок назначается стипендия или материальная помощь.

Часть таких правил вынесена в настройки системы. Университет может самостоятельно управлять ими, если пользователю предоставлены соответствующие права.

Через настройки можно изменять:

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

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

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

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

Если же меняется сама логика процесса — появляется новый критерий с нестандартным алгоритмом расчёта, ранее не предусмотренная проверка или новая последовательность действий, — потребуется оценка необходимости доработки системы.

«Изменение алгоритмов расчёта или добавление новых бизнес-правил, не предусмотренных системой, может потребовать доработки», — отмечает Владислав Агапов.

При этом в сервисе предусмотрен и отдельный сценарий формирования приказов через конструктор — без привязки к автоматическим правилам назначения.

Что под капотом

ЮНИВУЗ-3 построен на микросервисной архитектуре. Основные модули — «Стипендии», «Контингент», «Промежуточный контроль» и другие — работают как самостоятельные сервисы. Это позволяет университету поэтапно внедрять новые решения, независимо обновлять и развивать отдельные компоненты платформы.

Для обмена данными между сервисами используется RabbitMQ, а для интеграции с внешними системами и взаимодействия с пользовательскими интерфейсами — REST API. API Gateway обеспечивает единую точку входа, направляя запросы к нужным сервисам.

Технология микрофронтендов позволяет объединять в едином личном кабинете не только сервисы ЮНИВУЗ-3, но и собственные разработки университета или решения сторонних поставщиков, даже если они созданы на разных технологиях.

В основе платформы — .NET, Angular, PostgreSQL и Docker. Такая архитектура позволяет развивать единую цифровую среду университета, сохраняя существующие системы и размещая все компоненты в собственной инфраструктуре, в том числе в закрытом контуре.

Что показал реальный проект

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

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

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