Презентация к диплому «Разработка веб-сервиса учёта заявок»

• Тема: веб-сервис учёта заявок
• Автор: Логинов Артём Игоревич
• Цель — автоматизация техподдержки

Уважаемые члены государственной экзаменационной комиссии, представляю вашему вниманию выпускную квалификационную работу на тему «Разработка веб-сервиса учёта заявок в отделе технической поддержки». Цель работы — автоматизировать процесс приёма и обработки обращений пользователей, чтобы повысить качество и скорость работы службы поддержки.

• Проблема: телефон и почта, нет единой базы
• ≈5 000 обращений за 2025 год
• 4 часа — среднее время реакции
• 22% просроченных, ~6% потерянных
• Отсюда — цель проекта

До начала проекта отдел поддержки работал по старинке: заявки принимались по телефону и электронной почте, единой базы обращений не было. Из-за этого часть заявок просто терялась, а сроки реакции зависели от того, кто и когда успел записать обращение. За 2025 год мы зафиксировали около пяти тысяч обращений, при этом среднее время реакции составляло четыре часа, почти четверть заявок выполнялась с просрочкой, а примерно шесть процентов терялись вовсе. Именно эти проблемы и определили необходимость создания единого веб-сервиса учёта заявок.

• Цель — веб-сервис учёта заявок
• 4 задачи: анализ, архитектура, реализация, тестирование
• Дальше — анализ существующих решений

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

• Объект — процесс приёма заявок
• Предмет — архитектура и функции сервиса
• Цель — автоматизация процесса

Объектом исследования выступает сам процесс приёма и обработки заявок в отделе технической поддержки — от момента обращения пользователя до закрытия заявки. Предметом — архитектура и функциональность разрабатываемого веб-сервиса, который этот процесс автоматизирует. Иными словами, мы изучаем, как устроен текущий процесс и как его можно улучшить с помощью информационной системы.

• OTRS — бесплатно, но доработка
• GLPI — слабая интеграция
• YouTrack — дорого
• Вывод: своя разработка

Мы рассмотрели три популярные готовые системы учёта заявок. У каждой есть свои сильные стороны, но ни одна не подходит нам полностью. OTRS — бесплатная, но требует серьёзной доработки под наши процессы. GLPI удобен, но интеграция с корпоративными сервисами ограничена. YouTrack — мощный, но дорогой. Поэтому мы приняли решение разработать собственный сервис, который закроет все наши требования.

• Требования: функциональные и нефункциональные
• Функциональные: заявки, исполнители, статусы, отчёты
• Нефункциональные: отклик, масштабирование, безопасность
• Дальше — архитектура сервиса

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

• Клиент → API → сервер → БД
• REST API — единая точка входа
• PostgreSQL + Redis для данных
• Дальше — реализация ролей

Разберём, как устроен сервис изнутри. Пользователь работает в браузере — это клиентская часть, одностраничное приложение. Все запросы идут через единый REST API, который связывает интерфейс с серверным приложением. Сервер обрабатывает логику, проверяет права и обращается к базе данных. Данные хранятся в PostgreSQL, а для кэширования сессий используем Redis. Такой поток обеспечивает быструю обработку заявок и надёжное хранение.

• Три роли: оператор, инженер, администратор
• Экраны: список, карточка, создание, отчёты
• Стек: React, Node.js, PostgreSQL
• Дальше — тестирование системы

Перехожу к практической части. Система построена вокруг трёх ролей: оператор принимает и ведёт заявки, инженер выполняет работы, администратор управляет доступом и настройками. Для каждой роли предусмотрены свои ключевые экраны — от списка заявок с фильтрами до карточки с полной историей и экрана отчётов. В основе — современный стек: React с TypeScript на клиенте, Node.js на сервере и PostgreSQL для хранения данных. Такая архитектура обеспечивает гибкость и простоту дальнейшего развития сервиса.

• 120 тест-кейсов
• 18 дефектов найдено
• Все исправлены до опытной эксплуатации
• Виды: функциональное, UI, API, нагрузочное

Качество сервиса мы подтвердили комплексным тестированием. Провели функциональное, UI, API и нагрузочное тестирование — всего 120 тест-кейсов. В ходе проверок нашли 18 дефектов, и все они были исправлены до начала опытной эксплуатации. Это значит, что система вышла в реальную работу без известных критических проблем.

• Время реакции: 4 ч → 1 ч
• Снижение в 4 раза
• Автоматическая маршрутизация заявок
• Дальше — просроченные и потерянные заявки

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

• Затраты 600 тыс., экономия 1,2 млн
• Окупаемость 6 месяцев
• Экономия вдвое больше затрат
• Дальше — выводы и практическая значимость

Перейдём к экономической стороне. Разработка сервиса обошлась в 600 тысяч рублей — это разовые вложения. За счёт сокращения времени реакции и потерь заявок годовая экономия составит 1,2 миллиона рублей, то есть вдвое больше затрат. Срок окупаемости — всего 6 месяцев, что подтверждает целесообразность внедрения. Таким образом, проект не только решает операционные задачи, но и даёт измеримый финансовый эффект.

• Цель достигнута, задачи выполнены
• Время реакции: 4,5 → 1,5 часа
• Потеря заявок: 120 → 0
• Готов к тиражированию

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