18
● Safari;
● Telegram;
● Office 365;
● Time Machine.
Google ChromemacOS Mojave
Стандартный набор ПО для ПК всех
работников службы техподдержки,
MacBook Pro и Mac mini
ОС Windows 10/macOS Mojave
SafariTelegram
Time MachineOffice 365
Avocode
ПК менеджера управления проектами
Стандартный
набор
PhpStorm
ПК разработчиков (backend и
frontend)
Стандартный
набор
Text
Sublime
Git
FileZilla
VSCode
MinGW
Terminal
Git
Postman
Avocode
Sketch
ПК дизайнеров (UX/UI)
Стандартный
набор
Slack
XMind
Keynote
Яндекс.Диск
Adobe Illustrator
CC
Adobe Photoshop
CC
Adobe After
Effects
Adobe Animate
CC
CraftManager
Avocode
CINEMA 4D
Adobe Media
Encoder CC
ОС Windows Server 2016 R2
RAID5
СУБД MS SQl
Server 2008
Kaspersky
Internet Security
Сервер
ОС Windows 10/macOS Mojave ОС Windows 10/macOS Mojave
ОС Windows 10/macOS Mojave
Рисунок 3 Программная архитектура службы технической
поддержки банка
Принимая во внимание специфику деятельности отдела,
персональные компьютеры компании обеспечиваются дополнительными
программными обеспечениями.
19
Разработчики (backend и frontend): Стандартные пакеты; PhpStorm;
Sublime; Text; FileZilla; Git; MinGW; VSCode; Git; Terminal; Avocode;
Postman.
Дизайнеры (UX/UI): Стандартные пакеты; Sketch; Avocode;
CraftManager; XMind; Slack; Яндекс.Диск; Keynote; Adobe Photoshop CC;
Adobe Illustrator CC; Adobe Animate CC; Adobe After Effects; Adobe Media
Encoder CC; CINEMA 4D.
Менеджеры управления проектами: Стандартные пакеты; Avocode.
1.2 Характеристика совокупности задач, задачи и аргументация
необходимости автоматизации
1.2.1 Анализ совокупности задач автоматизации и характеристика
существующих бизнес-процессов «Как есть»
Проведем моделирование бизнес-процессов существующей
технологии работы специалистов службы технической поддержки с
использованием методологии ARIS. Диаграмма функций процесса с учетом
разделения его на потенциальные варианты обработки заявки (AS-IS)
представлена на рисунке 4.
Рисунок 1 Диаграмма функций процесса «Прием заявок
клиентов» с учетом разделения его на потенциальные
варианты обработки заявки
20
В рассматриваемом подразделении процесс по обработке заявки от
пользователя с удачным исходом (закрытие заявки) делится на 2 сценария:
1) Прием заявки от плательщика производится всегда
сотрудником первой линии.
2) Когда сотрудник первой линии не может закрыть заявку сам, то
он обязан передать ее специалисту второй линии. На рисунке 5
представлена типичная схема обработки заявки в данном случае (AS-IS).
3) Когда специалист второй линии закрыть заявку не может, то он
обязан ее передать в соответствующий отдел. На рисунке 6 представлена
типичная схема обработки заявки в данном случае (AS-IS).
Из представленных выше схем взаимодействия можно увидеть, что
при нагрузках на службу технической поддержки, большая часть заявок
перенаправляется отделу тестирования. Очевидно, что такое распределение
ресурсов оптимальным назвать нельзя. Проанализируем недостатки
существующей технологии.
В процессе анализа таких схем взаимодействия, и сравнения их с ПО,
используемым подразделением службы технической поддержки можно
заметить, что в процессе обработки заявок и от плательщиков, и от агентов
специалисты службы технической поддержке вынуждены обращаться к
протоколам работы определенных сервисов (процессинга, мониторинга)
или устройств (модемов, терминалов).
Типичная схема работы с протоколами функционирования системы
представлена на рисунке 7.
Из данного рисунка можно увидеть, что процесс работы над
типичными клиентскими заявками (как плательщиков, так и агентов) при
помощи разбора протоколов считается неоптимальным и затратным по
времени процессом.
21
Поступила заявка
от пользователя
Заявка принята службой
технической поддержки
Поиск платежа
сотрудником первой линии
Передача заявки
сотруднику второй линии
Платеж не найден
Заявка передана
Поиск платежа в логах
проццесинга\терминала
Платеж не найден
Передача заявки в отдел
тестирования
Первая линия СТП
Первая линия СТП
Вторая линия СТП
Вторая линия СТП
FB
Статус: заявка принята
FB
Статус: заявка передана
FB
Статус: платеж не найден
FB
Статус: платеж не найден
Рисунок 2 Процесс обработки заявки с передачей заявки в
отдел тестирования
22
Запрошен отчет о
состоянии работы системы
ООО «NetbyNet»
Запрос принят
администратором
Закрытие запроса
Администратор
системы
FB
Сформированы отчеты о
состоянии системы
Рисунок 3 Процесс формирования отчётности о состоянии
работы
Рисунок 4 Процесс взаимодействия специалистов службы
технической поддержки с протоколами функционирования
сервисов
Однако, исходя из анализа ПО, применяемого подразделением
службы технической поддержки, было продемонстрировано, что у службы
отсутствуют программные решения для успешной реализации 2-х
ключевых внешних критериев собственной деятельности:
23
1) Эффективность взаимодействия с сотрудниками –
специалистам службы технической поддержки приходиться передавать
некоторые случаи отделу тестирования. Специалисты отдела тестирования
затрачивают ежедневно 2 - 4 часа рабочего времени на обрабатывание
заявок, поступивших от службы технической поддержки. В процессе
работы над сложными заявками, число необработанных заявок
лавинообразно повышается, удовлетворенность пользователей
терминальной сети (как плательщиков, так и агентов) – снижается.
2) Инициативность профессиональной деятельности –
несомненно, что, зная о больших проблемах сервисов либо аппаратных
средств терминальной сети от плательщиков или агентов – у специалиста
службы технической поддержки нет возможности действовать проактивно;
ему приходится решать проблему постфактум, разбираясь в ней по степени
поступления.
Учитывая изложенные выше проблемы, в рамках предоставленной
работы предлагается осуществить разработку программного средства,
позволяющего специалистам службы технической поддержки действовать
проактивно, что предоставит возможность повышения скорости
обрабатывания заявок высокой и средней сложности, а, следовательно,
уменьшения потока заявок, перенаправляемых профильным службам (в
этом случае – отделу тестирования и разработки). Создаваемый
программный продукт получил рабочие название «Автоматизация службы
технической поддержки».
1.2.2 Определение места проектируемой задачи в совокупности задач и
ее описание
Задача автоматизации службы технической поддержки имеет
смежные задачи, связанные с работой абонентского отдела, ИТ-отдела,
экономического отдела. На рисунке 8 показана диаграмма места
проектируемой задаче в комплексе задач предприятия.
24
Автоматизация
службы
технической
поддержки
АИС Отдела по
работе с
клиентами
АИС ИТ-отдела
АИС
экономического
отдела
Формирование
отчетности
Рисунок 5 Диаграмма места проектируемой задачи в
совокупности задач предприятия
1.2.3 Аргументация необходимости применения вычислительной
техники для решения задачи
Приведем анализ экономической сущности задач специалистов
службы технической поддержки. Всего задачи данного типа можно
разделить на три группы:
- Прием заявок от клиентов и сотрудников компании;
- Отправка заявки в работу;
- Мониторинг исполнения.
Из таблицы 2 можно увидеть, что применение информационной
системы предоставит возможность существенной экономии рабочего
времени сотрудников, сокращения трудозатрат на выполнение ключевых
технологических процедур службы технической поддержки.
В ходе исследования выявлено, что в технологии службы технической
поддержки АО «Тинькофф Банк» возникает необходимость в составлении
отчетных форм и выходных документов, в которых имеются данные из
информационной базы.
25
Таблица 2
Частота составления отчетных документов
№
Наименование
документа
Время
составления
без
использования
автоматизации
Время
составления с
использованием
автоматизации
Частота
составления,
раз в год
1
Заявка в службу
техподдерржки
15 мин.
0,5 мин
6000
2
Передача
заявки на
исполнение
15 мин.
0,5 мин.
4000
3
Оформление
актов
выполненных
работ
15 мин.
0,5 мин.
4000
4
Назначение
специалистов на
выполнение
заявки
15 мин.
0,5 мин.
6000
5
Формирование
сводных
ведомостей по
заявкам в
службу
техподдержки
15 мин.
1 мин.
7000
6
Анализ качества
выполнения
работ
15 мин.
1 мин.
6000
7
Анализ работы
оборудования
2 ч.
1 мин.
12
8
Подготовка
отчётности
руководству
1 ч.
1 мин.
100
Существуют различные варианты подхода к приобретению
информационной системы, такие как покупка готовой ИС, покупка и
доработка существующих решений, разработка силами аутсорсинговых
компаний, самостоятельная разработка.
Как было рассмотрено выше, на рынке нет готовых решений,
полностью отвечающих требованиям, предъявляемым к разрабатываемой
системе. Доработка существующих решений либо невозможна ввиду
лицензионных обязательств конечного пользователя, либо экономически
нецелесообразна. Кроме того, существует риск, что «полуфабрикатное»
решение не будет обеспечено должным образом технической и справочной
26
документацией, позволяющей вести изменения самостоятельно, без
привлечения компании-разработчика.
Разработка силами аутсорсинг-компании выгодна лишь в тех случаях,
когда в организации нет своего штата ИТ-компетентных специалистов. У
аутсорсинга есть как свои преимущества, так и недостатки. Однако, как уже
упоминалось, особенности финансирования бюджетных организаций не
позволяют прибегать к услугам сторонних компаний с целью
сопровождения, создания и внедрения информационных систем.
Подход, при котором предприятие самостоятельно осуществляет
разработку новой системы под свои требования считается самым
дорогостоящим. Такой подход предполагает наличие на предприятии
отдела информационных технологий. Чтобы осуществить разработку
информационной системы контроля заявок необходимо привлечение на
постоянной основе высококвалифицированных специалистов, знакомых со
спецификой современного образовательного процесса, знать и понимать
параметры функционирования существующей информационной системы
организации.
Выбор в пользу такого подхода возможен по следующим причинам:
в организации уже есть ИТ-отдел со специалистами
необходимой квалификации;
организация не желает знакомить сторонние организации со
спецификой своей деятельности, передавать конфиденциальную
информацию сторонним разработчикам.
Из предложенных выше способов приобретения системы решено
разрабатывать новую систему самостоятельно, т.к. данный способ более
приемлем и удобен в плане финансово-экономической и административно-
управленческой политики функционирования, кроме того, в штате
сотрудников на постоянной основе работают квалифицированные ИТ-
специалисты, знакомые с разработкой информационных систем для нужд
службы контроля заявок технической поддержки.
27
Для работы системы необходимо наличие следующих
организационных единиц:
- Руководство;
- Администраторы системы, администраторы базы данных,
администраторы приложения;
- Пользователи.
При внедрении системы в промышленную эксплуатацию необходимо
издание документов:
- Приказ о вводе системы в промышленную эксплуатацию;
- Приказ о назначении администраторов системы, программы и
безопасности;
- Определение списка специалистов, допущенных к работе в
программе.
После издания нормативных актов вносятся изменения в
должностные инструкции специалистов, возможны варианты возложения
обязанностей на штатных специалистов, так и введение в штатное
расписание новых штатных единиц.
Разработка информационной системы деятельности службы
технической поддержки» и подрядчиками включает этапы:
- анализ бизнес-процессов деятельности службы технической
поддержки;
- определение перечня входных и выходных документов;
- анализ узких мест существующей технологии, определение задач
автоматизации;
- построение информационной модели в рамках поставленной задачи;
- выбор средств автоматизации, разработка информационной
системы;
- тестирование разработанной системы, доработка функционала при
обнаружении ошибок.