Проектирование и разработка автоматизированной системы управления заявками в дипломной работе

В современных компаниях объемы информации растут лавинообразно, и ручное управление процессами становится неэффективным. Особенно остро эта проблема стоит в сфере обработки обращений, где каждая потерянная заявка или сорванный срок — это прямой удар по репутации и финансам. Решением становятся системы управления заявками (СУЗ) — специализированные цифровые инструменты, предназначенные для централизованного приема, обработки и контроля всех поступающих обращений. Автоматизация учета заявок позволяет кардинально решить проблемы, связанные с рутинными операциями, человеческим фактором и потерей данных. Целью данной дипломной работы является проектирование и разработка автоматизированной системы управления заявками. Для ее достижения будут решены следующие задачи: проведен анализ предметной области, разработаны функциональные требования, спроектирована архитектура и база данных, а также дана оценка экономической эффективности проекта.

Глава 1. Теоретические основы и анализ предметной области

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

1.1. Что скрывается за понятием современных систем управления сервисом

Современные системы управления заявками вышли далеко за рамки простых Help Desk систем. Их идеология базируется на двух ключевых концепциях: ITIL (IT Infrastructure Library) и Enterprise Service Management (ESM). ITIL — это библиотека лучших практик по управлению IT-услугами, которая рассматривает любую заявку как часть более крупного процесса предоставления сервиса. ESM, в свою очередь, расширяет этот подход на всю организацию, применяя сервисные принципы не только к IT, но и к другим отделам: АХО, HR, бухгалтерии.

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

1. Создание: Заявка регистрируется через любой удобный канал (email, портал, мессенджер).
2. Классификация и маршрутизация: Система автоматически определяет категорию и приоритет, после чего направляет ее ответственному исполнителю.
3. Исполнение: Специалист работает над решением задачи, фиксируя все действия в системе.
4. Контроль и эскалация: Система отслеживает соблюдение сроков (SLA) и при необходимости эскалирует заявку на более высокий уровень.
5. Закрытие и обратная связь: После выполнения работ пользователь подтверждает решение проблемы и может оставить оценку качества, что запускает цикл непрерывного улучшения.

Таким образом, современная СУЗ — это не просто база данных, а интеллектуальный центр управления сервисными процессами компании.

1.2. Исследование бизнес-процессов на примере судоходной компании

Чтобы понять ценность автоматизации, рассмотрим бизнес-процессы «как есть» (as-is) на примере условной судоходной компании. Основная деятельность компании связана с организацией морских перевозок, что порождает множество внутренних и внешних запросов: от заявок на фрахт судна и расчет стоимости перевозки до запросов на техническое обслуживание навигационного оборудования на борту.

В условиях ручного управления процесс обработки заявки выглядит следующим образом. Запрос от клиента или внутреннего сотрудника поступает по электронной почте или телефону менеджеру. Менеджер фиксирует его в Excel-таблице, вручную определяет ответственный отдел (коммерческий, технический, фрахтовый) и пересылает информацию коллегам. Дальнейшая коммуникация происходит в разрозненных почтовых переписках и мессенджерах. Это порождает целый ряд «узких мест»:

• Потерянные заявки: Письмо может попасть в спам или просто затеряться в потоке другой корреспонденции.
• Срывы сроков: Без централизованной системы контроля невозможно отследить, на каком этапе «зависла» задача и кто несет за это ответственность.
• Человеческий фактор: Менеджер может неверно определить категорию заявки или просто забыть передать ее в работу, что ведет к ошибкам и снижению качества услуг.
• Отсутствие аналитики: Невозможно собрать статистику по количеству и типам заявок, времени их выполнения и загрузке персонала, что мешает принимать взвешенные управленческие решения.

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

Глава 2. Проектирование автоматизированной системы

Проведенный анализ доказывает необходимость внедрения автоматизированной системы. Теперь наша задача — превратить выявленные проблемы в четкие технические спецификации и спроектировать архитектуру будущего решения.

2.1. Формулируем цели, задачи и функциональные требования

На основе проблем, выявленных в Главе 1, сформулируем цели и задачи проекта. Главная цель — повышение эффективности управления заявками за счет автоматизации их жизненного цикла. Для ее достижения необходимо решить следующие задачи:

• Разработать единую точку входа для всех типов заявок.
• Автоматизировать процесс маршрутизации и назначения ответственных.
• Внедрить механизм контроля сроков выполнения (SLA).
• Обеспечить сбор аналитики для принятия управленческих решений.

На основе этих задач формируется список функциональных требований к системе:

1. Система должна позволять регистрацию заявок через различные каналы: веб-портал, email, чат-бот в Telegram.
2. Система должна автоматически классифицировать заявку и назначать ответственного или группу исполнителей на основе предустановленных правил.
3. Должен быть реализован механизм управления уровнем сервиса (SLA) с возможностью настройки разных временных нормативов для разных типов заявок.
4. Система должна автоматически отправлять уведомления пользователям и исполнителям при смене статуса заявки.
5. Должен быть реализован модуль отчетности, позволяющий формировать отчеты по ключевым метрикам (количество заявок, среднее время решения, процент нарушений SLA).

Помимо функциональных, важно учесть и нефункциональные требования, такие как надежность (система должна быть доступна 99.5% времени), производительность (время отклика интерфейса не более 2 секунд) и масштабируемость (способность выдерживать рост нагрузки до 1000 заявок в сутки).

2.2. Обоснование выбора технологического стека

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

• Стек 1: PHP/Laravel + MySQL. Проверенное и широко распространенное решение для веб-разработки. Laravel — мощный фреймворк с низким порогом входа, а MySQL — надежная и бесплатная СУБД.
• Стек 2: Python/Django + PostgreSQL. Связка, популярная в enterprise-разработке. Python отлично подходит для сложных бизнес-логик и интеграций, а PostgreSQL славится своей надежностью и расширяемостью.

Для нашего проекта, где важна не только стандартная CRUD-функциональность, но и потенциальная возможность интеграции с системами аналитики и машинного обучения (например, для предиктивной классификации заявок в будущем), выбор склоняется в пользу второго варианта. Python/Django + PostgreSQL обеспечивает большую гибкость для дальнейшего развития системы и лучше соответствует задачам, требующим сложной обработки данных. Django предоставляет надежную ORM и встроенную административную панель, что ускоряет разработку, а PostgreSQL гарантирует целостность данных на высоком уровне.

2.3. Проектирование базы данных как фундамента системы

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

На концептуальном уровне мы определяем ключевые сущности и связи между ними. Для нашей СУЗ можно выделить следующие сущности: «Заявка» (Ticket), «Клиент» (Client), «Исполнитель» (Agent), «Услуга» (Service), «Компания» (Company). Эти сущности и их взаимосвязи визуализируются с помощью ER-диаграммы (Entity-Relationship Diagram).

На логическом уровне мы детализируем структуру, определяя атрибуты каждой сущности и проводя нормализацию данных. Нормализация — это процесс устранения избыточности данных, который помогает избежать аномалий при их обновлении и обеспечивает целостность. Для большинства систем достаточно доведения структуры до третьей нормальной формы (3НФ). Например, вместо хранения полного имени клиента в каждой его заявке, мы храним только идентификатор клиента, а само имя находится в отдельной таблице «Клиенты».

На физическом уровне происходит реализация логической модели средствами выбранной СУБД. В нашем случае, с использованием PostgreSQL, это будет выражено в виде SQL-кода для создания таблиц.

CREATE TABLE Tickets (
    ticket_id SERIAL PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    description TEXT,
    status VARCHAR(50) NOT NULL,
    priority VARCHAR(50),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    client_id INT REFERENCES Clients(client_id),
    agent_id INT REFERENCES Agents(agent_id),
    service_id INT REFERENCES Services(service_id)
);

CREATE TABLE Clients (
    client_id SERIAL PRIMARY KEY,
    full_name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE,
    company_id INT REFERENCES Companies(company_id)
);

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

2.4. Разработка архитектуры приложения и ключевых модулей

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

1. Уровень представления (Client): Это пользовательский интерфейс (веб-страницы, мобильное приложение), с которым взаимодействуют клиенты и исполнители.
2. Уровень логики (Server): Это серверная часть приложения (наш Django-проект), где реализуется вся бизнес-логика: обработка запросов, применение правил маршрутизации, контроль SLA.
3. Уровень данных (Database): Это система управления базами данных (PostgreSQL), отвечающая за хранение и извлечение информации.

Такое разделение позволяет разрабатывать, тестировать и масштабировать каждый уровень независимо друг от друга. Для визуализации логики работы ключевых сценариев используются UML-диаграммы. Например, диаграмма вариантов использования (Use Case Diagram) покажет, какие действия доступны разным ролям (клиент может «Создать заявку», а исполнитель — «Изменить статус»). А диаграмма последовательности (Sequence Diagram) детально опишет взаимодействие между объектами системы при выполнении сценария, например, «Создание новой заявки через Telegram-бот»: от получения сообщения ботом до записи данных в базу и отправки уведомления пользователю. Это позволяет интегрировать различные каналы коммуникации в единый рабочий процесс.

Глава 3. Практическая реализация и тестирование

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

3.1. Описание алгоритмов обработки жизненного цикла заявки

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

1. Получить данные новой заявки (тип услуги, компания клиента, ключевые слова в описании).
2. Обратиться к таблице правил маршрутизации в базе данных.
3. Найти правило, соответствующее параметрам заявки. Например, если тип услуги = «Техническое обслуживание» И компания клиента = «Судно ‘Победа'», то назначить группу «Инженеры флота».
4. Если правило найдено, обновить поле `agent_id` или `agent_group_id` в таблице заявок.
5. Если правило не найдено, назначить заявку на диспетчера первой линии поддержки для ручной обработки.

Алгоритм эскалации при нарушении SLA:
Этот алгоритм работает в фоновом режиме, периодически проверяя все активные заявки.

• Выбрать все заявки в статусе «В работе».
• Для каждой заявки сравнить текущее время с плановым временем решения (которое рассчитывается на основе приоритета и SLA).
• Если текущее время превышает плановое, изменить статус заявки на «Просрочена» и повысить ее приоритет.
• Отправить уведомление руководителю ответственного исполнителя.

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

3.2. Стратегия тестирования и результаты

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

• Модульное тестирование: Проверка отдельных функций и компонентов системы в изоляции. Например, тест функции, рассчитывающей плановое время решения заявки.
• Интеграционное тестирование: Проверка взаимодействия нескольких модулей. Например, тест сценария создания заявки через email-шлюз, который затрагивает модули приема почты, парсинга и записи в БД.
• Системное тестирование: Комплексная проверка всей системы на соответствие функциональным и нефункциональным требованиям.

Для проверки ключевого функционала составляются тест-кейсы.

Тест-кейс 1: Создание заявки через email-шлюз
Шаги: 1. Отправить письмо с темой «Проблема с навигацией» на специальный email-адрес. 2. Проверить базу данных. 3. Проверить почтовый ящик исполнителя.
Ожидаемый результат: В таблице `Tickets` появилась новая запись с темой из письма. Назначен ответственный из группы «Техническая поддержка». Исполнителю пришло email-уведомление о новой заявке.
Фактический результат: Соответствует ожидаемому.

Успешное прохождение всех тест-кейсов подтверждает практическую значимость и работоспособность разработанной системы.

Глава 4. Оценка экономической эффективности проекта

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

4.1. Расчет затрат на разработку и внедрение

Затраты на проект делятся на две основные категории: капитальные (единовременные) и операционные (постоянные). В рамках дипломного проекта мы сфокусируемся на капитальных вложениях.

Затраты на разработку:

• Оплата труда команды: Это основная статья расходов. Рассчитывается как произведение трудозатрат в часах на ставку специалиста. (Например, Аналитик: 80 часов, Разработчик: 320 часов, Тестировщик: 120 часов).
• Накладные расходы: Обычно составляют определенный процент от фонда оплаты труда (аренда офиса, амортизация оборудования).

Затраты на внедрение:

• Приобретение оборудования: Стоимость сервера для размещения приложения и базы данных.
• Лицензии на ПО: В нашем случае стек (Linux, Python, PostgreSQL) является бесплатным, что снижает эту статью расходов до нуля.
• Обучение персонала: Затраты на проведение тренингов для диспетчеров и исполнителей по работе с новой системой.

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

4.2. Анализ рентабельности и срока окупаемости

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

• Сокращение трудозатрат: Автоматизация рутинных операций (регистрация, маршрутизация) высвобождает время сотрудников, которое они могут потратить на решение более сложных задач. Это прямая экономия на фонде оплаты труда.
• Уменьшение потерь из-за ошибок: Снижение количества потерянных заявок и нарушенных сроков напрямую влияет на лояльность клиентов и сокращает финансовые потери.
• Повышение производительности: Прозрачность процессов и быстрый доступ к информации позволяют исполнителям выполнять заявки быстрее.

На основе этих данных рассчитываются ключевые показатели эффективности инвестиций:

• ROI (Return on Investment): Показывает рентабельность проекта. Рассчитывается как отношение чистой прибыли от проекта к объему инвестиций.
• PBP (Payback Period): Срок окупаемости. Показывает, за какой период времени доходы от проекта покроют первоначальные затраты.

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

Заключени�� и перспективы развития

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

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

• Внедрение модуля машинного обучения: Использование исторических данных для автоматического предсказания категории, приоритета и исполнителя для новых заявок.
• Интеграция с новыми каналами: Добавление поддержки популярных мессенджеров (например, WhatsApp) для расширения каналов коммуникации.
• Разработка мобильного приложения: Создание удобного мобильного клиента для исполнителей, позволяющего работать с заявками «в полевых условиях».

Эти усовершенствования позволят превратить систему из инструмента автоматизации в интеллектуального помощника, еще больше повышая эффективность сервисных процессов в компании.

Библиографический список

1. Емельянова Н.З., Партыка Т.Л., Попов И.И. Основы по-строения автоматизированных информационных систем. – М.: Форум, Инфра-М, 2007.
2. Муссиано Ч., Кеннеди Б. HTML и XHTML . Подробное руководство, 6-е издание.
3. Джеффри Д. Ульман, Дженнифер Уидом. Основы реляци-онных баз данных, Лори, М, 2006 г.
4. Джен Л. Харрингтон. Проектирование реляционных баз данных Лори, 2006 г.
5. Кен Хендерсон. Профессиональное руководство по SQL Server. Структура и реализация (+ CD-ROM), Вильямс, М, 2006 г.
6. Павел Пушкарев. Web script.ru. Управление сайтом. http://webscript.ru/stories/02/01/03/3584690
7. Ачагу Р.М. Характеристика программного продукта. http://synopsis.kubsu.ru/informatic/operator/lecture/theme3_1_1.htm
8. Вендров А.М. Проектирование программного обеспечения экономических информационных систем, Финансы и статистика, М, 2002
9. Министерство здравоохранения Российской Федерации. Гигиенические требования к вычислительной технике, ус-ловиям и организации работы, М, 2002 г.
10. Министерство здравоохранения Российской Федерации. Гигиенические требования к вычислительной технике, условиям и организации работы, М, 2002 г.