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

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

• Проанализировать существующие бизнес-процессы поддержки («AS-IS»).
• Спроектировать архитектуру будущей системы («TO-BE»).
• Рассчитать экономическую эффективность от ее внедрения.

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

Глава 1. Теоретические и аналитические основы проекта

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

Почему стандарты ITIL служат надежным фундаментом для проекта

Проектирование системы автоматизации не должно происходить в вакууме. Для этого существуют общепризнанные методологии, и ключевой из них является ITIL (Information Technology Infrastructure Library). Впервые опубликованная в 1991 году, эта библиотека представляет собой свод лучших практик по управлению IT-услугами. Использование ITIL в дипломной работе не только повышает ее академическую ценность, но и гарантирует, что проектируемое решение будет соответствовать мировым стандартам.

Для службы технической поддержки наиболее релевантны следующие процессы ITIL:

• Управление инцидентами (Incident Management): Основная цель — максимально быстрое восстановление нормальной работы сервиса и минимизация негативного влияния на бизнес-операции.
• Управление проблемами (Problem Management): Задача этого процесса — выявление и устранение коренных причин инцидентов, чтобы предотвратить их повторное возникновение.
• Выполнение запросов (Request Fulfilment): Этот процесс отвечает за обработку стандартных запросов от пользователей, таких как предоставление доступа, консультации или установка ПО.

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

Как провести анализ текущей работы техподдержки на предприятии

Первый практический шаг любого проекта по автоматизации — это предпроектное обследование, результатом которого становится модель «AS-IS» («как есть»). Этот этап критически важен для выявления узких мест и обоснования необходимости изменений. Анализ текущей ситуации, например, в условном ЗАО «Эксперт» или АО «Тандер», обычно включает следующие шаги:

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

Для визуализации текущих потоков данных и процессов эффективно использовать DFD-диаграммы (Data Flow Diagram). Они наглядно показывают, как информация движется внутри системы, и помогают точно определить, на каких этапах происходят задержки, потери данных или избыточные действия.

Обоснование необходимости внедрения автоматизированной системы

После того как модель «AS-IS» построена, выявленные недостатки становятся очевидными. На этом этапе необходимо перейти от простого описания к четкой аргументации. Проблемы, обнаруженные в ходе анализа, следует сгруппировать и представить как доказательную базу для внедрения автоматизации. Типичные проблемы:

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

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

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

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

Разработка модели «TO-BE», или как будет работать новая система

Модель «TO-BE» («как будет») — это детальное описание будущей автоматизированной системы, которая призвана решить все проблемы, выявленные на этапе анализа. Она формирует четкое видение конечного продукта. Ключевыми функциональными блоками такой системы обычно являются:

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

Новая логика работы визуализируется с помощью обновленных DFD-диаграмм. Они наглядно демонстрируют, как изменились потоки данных: вместо разрозненных каналов (почта, телефон) появляется единая точка входа, а движение заявки становится прозрачным и контролируемым. Таким образом, модель «TO-BE» не просто описывает набор функций, а показывает, как именно новая система решает ранее обозначенные бизнес-проблемы.

Как сделать правильный выбор технологического стека и методологии

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

Методология разработки. Для дипломного проекта чаще всего рассматривают два подхода:

• Waterfall («Водопад»): Классический последовательный подход, где каждый этап (анализ, проектирование, разработка, тестирование) строго следует за предыдущим. Он хорош для проектов с четко определенными и неизменными требованиями.
• Agile (Гибкая методология): Итеративный подход, где разработка ведется короткими циклами (спринтами) с постоянной обратной связью. Он лучше подходит для проектов, где требования могут уточняться в процессе работы.

Технологии. Выбор конкретных языков программирования и систем управления базами данных (СУБД) зависит от требований к проекту и компетенций разработчика. Ниже представлен краткий сравнительный анализ популярных решений.

Сравнение технологий для разработки Help Desk системы

Компонент	Технология	Преимущества
Серверная часть (Backend)	PHP	Низкий порог входа, большое сообщество, доступный хостинг.
	Python / Java / C#	Строгая типизация, высокая производительность, подходят для сложных корпоративных систем.
База данных (СУБД)	MySQL / PostgreSQL	Бесплатные, открытый исходный код, высокая надежность, большое сообщество.
	SQL Server	Глубокая интеграция с продуктами Microsoft, мощные инструменты администрирования.

Проектирование архитектуры и ключевых компонентов системы

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

1. Клиентский уровень (Client Tier): Пользовательский интерфейс, работающий в браузере пользователя.
2. Сервер приложений (Application Server Tier): Здесь выполняется вся бизнес-логика: обработка запросов, управление заявками, работа с базой знаний.
3. Сервер баз данных (Data Server Tier): Отвечает за хранение и управление всеми данными системы.

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

Разработка пользовательских интерфейсов и сценариев взаимодействия

Даже самая функциональная система будет бесполезна, если ею неудобно пользоваться. Поэтому разработка продуманного UI/UX (User Interface/User Experience) является ключом к успешному внедрению. Необходимо спроектировать и описать основные экраны системы и сценарии взаимодействия с ними.

• Личный кабинет пользователя: Здесь пользователь видит список своих заявок, их статусы и может обратиться в базу знаний.
• Форма подачи заявки: Должна быть максимально простой и понятной, с возможностью прикреплять файлы и выбирать категорию проблемы.
• Интерфейс специалиста поддержки: Часто реализуется в виде канбан-доски со столбцами «Новые», «В работе», «Решенные», что позволяет наглядно отслеживать загрузку.
• Раздел базы знаний: Должен иметь удобный поиск и четкую структуру статей для быстрого нахождения решений.

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

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

Проектная часть завершена. Система спроектирована. Остался последний, но самый важный для бизнеса вопрос: насколько это выгодно? Экономическое обоснование превращает технический проект в бизнес-предложение.

Как рассчитать затраты на разработку и внедрение системы

Расчет затрат — первый шаг экономического анализа. Их принято делить на две категории:

1. Единовременные (капитальные) затраты:

• Стоимость разработки: Рассчитывается на основе трудозатрат команды (аналитик, разработчик, тестировщик) в человеко-часах, умноженных на их ставки.
• Закупка оборудования: Если для работы системы требуются новые серверы.
• Стоимость лицензионного ПО: Затраты на операционные системы, СУБД или другие коммерческие компоненты.

2. Постоянные (операционные) затраты:

• Заработная плата персонала: Например, системного администратора, который будет поддерживать систему.
• Расходы на обслуживание: Оплата хостинга или электроэнергии для серверов, продление лицензий, техническая поддержка.

Тщательный подсчет этих затрат формирует полную стоимость владения системой (TCO — Total Cost of Ownership).

Оценка потенциальной выгоды и расчет срока окупаемости

Посчитав расходы, необходимо оценить, какую выгоду принесет проект. Выгоды также бывают двух типов:

• Прямая экономическая выгода: Это легко измеряемые в деньгах преимущества. Например, сокращение штата первой линии поддержки на одного человека за счет того, что 30% типовых запросов теперь решаются через базу знаний.
• Косвенная выгода: Ее сложнее измерить, но она не менее важна. Сюда относится повышение лояльности клиентов (CSAT) за счет ускорения решения проблем, а также снижение потерь бизнеса от простоев оборудования и сервисов.

На основе затрат и выгод рассчитываются ключевые показатели эффективности. Основной из них — ROI (Return on Investment), или коэффициент возврата инвестиций. Он показывает, насколько прибыльным является проект. Формула для расчета срока окупаемости помогает определить, через какой период времени чистая прибыль от проекта покроет первоначальные вложения. Вывод о целесообразности проекта делается именно на основе этих объективных цифр.

Заключение: от идеи до готового бизнес-решения

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

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

• Интеграцию с корпоративной CRM-системой для создания единого профиля клиента.
• Разработку мобильного приложения для пользователей и специалистов.
• Внедрение элементов искусственного интеллекта для автоматической классификации заявок.

Что придает работе академический вес и завершенность

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

Список использованной литературы

1. Введение в системы баз данных – СПб: Издательский дом «Вильямс», 2000. — 848 с.;
2. Вендров А.М., CASE-технологии. Современные методы и средства проектирования информационных систем — М.: Финансы и статистика, 2006.
3. Гаджинский А.М. Основы логистики: Учеб.пособие/ Инфоpм.-внедpен.центp «Маpкетинг».- М., 2005.- 121, с.: ил., табл.
4. Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2006. 450 – 490 с.
5. Джексон Г. Проектирование реляционных баз данных для использования с микро-ЭВМ М.: Финансы и статистика, 1991.
6. Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2005. – 592 с.
7. Дэвид Флэнаган. JavaScript. Подробное руководство: Учебник – М.: Символ Плюс, 2008. 243 – 249 с.
8. Зеленков Ю.А. Введение в базы данных. Центр Интернет ЯрГУ, 1997.
9. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения / Пер. с англ. — М.: Мир, 1982. — 386 с., ил.
10. Ивлиев М.К., Порошина Л.А. Автоматизация оперативного и бухгалтерского учета товаров, 1997.
11. Информационные системы: Учебник для вузов. 2-е изд. СПб: «Питер», 2005 г — 656 стр.
12. Керри Н. Праг, Майкл Р. Ирвин, Access 2000 — Библия пользователя, Диалектика, 2000.
13. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
14. Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2006.
15. Лифшиц Н.И., Левин Е.Т Механизация и автоматизация процессов отборки и комплектования заказов на складах М., 1970.
16. Практическое руководство по программированию / Пер. с англ. Б. Мик, П. Хит, Н. Рашби и др.; под ред. Б. Мика, П. Хит, Н. Рашби. — М.: Радио и связь, 1986. — 168 с., ил.
17. Приказ Минэнерго РФ от 19 июня 2003 г. N 232 «Об утверждении Правил технической эксплуатации нефтебаз»
18. Проектирование и использование баз данных: Учебник. М.:Финансы и статистика, 1995г. – 191 с.;
19. Разработка программного обеспечения — СПб : «Питер», 2004 г — 592 стр.
20. Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2005 – 400с.:ил;
21. Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2006, 250с., ил.;
22. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. ГОСТ 19.701-90 (ИСО 5807-85) / Государственный комитет СССР по управлению качеством продукции и стандартам, 01.01.1992.
23. Фокс Дж. Программное обеспечение и его разработка / Пер. с англ. — М.: Мир, 1985. — 368 с., ил.
24. Язык компьютера. Пер. с англ, под ред. и с предисл. В. М. Курочки-на. — М.: Мир, 1989. — 240 с., ил. Глушаков С.В., Ломотько Д.В. Базы данных, 2000.