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

Кирпичёва Е. Ю., Махалкина Т. О., Русакова Е. А. Автоматизация приемной кампании вуза в условиях многозадачного подхода // Системный анализ в науке и образовании: сетевое научное издание. 2023. № 3. С. 26-37. EDN: REQFYU. URL :

Статья находится в открытом доступе и распространяется в соответствии с лицензией Creative Commons «Attribution» («Атрибуция») 4.0 Всемирная (CC BY 4.0)

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

Процесс проведения приемных кампаний в учебных заведениях является значимым и определяющим в оценке эффективности общей деятельности заведения. Данный процесс регламентируется как внешними, так и внутренними документами, в нем принимают участие не только сотрудники приемных комиссий, но и сами абитуриенты и их представители, а также рабочие группы подразделений вуза. Как правило в ходе данного процесса обрабатывается большой объем информации, поэтому эффективность самой приемной кампании зависит не только от качества ее организации, но и от уровня (глубины) внедрения информационных технологий [1].

• 1.    Проблемы автоматизации приемной кампании в вузе

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

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

В университете «Дубна» вопросами организации и реализации приемной кампании по направлениям бакалавриата, специалитета и магистратуры занимается Абитуриент-центр. В рамках приемной кампании разрабатываются следующие нормативные документы:

• -    Правила приема на обучение.

• -    Сроки проведения приема.

• - Программы вступительных испытаний.

• -  Документы для дистанционной подачи заявления.

• -    Информация о наличии общежитий.

• -    Информация о предоставляемых поступающим особых правах и преимущества.

• -    Информация о количество мест (контрольные цифры приема или КЦП).

• -    Регламент учета индивидуальных достижений поступающих и др.

Несмотря на то, что каждый вуз разрабатывает свою стратегию приемной кампании, начиная от рекламы и заканчивая консультациями абитуриентов, образовательные организации высшей школы обязаны выполнять ряд нормативных актов Министерства Образования Российской Федерации, причем от вузов требуется цифровизация приемной кампании и активное использование всероссийского суперсервиса [2].

Особенно отметим:

• 1.    Приказ Министерства науки и высшего образования Российской Федерации от 26.08.2022 № 814 «О внесении изменений в Порядок приема на обучение по образовательным программам высшего образования – программам бакалавриата, программам специалитета, программам магистратуры, утвержденный приказом Министерства науки и высшего образования Российской Федерации от 21 августа 2020 г. № 1076» (зарегистрирован 26.09.2022 № 70211) [3].

• 2.    Постановление Правительства Российской Федерации от 26.01.2023 № 89 «О функционировании суперсервиса «Поступление в вуз онлайн» в рамках приемной кампании 2023/24 учебного года» [4].

В связи с этим вся дальнейшая автоматизация приемной кампании должна опираться на особенности представления данных в указанных выше сервисах, учитывать структуры данных, а также исполнять закон о персональных данных абитуриентов. На рис. 1 представлена взаимосвязь сервисов при проведении приемной кампании в университете «Дубна» в общем виде (базовые требования к обеспечению приемной кампании).

Рис. 1. Взаимосвязь сервисов, задействованных при проведении приемной кампании

Разнообразие независимых цифровых платформ, задействованных в приемной кампании вуза, требует разработки собственных решений, пусть и представляющих порой «лоскутную» автоматизацию. Поскольку помимо единой цифровой платформы 1С Университет, вуз интегрируется также с суперсервисом, данные из которого обязаны быть преобразованы и добавлены в базу данных 1С, причем вуз для суперсервиса является одним из видом «пользователей», и вносить изменения в работу алгоритмов не может. Все возникающие ошибки фиксируются и передаются в службу технической поддержки суперсервиса. Таким образом, единая цифровая платформа 1С зависит от суперсервиса. На рис. 2 представлена более подробная взаимосвязь сервисов при проведении приемной кампании в университете «Дубна», актуальная для приемной кампании 2023 года.

Рис. 2. Организация использования ИТ-сервисов при проведении приемной кампании в университете «Дубна»

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

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

• -  15.03.04 Автоматизация технологических процессов и производств (очная форма),

• -  38.03.05 Бизнес-информатика (очная, очно-заочная форма),

• -  09.03.01 Информатика и вычислительная техника (очная, заочная форма),

• -  09.03.02 Информационные системы и технологии (очная форма),

• -  09.03.03 Прикладная информатика (очная, заочная форма),

• -  01.03.02 Прикладная математика и информатика (очная форма),

• -  09.03.04 Программная инженерия (очная, заочная форма),

• -  27.03.03 Системный анализ и управление (очная форма),

• -  02.03.02 Фундаментальная информатика и информационные технологии (очная форма),

• -  38.03.01 Экономика (очная, очно-заочная форма).

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

К атрибутам БД абитуриентов относятся:

• 1.    комментарий;

• 2.    приоритетное направление;

• 3.    приоритетность вуза;

• 4.    дата консультации;

• 5.    регистрационный номер;

• 6.    ФИО поступающего;

• 7.    СНИЛС;

• 8.    вид образования;

• 9.    целевик (целевое обучение);

• 10.    олимпиадник (без вступительных испытаний);

• 11.    особые права;

• 12.    сумма баллов;

• 13.    выбранные направления (20 столбцов, 10 приоритетов на очную форму обучения и 10 столбцом на очно-заочную и заочную форму обучения);

• 14.    направление, на которое подан оригинал аттестата или согласие на зачисление;

• 15.    сумма баллов за индивидуальные достижения;

• 16.    баллы ЕГЭ/ВИ;

• 17.    основание поступления;

• 18.    форма обучения;

• 19.    телефон;

• 20.    e-mail;

• 21.    адрес по прописке;

• 22.    нуждаемость в общежитии;

• 23.    год завершения обучения;

• 24.    способ подачи документов;

• 25.    согласие с госуслуг.

Данные для атрибутов № 5-25 могут быть получены на основе отчетности из 1С, данные для атрибутов № 1-4 являются дополнительными, формируются и вносятся сотрудниками ИСАУ. Эти данные не попадают в систему 1С и являются информацией внутреннего пользования института.

Общий вид БД абитуриентов можно представить следующим образом:

Рис. 3. База данных абитуриентов (общий вид)

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

• -    анализировать количество абитуриентов, подавших заявления на определенные направления;

• -    формировать конкурсные списки по направлениям;

• -    формировать расширенные конкурсные списки, с учетом приоритетности указанных абитуриентов направлений;

• -    анализировать конкурс на направления (относительный по заявлениям и абсолютный по согласиям на зачисление);

• -    выявлять абитуриентов, которые указали не все подходящие к их конкурсной группе направления и др.

Таким образом, при проведении приемной кампании вуза необходим комплексный подход, реализующий:

• -    бесперебойную работу сайта вуза и электронного способа приема документов;

• -    бесперебойную работу системы 1С Университет.ПРОФ как единой цифровой платформы для сбора и хранения данных об абитуриентах;

• -    эффективную работу всех членов приемной комиссии;

• -    формирование единой сводной отчетности (ежедневно) по поданным заявлениям о поступлении с выгрузкой необходимой и достаточной информации об абитуриентах для дальнейшего предоставления их на факультеты/институты;

• -    дополнение/преобразование полученного из 1С отчета, исходя из задач конкретного факуль-тета/института.

• 2.    Требования к конструктору

В рамках выявленных задач было принято решение о разработке локального Конструктора, который будет работать с данными из стандартного отчета 1С и преобразовывать его к виду, пригодному для построения базы данных абитуриентов, требуемой структурному подразделению (в нашем случае, ИСАУ) для принятия решений в интересах приемной кампании.

Цель разработки Конструктора заключается в конвертации и компоновки данных отчета из 1С таким образом, чтобы избежать больших временных затрат на сравнение выгрузок разных дней, на выявление и копирование данных по абитуриентам и т.п. Прежде чем разрабатывать Конструктор, нужно выявить конкретные требования. Начнем с анализа структуры данных отчета 1С, с которым предстоит работать, т.к. он является для конструктора исходными данными. Ожидается, что в результате разработки Конструктор будет представлять из себя полуавтоматическое (автоматизированное) цифровое решение (сервис). Планируемые временные затраты на использование Конструктора составляют от 5 до 20 минут ежедневно, а количество действий, совершаемых сотрудником, не превысит 10 логических операций. Это будет нашими главными критериями при оценке полученного результата.

Форма отчета из системы 1С формируется согласно следующей структуре (см. табл. 1).

Табл. 1. Структура отчета

Рег. номер

Физическое лицо

Атрибут 1

Атрибут 1

Атрибут N

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

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

Также возникает проблема с частичной автоматизацией такого отчета средствами обычной таблицы. Даже сортировка по ФИО или многоуровневая сортировка по атрибутам не даст ровного представления информации.

Функциональная возможность MS Excel «Сводные таблицы» может решить проблему одноразово, т.к. сводные таблицы статичны, при добавлении данных в основную таблицу их необходимо заново перестраивать. Таким образом, с отчетом, представленном в виде таблицы MS Excel , невозможно работать в динамике, невозможно осуществлять какой-то контроль версий или быстрое автоматическое сравнение и выявление изменений.

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

Нужен промежуточный сервис (Конструктор), который сможет скомпоновать данные нужным образом.

БД абитуриентов, для которой требуется преобразовать отчет из 1С, достаточно громоздкая, но вполне удовлетворяющего масштаба для стандартных табличных редакторов. С учетом форматов, с которыми работает 1С, ведение данной таблицы подразумевает использование табличных офисных пакетов, таких как: MS Excel , Open Office , My Office , Google Sheets и «Документы» от Yandex .

Opensource -решения предполагают риски размещения данных в сети Интернет. Необходимо соблюдать настройки доступа только из-под корпоративного университетского домена в защищенной подсети без возможности выхода в глобальную сеть. В этом случае можно допускать использование Google Sheets или «Документы» от Yandex .

Система 1С, на основе которой факультеты и институты строят свои отчеты, в полной мере обеспечивает безопасность данных при соблюдении условий и настроек безопасности как на уровне операционной системы, серверного оборудования вуза, так и на уровне самой СУБД. Однако использование для построения отчетов только 1С не подходит ввиду того, что доступ к изменению данных в 1С ограничен [5].

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

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

Для конструктора выделим две роли: администратор (создатель) и оператор. Все функции, относящиеся к получению и преобразованию данных, будут доступны оператору. Сам же файл Конструктора, все формулы/скрипты, его структура создаются один раз администратором. Любые изменения в структуру Конструктора или в формулы/скрипты могут вноситься администратором или оператором с одобрения администратора. Т.к. у обеих групп пользователей остаются права на редактирование таблиц, оператору следует четко следовать разработанной для Конструктора инструкции.

Сформулируем функциональные требования к Конструктору. Конструктор должен обеспечивать:

• -    интеграцию данных из 1С;

• -    сортировку данных;

• -    поиск дублирующих записей по заданному атрибуту;

• -    интеграцию записей по всем атрибутам абитуриента в одну уникальную запись таблицы с последующей разбивкой по столбцам данные из нескольких строк;

• -    удаление записей или изменение перечня отображаемых записей;

• -    фильтрацию данных по выбранному атрибуту.

Варианты использования Конструктора оператором (сотрудником кафедры) представлены на рис. 4.

1С (база данных)

Сетевая папка (файлы отчетов)

новые данные (заявления абитуриентов)

стандартный отчет 1С

База данных абитуриентов

стандартный отчет 1С

Преобразование и компоновка данных;

ошибка данных ^.форматы или форматирование)

Скомпонованные данные ^.1 (структура для БДА)

Рис. 4. Возможности оператора в Конструкторе (пользовательские требования)

Сотрудник приемной комиссии

Таким образом, можно выделить три сущности:

• -    Отчет из 1С (статичная таблица, каждый раз это новая таблица, т.е. новый excel -файл).

• -    Конструктор (набор динамических связанных между собой таблиц с формулами/макросами).

• -    БД абитуриентов (динамически обновляемая таблица со строгой последовательностью атрибутов).

• 3.    Автоматизация процесса переноса, сортировки и компоновки данных абитуриентов

Общая схема работы в период приемной кампании факультета/института с применением Конструктора представлена на рис. 5.

Рис. 5. Общая схема работы в период приемной кампании факультета/института с применением Конструктора

Данная схема была реализована в рамках приемной кампании ИСАУ в 2023 году.

Представим алгоритм работы с Конструктором в виде простой последовательной диаграммы (на основе выявленных ранее требований) (рис. 6):

Рис. 6. Последовательность работы Конструктора

Конструктор - это excel -файл, состоящий из нескольких листов, на каждом из которых формализованы правила работы с данными:

• -    TDSheet - это основная таблица с данными выгрузки из 1С;

• -    TDSheetO - часть данных с листа TDSheet , относящихся к очной форме обучения;

• -    TDSheetZ - часть данных с листа TDSheet , относящихся к заочной и очно-заочной форме обучения

• -    TDSheetO_Check – лист для промежуточной обработки данных: выявления, сбора в одну строку и дальнейшего разделения по отдельным ячейкам всех указанных абитуриентом направлений обучения по очной форме обучения;

• -    TDSheetZ_Check – лист, аналогичный TDSheetO_Check , но для заочной и очно-заочной форм обучения;

• -    TDSheetO_ToCopy – содержит в текстовом формате данные по абитуриентам (без дублей), подавшим документы на очную форму обучения, при этом их направления сгруппированы в ячейки в рамках одной строки;

• -    TDSheetZ_ToCopy – лист, аналогичный TDSheetO_ToCopy , но для заочной и очно-заочной форм;

• -    TOTAL – лист имеет структуру, подходящую для копирования данных в БД абитуриентов. Основные поля соответствуют выгрузке из 1С и «вытягиваются» с листа TDSheet .

Рассмотрим каждый лист более подробно.

Лист TDSheet полностью соответствует структуре отчета из 1С. На этот лист в ручном режиме копируются данные из актуального отчета 1С. Оператор может провести на данном листе многоуровневую сортировку всего массива данных. Однако, сортировать данные нужно будет обязательно на листах TDSheetO и TDSheetZ , поэтому первую сортировку можно не делать. Если же оператор все-таки принял решение сортировать весь массив данных, то нужно соблюдать следующую последовательность атрибутов: Рег.Номер → ФИО → ФормаОбучения → ОснованиеОбучения → Приоритет. Структура таблицы представлена на рис. 6.

Рис. 6. Общий вид всех атрибутов таблицы на листе TDSheet

Далее, данные с листа TDSheet необходимо разбить на два непересекающихся массива: данные по очной форме обучения (этот массив копируется на лист TDSheetO ), данные по очно-заочной и заочной форме обучения (этот массив копируется на лист TDSheetZ ).

Рассмотрим далее работу с данными абитуриентов, желающих поступить на очную форму обучения. На данном листе сортировка всего массива данных обязательна, вне зависимости, проводилась ли она ранее на листе TDSheet или нет. Без сортировки данных не будет возможным поставить выбранные абитуриентом направления в приоритетном порядке в отчет для БД абитуриентов. Для корректного представления данных необходимо соблюдать следующую последовательность атрибутов при многоуровневой сортировке: Рег.Номер → ФИО → ОснованиеОбучения → ОсобоеПраво – Целевое – Приоритет.

Теперь необходимо провести компоновку данных по каждому абитуриенту таким образом, чтобы собрать все указанные им направления обучения в одной строке, по разным столбцам, строго в порядке расставленных абитуриентом приоритетов. Т.к. данные уже отсортированы, то на листе TDSheetO по каждому абитуриенту находится от 1 до N строк в порядке приоритетов направлений.

За компоновку данных отвечает лист TDSheetO_Check . Опишем атрибуты таблицы этого листа, а также формулы, согласно которым обрабатываются данные.

• -    Регистрационный номер – копируется с листа TDSheetO как регистрационный номер абитуриента;

• -    ФИО – с помощью формулы вертикального поиска ВПР с листа TDSheetO копируется ФИО абитуриента, соответствующее регистрационному номеру в столбце слева; в общем виде формулу можно представить так:

=ВПР($ЯчейкаРег.Номера;;TDSheetO!Закрепленный_диапазон_все_данные;2;0).

• -    Физическое лицо (СНИЛС) - с помощью формулы вертикального поиска ВПР с листа TDSheetO копируется СНИЛС абитуриента, формула аналогична вышепредставленной, только изменяется номер столбца для получения данных;

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

=ЕСЛИ(TDSheetO!Предыдущая_Ячейка_Рег.Номер<>TDSheetO!Текущая_Ячейка_Рег.Номер; СЦЕ-ПИТЬ(TDSheetO!ТекущаяЯчейка_Направление);0)

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

=ЕСЛИ(TDSheetO!Предыдущая_Ячейка_Рег.Номер<>TDSheeЮ!Текущая_Ячейка_Рег.Номер;СЦЕПИТЬ( TDSheetO!ТекущаяЯчейка_Направление);СЦЕПИТЬ(ПредыдущаяЯчейка_ВсеНаправленияПоПриоритет ам;",";TDSheetO!ТекущаяЯчейка_Направление))

• - Фиксация уникального абитуриента (вхождение в отчет) - данный столбец заполняется «1» в строках, где происходит окончание сбора всех указанных направлений по одному абитуриенту; заполняется «0» в строках, относящихся к одному абитуриенту в процессе сбора по нему данных:

=ЕСЛИ(И(ИЛИ(ТекущийРегНомер=ПредыдущийРегНомер;ТекущийРегНомер<>ПредыдущийРегНомер); ТекущийРегНомер<>СледующийРегНомер);1;0)

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

=ЕСЛИ(ФиксОтдСтуд=1 ;ДЛСТР(ВсеНаправленияПоПриоритетам) -ДЛСТР(ПОДСТАВИТЬ(ВсеНаправленияПоПриоритетам; ",";""))+1;)

- Разделение направлений по отдельным ячейкам - с помощью функции разделение SPLIT() по символу разделителя «,», все собранные в одной ячейке направления обучения разбиваются в рамках одной строки на разные столбцы. Теперь каждому направлению соответствует своя ячейка в рамках одной строки уникального абитуриента.

Рис. 7. Общий вид всех атрибутов таблицы на листе TDSheetO_Check

Далее производится фильтрация данных по столбцу Фиксация уникального абитуриента (вхождение в отчет), и все уникальные абитуриенты копируются на лист TDSheetO_ToCopy . Эта таблица заметно компактнее исходной таблицы из отчета 1С, поскольку содержат уникальные записи. Также стоит отметить, что структура таблица на листе TDSheetO_ToCopy отличается от TDSheetO и соответствует структуре правой части базы данных абитуриентов (атрибутам № 5-25), причем направления в соответствующих столбцах указаны в порядке приоритетности.

Для работы с абитуриентами очно-заочной и заочной формы обучения принцип тот же, формулы аналогичны.

Остается завершающий этап работы Конструктора: перенос данных на лист TOTAL . Перенос данных происходит с нескольких листов. С TDSheet берутся данные регистрационных номеров и «зануляются», если два последующих регистрационных номера совпадают (т.е. относятся к одному и тому же абитуриенту):

=ЕСЛИ(TDSheet!ПредыдущийРегНомер<>TDSheet!ТекущийРегНомер;TDSheet!ТекущийРегНомер;0)

Таким образом, на итоговый лист, переносятся данные только по уникальным записям. С помощью формул ВПР с TDSheet копируются все данные, кроме информации о направлениях. С TDSheetO_ToCopy и TDSheetZ_ToCopy в части, касающейся направлений в строгом соответствии с текущим регистрационным номером, переносятся разделенные в приоритетном порядке данным по столбцам, причем сначала у абитуриента указываются все желаемые им очные правления, и только потом заочные, очно-заочные. Абитуриенты, подающие документы только на какую-то одну форму обучения, будут выделяться, т.к. у них будет заполнена только половина столбцов, отведенных под направления.

В ходе тестирования и дальнейшего ежедневного использования данного Конструктора в рамках приемной кампании ИСАУ университета «Дубна» в 2023 году было выявлено, что на работу с Конструктором оператор тратит от 10 до 15 минут, с учетом всех копирований, фильтрации, проверок данных. Без использования Конструктора преобразование данных из отчета 1С занимало бы от 40 минут до 1,5 часов. Т.к. Конструктор автоматизирован частично, то дальнейшим развитием данного решения видится полная автоматизация с помощью макросов.

Заключение

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