Автосекретарь в дипломе: от IVR до интеграции с МИС на примере кейса Хакасии
МТС опубликовала любопытную аналитику по Хакасии: медучреждения республики сократили время записи пациента по телефону ровно в три раза — за счёт переноса рутинных операций на автосекретаря виртуальной АТС. Для выпускника ИТ это не просто новость, а готовая фактура под ВКР: работающий бизнес-кейс с измеримым результатом, понятной архитектурой и открытыми метриками. Разберём, как превратить эту публикацию в защищаемую дипломную работу, какие инструменты использовать и на чём чаще всего «горят» студенты, выбравшие телеком-тематику без опыта в телефонии.
FAQ: что студенты спрашивают чаще всего, прежде чем взять тему по автосекретарю
Мне обязательно иметь доступ к реальной МИС медучреждения для ВКР?
Нет. Достаточно смоделировать интеграцию через открытые API и заглушки. Сами МИС (например, «1С:Медицина», Барс.Медицина, ЕГИСЗ) закрыты соглашениями, но документация по REST-профилям частично доступна. В главе 2 вы описываете адаптерный слой, а в главе 3 поднимаете mock-сервер на FastAPI или WireMock и прогоняете сценарии.
Какой стек выбрать: Asterisk, FreeSWITCH или облачная АТС?
Для диплома оптимален Asterisk: открытый, документированный, ставится за час в Docker, есть реальные примеры dialplan. FreeSWITCH мощнее, но порог входа выше. Облачная АТС (МТС, Манго, UIS) — экономнее по времени, но у вас не будет кода. Компромисс — Asterisk + облачный SIP-транк для тестовых звонков.
Реально ли доказать «трёхкратное ускорение» в параграфе с испытаниями?
Да, если сравнивать не абсолютные секунды, а нормированные метрики: AHT (Average Handle Time), FCR (First Call Resolution), ASA (Average Speed of Answer) и Abandonment Rate. Соберите baseline на 50–100 пробных звонках вручную, затем повторите сценарий через IVR-сценарий и приведите распределение, а не одно среднее.
Как оформить схемы, чтобы нормоконтроль не завернул?
UML-диаграммы последовательности и BPMN 2.0 — по ГОСТ 19.701 и рекомендациям ISO/IEC 19505. Архитектуру подавайте в C4-модели (Context, Container), но каждую диаграмму сопровождайте текстом на 1–2 абзаца. Согласование с нормоконтролем лучше пройти в начале семестра, а не за неделю до защиты.
Темы ВКР, которые вырастают напрямую из кейса Хакасии
-
Тема 1. Разработка IVR-автосекретаря для записи пациентов с интеграцией в медицинскую информационную систему.
Актуальность: прямая отсылка к статье — рост нагрузки на колл-центры и потребность в автоматизации первичного контакта. Цель: спроектировать и реализовать сценарий голосового меню с записью на приём. Задачи: анализ бизнес-процесса записи; выбор SIP-платформы (Asterisk/FreeSWITCH); проектирование API-шлюза к МИС; нагрузочное тестирование. Структура: Гл.1 — анализ предметной области и метрик AHT/FCR; Гл.2 — архитектура C4 + BPMN-диаграмма; Гл.3 — стенд, тесты, расчёт эффективности. -
Тема 2. Оптимизация телефонной нагрузки контакт-центра медучреждения на базе виртуальной АТС.
Актуальность: перегрузка регистратур в районных больницах. Цель: снизить долю пропущенных вызовов и высвободить операторов. Задачи: аудит текущих метрик; построение имитационной модели (AnyLogic/SimPy); внедрение автосекретаря; оценка экономии фонда рабочего времени. Структура: Гл.1 — теория массового обслуживания (M/M/c); Гл.2 — имитационная модель и сценарии; Гл.3 — итоговые SLA-показатели. -
Тема 3. Интеллектуальный голосовой автосекретарь с распознаванием речи для записи на приём.
Актуальность: ASR/TTS перестали быть роскошью, а Хакасия показала, что даже базовый IVR даёт эффект. Цель: собрать прототип с Yandex SpeechKit/GigaChat API. Задачи: обзор ASR-моделей; проектирование диалогового сценария; интеграция с календарём врача; оценка WER и Intent Recognition Accuracy. Структура: Гл.1 — обзор NLP-стека; Гл.2 — пайплайн ASR→NLU→TTS; Гл.3 — метрики качества диалога. -
Тема 4. Оценка экономической эффективности внедрения виртуальной АТС в медицинской организации.
Актуальность: заказчику нужны не только фичи, но и расчёт ROI/TCO. Цель: построить методику расчёта эффекта от автоматизации. Задачи: сбор исходных данных; расчёт TCO облачного и on-premise решения; сценарии «как есть / как будет»; срок окупаемости. Структура: Гл.1 — методология TCO/ROI и PMBOK 7; Гл.2 — финансовая модель; Гл.3 — анализ чувствительности и выводы.
Как встроить материал статьи в три главы ВКР
Глава 1. Аналитическая: превращаем новость в постановку задачи
Не пересказывайте пресс-релиз. Извлеките из публикации сущности: тип организации (медучреждение), инструмент (автосекретарь виртуальной АТС), результат (трёхкратное сокращение времени). Сформулируйте гипотезу: снижение AHT обусловлено переходом от ручного диспетчирования к сценарному IVR. Постройте контекстную диаграмму C4 уровня Context (пациент → телефония → МИС → регистратура) и BPMN «как есть» — по шагам: дозвон, ожидание, диалог с оператором, поиск слота, подтверждение. Здесь же уместны ссылки на ISO/IEC 25010 (функциональная пригодность, производительность) и ГОСТ 34.601 как методическую рамку.
Глава 2. Проектная: архитектура и интеграция
Основной вес главы — диаграмма последовательности UML для сценария «пациент записывается на приём». Обязательно покажите обмен через CTI/ARI-шлюз и REST-адаптер к МИС. Ниже — минимальный фрагмент Asterisk dialplan, который без стыда смотрится в приложении:
[ivr-med]
exten => s,1,Answer()
same => n,Wait(1)
same => n,Background(privetstvie_med)
same => n,Read(vybor,,1,,1,7)
same => n,GotoIf($["${vybor}" = "1"]?zapis)
same => n,GotoIf($["${vybor}" = "2"]?raspisanie)
same => n,GotoIf($["${vybor}" = "3"]?operator)
same => n,Playback(invalid)
same => n,Goto(s,1)
same => n(zapis),AGI(zapis_priyoma.py)
same => n,Hangup()
same => n(operator),Queue(registratura)
same => n,Hangup()
А вот псевдокод адаптера, который вызывает API МИС после выбора пациента — покажите его в приложении как листинг:
POST /api/v1/ivr/appointment
Authorization: Bearer <token>
{
"phone": "+79001234567",
"doctor_id": "A-113",
"slot": "2026-03-30T10:15:00+07:00",
"source": "ivr"
}
Не забудьте про защиту API: TLS, ограничение частоты запросов, журналирование через OpenTelemetry — это уместная ссылка на рекомендации OWASP API Security Top 10.
Глава 3. Практическая: метрики, тесты, экономика
Соберите полигон: Asterisk в Docker, SIP-клиент (Zoiper/MicroSIP), mock-МИС на FastAPI. Прогоните 100 тестовых звонков в двух режимах — «с оператором» и «через IVR». Считайте не только среднее, но и медиану, 95-й перцентиль, доверительный интервал. Отдельно посчитайте FCR и Abandonment Rate. Итоговая таблица метрик — это ваш главный защитный аргумент.
| Метрика | Как есть | С автосекретарём | Комментарий |
|---|---|---|---|
| AHT, сек | 185 | 62 | Ускорение ≈3× |
| FCR, % | 71 | 88 | Больше записей с первого звонка |
| Abandonment, % | 18 | 6 | Меньше отвалов |
| ASA, сек | 42 | 3 | Мгновенный вход в меню |
Чему вы научитесь на такой ВКР
- Проектировать отказоустойчивые интеграции телефонии с медицинскими системами.
- Описывать требования и архитектуру по ГОСТ 34 и модели C4 — без воды и «красивых картинок».
- Считать AHT, FCR и TCO так, чтобы цифры выдерживали вопросы комиссии.
- Поднимать стенды Asterisk + Docker + mock-API за один вечер и воспроизводить эксперименты.
- Оформлять технические приложения (dialplan, листинги, спецификации API) по требованиям нормоконтроля.
- Каждая задача из введения имеет свой параграф и вывод в заключении.
- Диаграммы C4, BPMN и UML подписаны и пронумерованы, есть ссылки в тексте.
- Все метрики имеют формулу, единицы измерения и источник данных.
- Код в приложениях не «висит в воздухе» — на каждый листинг есть ссылка из главы.
- Ссылка на новость CNews и другие источники оформлены единообразно (ГОСТ Р 7.0.100-2018).
- Проверена уникальность текста и корректность списка литературы.
- Терминология (IVR, SIP, МИС, AHT) расшифрована при первом употреблении.
1. Пустой пересказ статьи. Публикация даёт лишь бизнес-факт, а ВКР требует технику: протокол SIP (RFC 3261), архитектуру шлюза, метрики. Добавьте модели и эксперименты, иначе комиссия увидит «реферат».
2. Метрики «на глазок». Заявлять ускорение в три раза, не показав методику эксперимента, — верный путь к неудовлетворительной оценке. Объём выборки, условия теста, критерии — всё должно быть зафиксировано.
3. Ноль внимания к безопасности и 152-ФЗ. Телефонная запись содержит персональные данные. Обязательно опишите шифрование (SRTP/TLS), разграничение доступа и журнал аудита — это те требования, которые в Хакасском кейсе тоже присутствуют, но не вынесены в пресс-релиз.
Источник: Медицинские организации Хакасии в три раза сократили время записи пациентов по телефону с помощью автосекретаря (опубликовано 2026-03-26)