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

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

Задачи проекта:

- собрать данные из 12+ учетных систем (1С, КАС, LMS Moodle, Pyrus, SimpleOne, Directum, КЭДО, Bitrix24, Яндекс Трекер и др.) в единое хранилище с послойной архитектурой;

- автоматизировать загрузку и расчет витрин с обновлением от 3 минут до суток;

- перевести бизнес в режим самообслуживания: 63 дашборда с актуальными данными вместо выгрузок по запросу;

- поставить качество данных под контроль: мониторинг пайплайнов, проверки целостности, защитные пороги, документация и автотесты;

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

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

- Время подготовки регулярной отчетности сокращено с дней до минут; ручные выгрузки для руководителей исключены.

- Актуальность данных: оперативные процессы обновляются каждые 3-60 минут, ежедневные - к началу рабочего дня.

- Под контролем более 900 объектов хранилища в 49 схемах; витрина заявлений приемной кампании - 1,47 млн строк, витрина контингента - более 1,2 млн записей.

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

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

PostgreSQL (хранилище данных), Apache Airflow (оркестрация загрузки и расчетов), Python (библиотеки SQLAlchemy, psycopg2, pandas, sqlglot), Yandex DataLens (BI и дашборды), GitLab (версионирование и CI/CD-деплой DAG), Yandex Tracker (управление задачами), Linux-серверы. Системы-источники: 1С, КАС, LMS Moodle, Pyrus, SimpleOne, Directum, КЭДО, Bitrix24, Яндекс Метрика, Яндекс Формы, Яндекс Трекер.

Главная сложность - источники. Документации нет, контракты API восстанавливались по факту, часть справочников ведется вручную, идентификаторы в разных системах не совпадают: студент 1С и студент LMS - разные ключи, соответствие пришлось восстанавливать через данные посещаемости. Учетные системы хранят данные во вложенном JSON с кириллическими именами полей; API нестабильны - понадобились курсорная пагинация, ретраи и резервные стратегии выборки. Отдельная задача - не мешать бизнесу: тяжелые пересборки витрин разведены с DDL-операциями и ограничены таймаутами блокировок. И организационная часть - согласование единых определений показателей с владельцами процессов: технически свести данные проще, чем договориться, что считать контингентом и как считать задолженность.

ИСХОДНАЯ СИТУАЦИЯ

Данные о ключевых процессах были разнесены по десяткам систем: 1С и КАС (приемная кампания, расчеты с обучающимися, справки), LMS Moodle (учебный процесс), Pyrus (закупки), SimpleOne (ИТ-поддержка и АХО), Directum и КЭДО (документооборот), Bitrix24, Яндекс Трекер, Метрика, Формы. Сквозной картины не было ни у одного руководителя. Отчетность собиралась вручную (запрос в ИТ, выгрузка, сверка, письмо): подготовка занимала дни и недели, к моменту готовности данные устаревали. Одинаковые показатели в разных подразделениях считались по-разному, и совещания уходили в спор о цифрах вместо решений. У источников не было документации и стабильных контрактов API, ключи между системами не совпадали, часть справочников велась вручную, данные содержали персональные сведения. Сбои загрузки обнаруживались по жалобе пользователя, а не по мониторингу. Масштаб добавлял сложности: сеть филиалов и десятки направлений подготовки, миллионы строк заявлений в приемной кампании, ежедневные решения с высокой ценой ошибки.

РЕАЛИЗОВАННОЕ РЕШЕНИЕ

Внедрена корпоративная платформа данных из четырех контуров.

Хранилище: PostgreSQL, послойная архитектура raw - stg - dm, 49 схем и более 900 объектов (758 таблиц, 117 представлений, 48 материализованных представлений); витрины спроектированы под бизнес-вопросы, а не под структуру источников.

Загрузка и расчет: Apache Airflow, 48 продуктивных пайплайнов с расписаниями от 3 минут до суток (63 DAG-файла, 29 пакетов переиспользуемых задач); интеграции с 12+ системами по API и веб-сервисам.

Аналитика и BI: Yandex DataLens, 63 дашборда по приемной кампании, контингенту, успеваемости, расчетам с обучающимися, расписанию и аудиторному фонду, закупкам, ИТ-поддержке, документообороту и потоку задач - без ручных выгрузок.

Эксплуатация и качество данных: мониторинг пайплайнов каждые 3 минуты, ежечасный контроль структуры хранилища, проверки целостности витрин, защитные пороги, документация (49 README) и автотесты.

Процессы: задача в Яндекс Трекере - ветка - код-ревью - merge request - автоматический деплой в Airflow; реестр продуктивных пайплайнов с владельцами и расписаниями; аналитикам выдается доступ только на чтение.

ИЗМЕНЕНИЯ ПОСЛЕ ВНЕДРЕНИЯ

Ручные Excel-сборки заменены витринами и дашбордами: регулярные отчеты готовятся за минуты вместо дней, ключевые процессы обновляются автоматически несколько раз в сутки. Приемная кампания, контингент и расчеты с обучающимися ведутся по единым определениям показателей; конкурсная ситуация, прогноз зачисления и задолженность доступны руководителям без запросов в ИТ. Подразделения перешли в режим самообслуживания, ИТ-команда перестала быть «службой выгрузок». Сбои выявляются мониторингом в течение минут - до попадания неверной цифры в отчет. Появился воспроизводимый цикл «задача - код - тесты - релиз - документация».

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