Мини-проект · Реинжиниринг бизнес-процессов

Детский
сад

Приём ребёнка
и адаптация

От модели процесса
к веб-приложению

ГАПОУ ККАСиЦТ · 09.02.07 · ИС 24-2

Аксененко М., Верозубов А., Гребенкина М., Мергенева Д.

Новокузнецк · 2026

Цель и задачи

Пройти весь путь:
от процесса к приложению

Освоить полный цикл реинжиниринга — от модели «как есть»
до работающего веб-приложения с подключением к БД.

Описать AS-IS

Модель «как есть» в IDEF0 / BPMN

Найти узкие места

Задержки, повторы и согласования

Спроектировать TO-BE

Горизонтальное и вертикальное сжатие

Нормализовать БД

Структура данных до 3НФ

Создать приложение

ASP.NET Core MVC + MS SQL Server

Провести тестирование

Проверка сценариев и бизнес-правил

Предметная область и участники

От заявки до адаптации —
общая работа семи участников

Детский сад: присмотр, уход и воспитание детей 1,5–7 лет.

Заявка

Медосмотр

Согласование

Зачисление

Адаптация

Участник	Ответственность в процессе
Родитель	Подаёт документы, получает услугу
Секретарь	Принимает и регистрирует документы
Медсестра	Проверяет медкарту и состояние здоровья
Воспитатель	Оценивает готовность к адаптации
Педагог-психолог	Проводит диагностику адаптации
Заведующая	Принимает решение, оформляет приказ
Отдел образования	Внешний контроль: ОВЗ, спорные случаи

04 · Модель AS-IS

Последовательные проверки задерживают приём

Секретарь принимает документы

Воспитатель даёт заключение

Медсестра / психолог проверяют повторно

Заведующая подписывает приказ

Секретарь регистрирует и уведомляет

05 · Узкие места

Повторы и централизация создают лишнюю работу

Проблема	Причина	Последствие
Согласования	Неясные полномочия	Задержка 3–7 дней
Повторные проверки	Нет единого реестра	Дублирование работы
Все решения наверху	Нет делегирования	Перегрузка заведующей
Разрозненные этапы	Документы и осмотр отдельно	Несколько визитов
Нет обратной связи	Нет мониторинга	Позднее выявление проблем

Решение: объединить операции и сократить уровни согласования.

06 · Горизонтальное сжатие

Документы проверяются параллельно в одной системе

Родитель подаёт полный пакет документов

Секретарь
Проверка документов

Медсестра
Проверка медкарты

Автопроверка комплектности в CRM

Не хватает данных
Уведомить родителя

Пакет готов
Передать на решение

Оценка в учебной схеме: 7 → 2–3 дня; контакты: 4 → 1–2.

07 · Вертикальное сжатие

Стандартные решения передаются старшему воспитателю

Как есть

Заведующая

Медсестра / психолог

Воспитатель

Секретарь

4 уровня согласования

Как должно быть

Старший воспитатель

Стандартные заявки и приказы

Заведующая

ОВЗ и спорные случаи; стратегический контроль

1 уровень для стандартной заявки

Предлагаемое распределение полномочий в модели TO-BE.

08 · Модель TO-BE

Единый маршрут ведёт от заявки к адаптации

Полный пакет от родителя

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

Автопроверка комплектности

Решение по типу заявки

Уведомление → начало адаптации

09 · Нормализация до 3НФ

Семь таблиц разделяют данные и ответственность

Parents · Родители

Children · Дети

MedCards · Медкарты

Groups · Группы

Applications

Заявления

PK: AppID

FK: ParentID, ChildID,
MedCardID, GroupID,
CreatedBy, ApprovedBy

Users · Пользователи

AuditLog · Журнал

Users связана с созданием и утверждением заявок, а также журналом.

1НФ
Атомарные значения

2НФ
Зависимость от всего ключа

3НФ
Нет транзитивных зависимостей

10 · Архитектура веб-приложения

Интерфейс, логика и данные разделены

Браузер

Вход · заявления · справочники · уведомления

↓ запрос / ответ ↑

ASP.NET Core MVC · C#

Views
Страницы

Controllers
Запросы

Services
Бизнес-правила

Доступ
Роли

↓ запрос к данным / ответ ↑

MS SQL Server

7 связанных таблиц · заявки, участники и журнал действий

11 · Роли и экраны

Пять ролей получают свои возможности

Роль	Возможности
Admin	Пользователи и полный доступ
Secretary	Создание заявок, справочники
Nurse	Медкарты и подтверждение здоровья
SeniorTeacher	Утверждение стандартных заявок
Manager	Исключительные случаи, отчёты

Вход → Dashboard → Заявки

Создание → Проверка → Утверждение

Справочники: родители, дети, медкарты, группы

12 · Реинжиниринг в коде

Изменения процесса отражаются в сервисах и ролях

Пример ограничения доступа в ASP.NET Core MVC

[Authorize(Roles = "SeniorTeacher")]
public async Task<IActionResult>
    Approve(int id)
{
    await service.ApproveAsync(id);
    return RedirectToAction("Index");
}

Одна форма
Родитель, ребёнок, медкарта и группа

ApplicationService
Комплектность и определение статуса

NotificationService
Уведомления; AuditLog — история

Учебный пример; права проверяются на сервере, не только в интерфейсе.

13 · Бизнес-логика

Проверки определяют статус и маршрут заявки

Правило	Поведение
Возраст	1,5–7 лет; иначе создание недоступно
Документы	Неполный пакет → «На проверке»
Свободные места	Есть → «Готово»; нет → исключение
Утверждение	Стандарт — воспитатель; ОВЗ — заведующая
Статус	На проверке → Готово → Зачислен / Отклонён
Уведомления	Родителю — документы; руководителю — исключения
Ролевой доступ	Действия и данные в рамках полномочий
Журнал	Кто, что и когда изменил

14 · Тест-кейсы

Тесты охватывают доступ, данные и бизнес-правила

Сценарий	Ожидаемое поведение
Верный / неверный пароль	Вход / отказ в доступе
Создание заявки, пустые поля	Сохранение / ошибки валидации
Утверждение по ролям	Воспитатель — разрешено; секретарь — отказ
Возраст вне диапазона	Заявка не создаётся
Группа заполнена	Исключительный случай
Обрыв связи с БД	Обработанная ошибка без потери контроля

В материалах заявлено 15 тест-кейсов; на снимке показаны 10 с отметками успеха.

Выше — укрупнённые сценарии. Результаты приведены по материалам автора, приложение здесь повторно не тестировалось.

15 · Выводы и перспективы

Реинжиниринг связывает процесс, данные и приложение

В учебном проекте

Модели AS-IS и TO-BE

Объединение операций и делегирование

7 таблиц в модели 3НФ