Информационная система образовательной организации: что действительно нужно директору

# Информационная система образовательной организации: что действительно нужно директору

Редакция SGI24. Ниже — проектная архитектура, а не заявленный кейс внедрения в образовательной организации. [О бюро](/company).

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

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

Спроектировать систему образовательной организации

Начните с решений директора

До выбора платформы сформулируйте вопросы, на которые система обязана отвечать:

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

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

Семь частей системы

1. Официальный сайт и привлечение

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

В систему передаются:

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

Сайт не должен хранить отдельную базу лидов, если карточка уже создана в CRM.

2. Приём и набор

CRM сопровождает поступающего от обращения до решения. Она хранит статус, ответственного, следующий шаг, мероприятия, места и итог.

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

Один общий статус «клиент» не показывает этап образовательного выбора.

3. Образовательный процесс

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

Статья 16 № 273-ФЗ определяет электронное обучение и дистанционные технологии и устанавливает требования к электронной информационно-образовательной среде. Для основных общеобразовательных программ и программ СПО при применении таких технологий с обработкой данных обучающихся часть 3.1 статьи 16 предусматривает использование государственных информационных систем и многофункционального сервиса обмена информацией.

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

4. Договоры и документы

После решения о зачислении подтверждённые сведения переходят в договор, приказ и другие документы. Система контролирует:

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

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

5. Финансы

Бухгалтерская система остаётся основной по проводкам и фактическим платежам. На экран руководителя передаются статусы: выставлено; оплачено; частично оплачено; просрочено; возвращено; требует сверки.

Менеджер не должен вручную ставить «оплачено» по сообщению родителя. Интеграция получает подтверждение из учётной системы или платёжного провайдера.

6. Сотрудники и доступ

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

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

7. Аналитика директора

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

Хорошая сводка показывает действие:

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

Не один монолит, а управляемая архитектура

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

Ценность создают связи:

text сайт → CRM приёма → договор → оплата → зачисление → образовательная система ↘ документы ↘ управленческий отчёт

Для каждой стрелки определяются:

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

Интеграция без владельца только быстрее распространяет неверные сведения.

Единый идентификатор

Имя и телефон не подходят как постоянный ключ. Они меняются и могут совпадать. Система создаёт внутренние идентификаторы для:

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

Это не означает одну огромную таблицу. Системы обмениваются идентификаторами и необходимыми полями, сохраняя свои зоны ответственности.

Справочники

Одинаковые сущности должны называться одинаково:

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

Если сайт пишет «10 класс, инженерный профиль», CRM использует «старшая школа 1», а бухгалтерия «тариф C», отчёт требует ручной расшифровки. Справочник связывает коммерческое название с официальным идентификатором и учётной услугой.

Роли и минимальный доступ

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

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

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

Персональные данные

Карта данных входит в архитектуру. Для каждой системы фиксируются:

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

Новый модуль нельзя подключать только по решению одного подразделения. Он проверяется по договору, маршруту и доступу.

Образовательные процессы подробно разобраны в статьях «Персональные данные в школе» и «Персональные данные в колледже».

Документы официального сайта

Раздел «Сведения об образовательной организации» требует постоянного обновления. Система может вести реестр публикаций:

• документ;
• нормативное основание;
• владелец содержания;
• дата утверждения;
• дата публикации;
• следующая проверка;
• ссылка;
• версия;
• статус.

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

Кабинеты участников

Не каждому пользователю нужен весь портал. Кабинет строится вокруг задач.

Поступающий

Видит заявление, документы, статусы и следующий шаг.

Родитель

Видит информацию о своём ребёнке в пределах полномочий, договор, оплату и сообщения.

Обучающийся

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

Сотрудник

Видит рабочую очередь и документы своей роли.

Директор

Видит отклонения и управленческие показатели.

Один перегруженный кабинет с десятками меню ухудшает безопасность и работу.

Уведомления

Система различает: событие для пользователя; рабочую задачу сотрудника; техническую ошибку; управленческое отклонение; рекламное сообщение.

Не отправляйте полный документ в письмо. Уведомление ведёт в защищённый кабинет. Канал выбирается по чувствительности и подтверждённым контактам.

Интеграции и ошибки

Успешный запрос не всегда означает правильный результат. Контроль включает:

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

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

Что внедрять сначала

Приоритет задаёт потеря управления:

1. Все обращения попадают в одну приёмную очередь.
2. У каждой карточки есть ответственный и следующий шаг.
3. Договор связан с поступлением.
4. Оплату подтверждает учётная или платёжная система.
5. Зачисление передаётся без ручного дублирования.
6. Права сотрудников управляются централизованно.
7. Директор видит просрочки и ошибки.

После этого добавляются кабинеты, сложные отчёты и автоматизация менее частых сценариев.

Как описать требования подрядчику

Техническое задание должно содержать не перечень экранов, а процессы:

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

Например: «После подтверждённой оплаты система зачисления получает идентификатор поступающего и программу; при успехе создаёт ученика, при конфликте ставит задачу ответственному; директор видит число необработанных ошибок».

Частые ошибки цифровизации

• Покупка платформы до описания процессов.
• Перенос всех старых таблиц без отбора.
• Одинаковые права у сотрудников.
• Несколько систем независимо меняют статус оплаты.
• Телефон используется как идентификатор человека.
• Интеграция не сообщает о смысловой ошибке.
• Директор получает отчёт раз в месяц вручную.
• Обязательные документы сайта обновляет один человек без контроля.
• Персональные данные оцениваются после запуска.
• Новый модуль добавляет ещё одну ручную выгрузку.

Первый этап цифровой системы

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

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

Обсудить архитектуру образовательной системы

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

Официальные источники

• Статья 16 № 273-ФЗ: электронное обучение и дистанционные образовательные технологии
• Статья 28 № 273-ФЗ: компетенция и ответственность образовательной организации
• Статья 29 № 273-ФЗ: информационная открытость
• Статья 19 № 152-ФЗ: безопасность персональных данных

Архитектура определяется по типу программ, статусу организации, действующим государственным системам и существующим продуктам.