В современных условиях информационного общества, когда информационные технологии пронизывают практически все сферы деятельности, любая IT-организация нуждается в новых путях повышения эффективности своего функционирования. Всестороннее развитие и повышение эффективности достигаются за счёт автоматизации рутинных операций и бизнес-процессов, использующихся в IT-компании. Автоматизация может быть направлена на улучшение качества предоставляемых компанией услуг, повышение производительности труда сотрудников, произведение высокоточных и быстрых расчётов, сбор и формирование различной отчётности и ряд других задач [1, 2].
В настоящей статье рассматриваются вопросы автоматизации технической поддержки клиентов на примере компании ООО «НПЦ КСБ» [3]. Автоматизация процессов технической поддержки компании направлена на централизованный прием и обработку обращений действующих клиентов, которым компания предоставляет какие-либо продукты/услуги/сервисы на возмездной или безвозмездной основе в течение срока поддержки, обусловленного договором продажи, договором поддержки или оговоренного иным способом.
Цель исследования: разработка проекта системы Service Desk для технической поддержки клиентов ООО «НПЦ-КСБ».
Для достижения поставленной цели решены следующие задачи:
1) анализ систем технической поддержки и особенностей технической поддержки ООО «НПЦ-КСБ»; формирование требований, предъявляемых к разрабатываемой системе;
2) концептуальное моделирование и проектирование системы;
3) разработка интерактивного прототипа системы Service Desk;
4) анализ области дальнейшего применения результатов работы.
Необходимость разработки собственной системы технической поддержки в рассматриваемом случае (для ООО «НПЦ-КСБ») обусловлена отсутствием у имеющихся на рынке решений, таких как Омнидеск, Okdesk и решения на основе «1С», функционала взаимодействия с компаниями-партнёрами. В разрабатываемой системе планируются внедрение данного функционала, то есть взаимодействие с компаниями-партнёрами, в целях уменьшения рабочей нагрузки сотрудников своей компании и оказания за счет этого круглосуточной технической поддержки клиентов вне зависимости от часового пояса.
Материалы и методы исследования
Внедрение автоматизированной системы технической поддержки Service Desk позволяет контролировать приём и обработку обращений в службу поддержки, фиксировать случаи поломки оборудования и сбои работы программного обеспечения и наиболее объективно оценить качество предоставляемых компанией услуг [4, 5]. На основании данной информации можно выявить слабые места компании, распланировать этапы развития IT-инфраструктуры, а также получить знание о текущем уровне квалификации сотрудников.
На рис. 1 представлена концептуальная модель системы технической поддержки клиентов ООО «НПЦ КСБ».
Рис. 1. Концептуальная модель системы Service Desk
Из всех вышеперечисленных внешних сущностей можно уделить особое внимание следующим подсистемам:
- Подсистема управления обращениями предназначена для организации взаимодействия между компанией и ее клиентом, в период действия договора поддержки. Подсистема даёт возможность манипуляции и обработки обращений пользователей и партнёров.
- Подсистема уведомлений необходима для оповещения всех пользователей системы в случае тех или иных изменений, касающихся непосредственно роли или пользователя системы.
- Подсистема управления клиентами предназначена для управления и настройки информации, касающейся контрагентов (клиентов) компании.
- Подсистема управления партнёрами предоставляет возможность настройки компетенций, то есть прав на продажу лицензий на тот или иной продукт компании ООО «НПЦ КСБ», а также прав на обработку обращений клиентов компании на уровне первой линии поддержки.
- Подсистема управления пользователями необходима для управления и настройки ролей и полномочий пользователей. Предоставляет возможность создавать новые роли, менять их полномочия, обрабатывать заявки на регистрацию, а также возможность управлять учётными записями пользователей.
- Подсистема управления линиями поддержки предназначена для распределения сотрудников поддержки по линиям, что в свою очередь позволит равномерно распределить нагрузку и наладить контроль за ответственностью сотрудников.
- Подсистема управления продуктами предназначена для ведения каталога продуктов (услуг), предоставляемых компанией своим клиентам, в процессе эксплуатации, по факту оказания которых Компания осуществляет сервисную поддержку клиентов.
- Подсистема управления настройками и справочниками позволяет манипулировать данными справочников системы.
- Подсистема генерации отчётов необходима для отображения необходимых изменений (трендов), которые отображают динамику изменений показателей эффективности системы.
- Подсистема интеграции с трекером задач играет роль «сборщика» задач, который автоматически заводит задачи, которые были переведены на третью линию поддержки, в системе JIRA для дальнейшей работы программистов.
Все внешние сущности взаимосвязаны между собой верхнеуровневыми потоками данных. Таким образом, концептуальная модель определяет взаимодействие основных функциональных подсистем проектируемой информационной системы, как между собой, так и с внешними входными и выходными потоками данных и внешними объектами, что в свою очередь помогает определить рамки и границы проекта.
На данный момент обработка обращений клиентов происходит по электронной почте. В силу того, что обращения распределяются и фиксируются вручную, данный процесс необходимо автоматизировать. После полного реинжиниринга процесса на диаграмме обработки тикета «TO BE» (рис. 2) можно заметить появление тикетной системы для работы с обращениями. В результате чего все обращения клиентов в техническую поддержку фиксируются и заводятся в системе, что позволит собирать статистическую отчётность и проводить контроль скорости и качества обработки обращений.
Рис. 2. Диаграмма обработки тикета
Рис. 3. Фрагмент информационной модели
На рис. 3 приведен фрагмент модели «Сущность – Связь», построенной на основе концептуального моделирования.
На информационной модели можно выделить следующие сущности: Учётная запись пользователя, Роли, Полномочия, Уведомления, Тикеты, Типы обращений, Очередь обращений, Комментарии, Компоненты, Отзывы, Оценка качества обслуживания, Отчёты по обращениям, Условия SLA, Приоритеты, Календарь, Организации, Продукты, Вендоры, Обязательства, Серверы, SLA, Таблица принадлежности продукта к обязательству, Версии продукта, Виды обязательства, Справочник регионов, Партнёры, Компетенции, Справочник сотрудников организаций, Справочник сотрудников партнёров, Справочник сотрудников поддержки, Линии поддержки продукта, Таблица принадлежности сотрудника поддержки к линии.
Результаты исследования и их обсуждение
Результатом работы является интерактивный прототип системы Service Desk для технической поддержки ООО «НПЦ КСБ», разработанный в среде Axure RP. Интерактивным прототипом является некий набор связанных друг с другом html-макетов. Переход между макетами осуществляется при щелчке по соответствующим компонентам при помощи специальных сценариев (взаимодействий). Взаимодействия компонентов прототипа помогают сформировать частичное представление о логике работы приложения, так как, нажав на тот или иной элемент на форме, можно определить реакцию системы. Таким образом, взаимодействия помогают детализировать требования, описанные в спецификации, что в свою очередь является большим плюсом для разработчиков системы, так как уменьшатся затраты времени на прояснение неявных требований. Далее приводится тестирование процесса подачи и отслеживания обращения клиентом.
Когда клиент переходит к процессу подачи обращения, у него сразу возникает вопрос, который должен попасть в систему для дальнейшего решения. Перед тем как клиент подаст обращение, у него есть возможность посмотреть базу знаний «Раздел часто задаваемых вопросов и методов их решения».
Далее, если у клиента есть возможность самому найти решение вопроса или проблемы, то потребность задать вопрос отпадает, что благоприятно скажется на эффективности системы. Но зачастую пользователи не желают тратить время на самостоятельные поиски решения проблем, поэтому ему предлагается выбрать тип обращения для дальнейших действий. После того, как пользователь выберет тип обращения, ему предоставляется возможность выбрать продукт, по которому он хочет получить техническую поддержку, и описать суть вопроса. Создав обращение, во вкладке «Мои обращения», расположенной в зоне горизонтального меню, можно увидеть перечень своих обращений в службу поддержки (рис. 4).
Рис. 4. Скриншот формы создания обращений
Рис. 5. Скриншот формы просмотра конкретного обращения
Посмотрев список своих обращений и щёлкнув по ссылке, пользователь имеет возможность перейти к конкретному вопросу, чтобы ближе ознакомиться с деталями обращения (рис. 5).
Итак, на форме просмотра конкретного обращения пользователю представлена возможность вести переписку с сотрудниками поддержки, эскалировать обращение, переоткрывать, закрывать, оставить отзыв, а также посмотреть детали обращения, а именно: тему, статус, дата создания, описание, историю комментариев.
Форма эскалации, закрытия и переоткрывания обращения имеет одинаковый интерфейс взаимодействия в виде модального окна, которое требует указать причину действия.
Выводы
В результате работы разработан проект системы Service Desk для обеспечения помощи и поддержки пользователей технологичных продуктов и сервисов предприятия. Главная функция, включенная в систему – это функционал взаимодействия с компаниями-партнёрами. Данный функционал позволит правильно распределить нагрузку на сотрудников технической поддержки филиалов и партнеров предприятия. Поэтому результаты данной работы могут быть использованы при оптимизации деятельности системных интеграторов, групп компаний или крупных компаний с большим количеством филиалов, являющихся разработчиками или поставщиками IT-решений и услуг в области информационных технологий (программных и/или программно-аппаратных средств). На данный момент имеющиеся аналоги системы не содержат в полной мере названного выше функционала, требуют детальной оптимизации при внедрении с учетом особенностей предприятия, содержат ряд лишних функций.
Переходя к разработанному интерактивному прототипу, можно отметить высокую эффективность визуализации требований, прототип соблюдает логику системы. В настоящее время логика работы интерактивного прототипа протестирована и отлажена, наибольшее количество неточностей в требованиях выявлены и отображены в BMPN диаграммах.