Дипломная работа: Разработка системы взаимодействия с клиентами SAAS-среды аренды сайтов

Предложенные ITIL рекомендации по организации процессного подхода и управления качеством предоставления услуг было принято использовать при проектировании системы, так как система является одной из эффективных, наиболее обобщенных и практичных из существующих. Существует 5 книг последней версии ITIL, каждая из которых направлена на определенную деятельность системы (Service Strategy, Service Design, Service Transition и т.д.). Основными концептами подхода являются: управление инцидентами, управление проблемами, управление изменениями, управление финансами и т.д. Книга «Planning to Implement Service Management» посвящена организации подхода к внедрению управления услугами компании. На основе передового опыта и зарекомендовавших себя практик были спроектированы модели бизнес-процессов ООО «ВЕБ ДЕПО» для работы с системой взаимодействия с клиентами.

Взаимодействие с клиентами организации было описано в нотации IDEF0 с учетом специфичных результатов анализа инфраструктуры предприятия. Бизнес-процесс «обработать заявку» (см. рис. 2.1) имеет три стрелки на входе, обозначающие три вида каналов связи с клиентом - были выделены основные каналы связи, по которым может быть зарегистрировано обращение - телефонный звонок, электронная почта, визит (личное обращение).

Рисунок 2.1. Обработка заявки

Стрелка управления показывает порядок обработки обращения клиента, что означает логику следования обращения клиента по трем уровням технической поддержки. Стрелки механизма показывает сотрудников, программное обеспечение (CRM-система). На выходе процесса получается обработанная заявка клиента, хранимая в базе данных обращений, и результат обращения клиента - следствие принятие мер по обработке заявки («тикета»).

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

Рисунок 2.2. Обработка заявки

Декомпозиция подпроцесса «принять обращение» более детально описывает принятие заявок от каналов связи и регистрации обращению (см. рис. 2.3).

Рисунок 2.3. Принятие заявки

Подпроцесс «обработать обращение» включает в себя прохождение уровней технической поддержки клиента (см. рис. 2.4). В зависимости от сложности обращения, «тикет» проходит каждый уровень поддержки и возвращается к предыдущему подпроцессу для проверки и принятия работы. Таким образом, заявка в любом случае возвращает к первому уровню поддержки взаимодействия с клиентом, затем готовится отчет о выполненной работе.

Рисунок 2.4. Обработка заявки

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

2.2 Проектирование базы данных обращений клиентов

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

Созданный проект базы данных включает в себя:

– название,

– имя клиента,

– организация,

– электронная почта,

– дата,

– контент (текст),

– статус.

Статус проекта определяет направляет заявку на нужный уровень поддержки клиентов (рис. 2.5), ускоряет обработку заявки. Пример категории: разработка, редактирование, дизайн, доработка (правка), одобрение и т.д.

Рисунок 2.5. Классификация обращений клиентов

Дата проекта необходима для расставления приоритетов при обработке заявок. Пример срочности проекта: несрочный, срочный.

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

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

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

Обращение - «тикет», поданный клиентом в обработку, фиксируемый в базе данных и отправляемый на дальнейшую обработку.

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

– Инфраструктура платформы, анализирующая и предоставляющая различные решения для приложения, позволяющие сконцентрироваться на разработке приложения;

– Платформа предоставляет серверную часть, созданную Google;

– Продукты платформы управляются единой консолью.

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

Занесение информации в базу данных происходит через стандартную форму CRM-системы как на примере (рис. 2.6).

Рисунок 2.6. Пример отображения обращения в CRM-системе

Необходим многопользовательский вход в систему (RBAC) для защиты информации и распределенного использования системой: клиент (свободный доступ), 1 уровень поддержки, 2 уровень поддержки, 3 уровень поддержки, менеджер (см. рис. 2.7).

Рисунок 2.7. Use Case диаграмма

Для наглядной реализации RBAC-модели доступа (Role Based Access Control) создана Use Case диаграмма, распределяющая функционал приложения между актерами в зависимости от их роли.

Возможности клиента:

– вход в систему,

– просмотр предыдущих обращений,

– создание нового обращения,

– принятие результатов обработки обращения.

Возможности 1 уровня поддержки:

– вход в систему,

– просмотр всех обращений клиентов,

– управление обращениями,

– связь с клиентом,

– создание отклика,

– редактирование статуса обращений,

– перенаправление обращения на другой уровень.

Возможности 2 уровня поддержки:

– вход в систему,

– просмотр всех обращений клиентов,

– перенаправление обращений на другой уровень.

Возможности 3 уровня поддержки:

– вход в систему,

– просмотр всех обращений клиентов,

– перенаправление обращений на другой уровень.

Возможности 2-го и 3-го уровня поддержки фактически включают в себя лишь просмотр обращения и отправление на дальнейшую обработку (2 уровень поддержки передает обращение 3-му уровню поддержки), либо для выполнения обращения (2 уровень поддержки передает обращение 1-му уровню поддержки), поскольку результатом обработки обращения является непосредственная работа.

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

Менеджер поддержки контролирует бизнес-процесс взаимодействия с клиентами.

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

Описание бизнес-процесса содержит 5 пулов: Клиент, Первый уровень, Второй уровень, Третий уровень, Руководство (см. Прил. A). Старт бизнес-процесса находится в пуле Клиента и продолжается подаче обращения организации. Первый уровень регистрирует обращение и заносит его в хранилище данных CRM-системы. Параллельно выполняются процессы уведомления клиента о регистрации обращения, получение уведомления и обработка обращения на Первом уровне (рис. 2.8).

Рисунок 2.8. Начало описания бизнес-процесса

Принимается решение о статусе тикета - если он выполнен, то тикет отмечается, как выполненный, если тикет требует более глубокой обработки, он передается на Второй уровень. Второй уровень аналогично принимает тикет, обрабатывает его и выносит решение о статусе тикета (см. рис. 2.9).

Рисунок 2.9. Описание бизнес-процесса. Второй уровень поддержки

Третий уровень принимает и обрабатывает тикет. В случае необходимости разработки, Третий уровень запрашивает ресурс у руководства и начинает разработку, в случае решения тикета без разработки, тикет передается обратно на Второй уровень, где принимается и вновь обрабатывается (рис. 2.10).

Рисунок 2.10. Описание бизнес-процесса. Третий уровень поддержки

Если Второй уровень признал тикет решенным, он передается на Первый уровень, где помечается, как выполненный. Подается уведомление Клиента о решении тикета, Клиент получает уведомление, и бизнес-процесс завершается (рис. 2.11).

Рисунок 2.11. Конец описания бизнес-процесса. Первый уровень поддержки

Описание бизнес-процесса проходит валидацию без ошибок, что говорит о корректном соединении компонентов нотации. Для анализа модели бизнес-процесса была проведена валидация процесса и временной анализ (см. табл. 2.1).

Результаты анализа были сделаны исходя из заранее заданных начальных данных:

– подача обращения - 30 минут,

– регистрация тикета - 1 минута,

– обработка тикета (1 ур.) - 1 день,

– обработка тикета (2 ур.) - 1 день 4 часа,

– обработка тикета (3 ур.) - 2 дня,

– уведомление о регистрации тикета (отправка) - 1 минута,

– уведомление о регистрации тикета (получение) - 10 минут,

– принятие решения о тикете (1 ур., 2 ур.) - 1час,

– принятие решения о тикете (3 ур.) - 1 день,

– принятие тикета - 10 минут,

– отправка тикета - 10 минут,

– предоставление ресурса для разработки - 1 день,

– разработка - 2 дня,

– I шлюз «Решен?»: 75% - да, 25% - нет,

– II шлюз «Решен?»: 80% - да, 20% - нет,

– III шлюз «Разработка?»: 10% - да, 90% - нет.

Таблица 2.1. Результаты симуляции модели бизнес-процесса