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

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования
«Национальный исследовательский университет
«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

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

Ткаченко Фёдор Игоревич

Пермь, 2018 год



• Содержание
• Глава 1. Анализ предметной области
• 1.1. Анализ ИТ-инфраструктуры организации
• 1.2. Анализ существующих систем взаимодействия с клиентами
• Глава 2. Проектирование системы взаимодействия с клиентами
• 2.1. Моделирование бизнес-процессов взаимодействия с клиентами
• 2.2. Проектирование базы данных обращений клиентов
• 2.3. Проектирование системы взаимодействия с клиентами
• 2.4. Проектирования интерфейса системы взаимодействия с клиентами
• Глава 3. Разработка системы взаимодействия с клиентами
• 3.1. Требования к разработке системы взаимодействия с клиентами
• 3.2. Ограничения технологий разработки
• 3.3. Разработка базы данных
• 3.4. Разработка интерфейса системы взаимодействия с клиентами
• 3.5. Развертывание системы взаимодействия с клиентами
• Заключение
• Библиографический список
• Приложение
• информационный технический клиент

• Введение

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

Системы взаимодействия с клиентами являются неотъемлемой частью бизнеса на протяжении нескольких лет: по результатам анализа Gartner в 2012 году рынок CRM-систем оценили в $18 миллиардов долларов. Потребность во внедрении этой системы в бизнес объясняется возможностью улучшить качество обслуживания клиентов. Актуальность данной работы определена потребностью ООО «ВЕБ ДЕПО» в разработке собственной системы взаимодействия с клиентами.

Объектом работы является деятельность компании ООО «ВЕБ ДЕПО".

Предмет исследование - автоматизация взаимодействия организации с клиентами SaaS-среды аренды сайтов.

Цель работы - разработка системы взаимодействия с клиентами SaaS-среды аренды сайтов.

Для достижения поставленной цели выделено несколько задач:

1. Ознакомиться с организационной структурой компании, ее сферами деятельности, материально- технической базой.

2. Проанализировать ИТ-инфраструктуру ООО «ВЕБ ДЕПО».

3. Проанализировать предметную область СRM-систем.

4. Проектировать систему взаимодействия с клиентами.

5. Разработать систему взаимодействия с клиентами.



Глава 1. Анализ предметной области

1.1 Анализ ИТ-инфраструктуры организации

Организация ООО «ВЕБ ДЕПО» занимается предоставлением различных услуг:

– услуги хостинга,

– контент-менеджмент,

– дизайн,

– веб-разработка.

Основным направлением является обеспечение сетевого доступа к вычислительным ресурсам по требованию, то есть облачные вычисления (англ. «cloud computing»). Облачные вычисления предполагают три разновидности моделей обслуживания:

– IaaS - представление облачной инфраструктуры для самостоятельного управления как услуги;

– PaaS - представление облачной инфраструктуры для размещения программного обеспечения;

– SaaS - предоставление возможности использования программного обеспечения, размещенного в облачной инфраструктуре провайдера.

Основным направлением работы организации является - IaaS.

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

При взаимодействии с клиентами организация использует трехуровневую техническую поддержку:

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

– Второй уровень не контактирует с клиентом и обрабатывает вопросы и проблемы, нерешенные первым уровнем поддержки;

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

Обращение клиента фиксируется в интегрированной системе взаимодействия с клиентами. Недостаточный уровень автоматизации системы и общая неудовлетворенность от работы системы повлияли на решение организации о создании собственной CRM - системы.

1.2 Анализ существующих систем взаимодействия с клиентами

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

– Наличие единого хранилища информации, куда собираются сведения о взаимодействии с клиентами -- клиентской базы.

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

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

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

Детальное рассмотрение внутреннего устройства, функционала и интерфейса подобных систем предполагает проведение анализа существующих систем взаимодействия с клиентами и нахождение критериев для их сравнения (см. табл. 1.1).

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

– 1C CRM - один из продуктов наиболее известной компании на Российском рынке. Продукты данной компании отличаются широким функционалом и надежностью.

– Bitrix 24 CRM - продукт компании, специализированной на разработке систем управления веб-проектами и корпоративных порталов.

– Amo CRM - наиболее яркий представитель систем для начинающих пользователей.

В качестве критериев были определены:

– Ведение сделки - алгоритмизация сделки и поэтапное выполнение;

– Телефония - обработка обращений по телефонной связи;

– Автоматизация бизнес-процессов - возможность автоматизировать бизнес-процессы организации;

– Планирование - маркетинговая составляющая системы;

– Email - качество работы с сервисами электронной почты;

– Настройка интерфейса - возможной персональной конфигурации программного обеспечения;

– Отчетность - качество предоставления отчета по работе системы;

– Доработка - возможность дополнительной разработки, расширения программного обеспечения;

– Сложность - трудности освоения программного обеспечения.

Таблица 1.1. Сравнение CRM-систем

	1C CRM	Bitrix 24 CRM	Amo CRM
Ведение сделки	+	++	+
Телефония	++	+	+
Автоматизация БП	+	+++	-
Планирование	+++	+++	+
Email	++	+	+
Настройка интерфейса	+	+	+
Отчетность	+++	+	+
Доработка	+++	+	+
Сложность	Низкая	Высокая	Низкая

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

Показатели сравнения Bitrix24 CRM свидетельствуют об акценте системы на работу с бизнес-процессами компании, их автоматизация и планирование, так как производитель направлен на ведение корпоративных порталов.

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

На основе проведенного анализа выявлены важнейшие качества актуальных CRM-систем:

– единая безопасная база данных;

– охват большого количество каналов связи клиентов с организацией;

– корпоративные коммуникации без информационных провалов;

– получение аналитических отчетов;

– ведение маркетинговых кампаний, отслеживание и контроль за выплатами, доставками и т.д.;

– возможность конфигурации системы;

– накопление всей информации о клиенте, сделках, рекламных кампаниях, ее защита и инструменты управления.

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



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

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

Для проектирования бизнес-процессов и логики системы взаимодействия с клиентами изучена документация ITIL (IT Infrastructure Library). Библиотека, хранящая в себе лучшие примеры и практики по предоставлению услуг, организации рабочей деятельности, управлению информацией и дизайну бизнес-процессов, была изобретена в Великобритании в 1980-х годах и обрела популярность, объединив представителей ИТ-сервисов единой целью и стратегией развития компании. Данная библиотека описывает весь набор процессов, необходимых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей. Процессный подход, взятый за основу документации, акцентирует внимание компании на поставленных целях. Эта библиотека является ветвью ITSM (IT Service Management) для систематизации ИТ-услуг. Подход управления ИТ-услугами централизует нужды клиента и обращает все услуги и развитие компании и ее бизнес-процессов в сторону удовлетворения потребностей клиента, создавай условия для непрерывного улучшения - анализа деятельности компании, развития и закрепления успехов

Предложенные 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. Результаты симуляции модели бизнес-процесса

Name	Type	Instances completed	Instances started	Min. time (d)	Max. time (d)	Total time (d)
Обработка заявки	Process	28	31	1,077777778	6,577777778	51,34583333
NoneStart	Start event	31
Подача обращения	Task	30	31	0,020833333	0,020833333	0,625
Регистрация тикета	Task	30	30	0,000694444	0,000694444	0,020833333
Уведомление о регистрации	Task	30	30	0,000694444	0,000694444	0,020833333
Обработка тикета	Task	29	30	1	1	29
Получение уведомления	Task	30	30	0,006944444	0,006944444	0,208333333
Решен?	Gateway	38	38
Обработка тикета	Task	11	12	1,166666667	1,166666667	12,83333333
Решен?	Gateway	11	11
Обработка тикета	Task	2	2	2	2	4
Разработка?	Gateway	2	2
Предоставление ресурса	Task	0	0	0	0	0
Отправка уведомления о решенном тикете	Task	28	28	0,000694444	0,000694444	0,019444444
Получение уведомления	Task	28	28	0,006944444	0,006944444	0,194444444
NoneEnd	End event	28
Принятие тикета	Task	2	2	0,006944444	0,006944444	0,013888889
Передача тикета	Task	2	2	0,006944444	0,006944444	0,013888889
Передача тикета	Task	9	9	0,006944444	0,006944444	0,0625
Разработка	Task	0	0	0	0	0
Решение тикета	Task	2	2	1	1	2
Принятие решения	Task	11	11	0,041666667	0,041666667	0,458333333
Принятие тикета	Task	12	12	0,006944444	0,006944444	0,083333333
Принятие решения	Task	38	38	0,041666667	0,041666667	1,583333333
Передача тикета	Task	2	2	0,006944444	0,006944444	0,013888889
Отметить выполненный тикет	Task	28	28	0,006944444	0,006944444	0,194444444

Результаты анализа:

Можно заметить перегрузку токенов на Втором уровне поддержки, и, в меньше мере, на Первом уровне поддержки, из-за петли потоков управления.

Каскадные потоки управления обусловлены специфичной структурой отдела взаимодействия с клиентами.

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

Минимальное время, затраченное на выполнение одного обращения, составляет 1.07 дня.

Максимальное время, затраченное на выполнение одного обращения, составляет 6,57 дня.



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

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

Требования к интерфейсу:

– Раздельный вход в систему,

– Общее хранилище обращений,

– Просмотр информации об обращении (ссылки),

– Возможность подачи обращения.

Индивидуальные требования для каждого пользователя системы изложены как возможности пользователя в моделировании системы взаимодействия с клиентами (см. гл. 2.2). Для проектирования интерфейса системы было решено следовать новейшим практикам создания прогрессивных веб-приложений (PWA - Google). В данную методику входят общие стандарты создания приложений нового поколения:

– доступность всех компонентов приложения пользователю,

– представление приложения после загрузки,

– наличие манифеста приложения,

– наличие полных метаданных приложения,

– необходимый стек технологий.

Дизайн интерфейса - Material Design (унифицированная система, содержащая инструменты, накопленный опыт, ресурсы для создания дизайна). Система, впервые представленная Google в 2014 году, является материалистичным подходом к представлению приложений. Пользователями данной системы являются Google, YouTube, ВКонтакте и т.д.

Модель, полученная в ходе проектирования системы, содержит в себе

– описание бизнес-процесса,

– симуляцию работы системы,

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



Глава 3. Разработка системы взаимодействия с клиентами

Создание современного и прогрессивного веб-приложения стандартизировано и включает в себя определенный стек технологий по версии PWA: HTML, CSS, JS. Приложение, соединенное с данными, должно иметь непрерывный контакт для получения, редактирования, отправки информации, таким образом, для разработки приложения использован JS-фреймворк Angular 5.2, позволяющий создать одностраничное приложение (SPA), не нарушая контакт с данными. Интегрированная среда разработки - Visual Studio Code. Вспомогательный инструмент - Google Dev Tools + Lighthouse. Для реализации спроектированного пользовательского интерфейса и использования системы Material Design. Были подключены пакеты анимации и дизайна (Angular Material, Angular Animations, HammerJS, Bootstrap CDN). Доступ к данным осуществляется с использованием библиотеки AngularFire2, способствующая совместной работе Firebase и Angular приложений.

3.1 Требования к разработке системы взаимодействия с клиентами

– NPM Package 3.10.8

– Angular CLI 1.7.3

– Angular 5.2.10

– Angular Material Package

– Angular Animations Package

– HammerJS

– AngularFire2 (Официальная библиотека для Angular и Firebase)

– Bootstrap CDN (CSS-фреймворк)

Разработка данного веб-приложения требует навыков работы с консольным клиентом, знания HTML, CSS, JavaScript, TypeScript.

3.1. Ограничения технологий разработки

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

Таблица 3.1. Ограничения бесплатного аккаунта Firebase

Объем облачного хранилища	1 Гб
Пропускная способность	10 Гб/месяц
Количество записей документов	20000
Количество чтений документов	50000
Количество удалений документов	20000
Доступ к продуктам платформы	Только бесплатные продукты

Ограничения Angular связаны с некорректным отображением в некоторых версиях браузеров. Несмотря на современную сбору фреймворка, она включает в себя большое количество полифиллов (web polyfills), помогающих корректному отображению в старых версиях браузеров (табл. 3.2).

Таблица 3.2. Поддержка браузеров Angular 5.2.10

Браузер	Поддерживаемая версия
Chrome	Последняя версия
Firefox	Последняя версия
Edge	2 последние версии
IE	11, 10, 9
IE Mobile	11
Safari	2 последние версии
iOS	2 последние версии
Android	Nougat (7.0), Marshmallow (6.0), Lollipop (5.0, 5.1), KitKat (4.4)



3.2 Разработка базы данных

Платформа Firebase оптимизирует процесс создания хранилища данных. Для отдельного приложение создается уникальный проект, который позволяет пользователю использовать любой из доступных продуктов, соединив приложение с продуктом API ключом. В проекте создается облачное хранилище, устанавливающие права записи и чтения данных. Облачное хранилище содержит в себе коллекции документов (экземпляров), которые состоят из полей определенных типов. Каждый документ имеет уникальный идентификатор, генерируемый автоматически при записи в коллекцию. Таким образом проект базы данных принимает данную структуру (рис. 3.1). Для соединения проекта платформы с веб-приложением необходимо создать конфигурацию, содержащую следующие элементы:

1. API ключ;

2. Домен проекта;

3. URL базы данных;

4. Идентификатор проекта;

5. Уникальный идентификатор отправителя;

6. Объектное хранилище.

Конфигурация уникальна для каждого проекта. Набор этих элементов является параметрами функции инициализации Firebase модуля внутри приложения.



Рисунок 3.1. Структуры данных.

3.3 Разработка интерфейса системы взаимодействия с клиентами

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

Добавляется маршрутизирующий модуль, импортирующий компоненты приложения, участвующие в маршрутизации и навигации. Модуль импортирует RouterModule и Routes для создания элемента класса Routes, включающего в себя пути маршрутизации к определенным компонентам - каждый путь может содержать ссылку, компонент, защитный компонент. Для программной навигации требуется импорт RouterModule и Router для создания элемента класса Router для выполнения навигации компонента по URL. Для настройки внешних характеристик интерфейса, подключается Material Design Package. В приложении создается дополнительный модуль, импортирующий отдельные блоки из библиотеки, соединенный с основным модулем приложения (см. прил. B). Взаимодействие с приложением строится по модели RBAC, которая предполагает разный функционал пользователей в зависимости от их роли в жизненном цикле приложения. В корневом каталоге создаются каталоги, группирующие компоненты приложения по RBAC-модели: Пользователь, Первый уровень поддержки, Второй уровень поддержки, Третий уровень поддержки (user, first, second, third). Также создаются каталоги для сервисов(services) и защитных компонентов (guards). Для каждого из уровней поддержки нужен отдельный сервис и защитный компонент. Сервис представляет из себя класс с набором get-/set-функций, устанавливающих и определяющих авторизацию определенного пользователя. Защитный компонент открывает доступ к определенному компоненту в маршрутизаторе функцией canActivate(), возвращающей двоичной значение авторизации пользователя. С помощью данной связи сервиса и защитного компонента была реализована система авторизации пользователей (сотрудников организации). Защитные компоненты устанавливаются в маршруты защищенных компонентов сотрудников службы поддержки, являясь провайдерами основного модуля приложения. Для удобства предоставления ссылок маршрутизатора, создаются компоненты навигационного меню и футера в отдельном каталоге (elements). Навигационное меню содержит ссылки маршрутов, отображающие выбранные компоненты в выводе маршрутизатора (router outlet). Таким образом, получается промежуточная структура приложения.

Рисунок 3.2. Структура приложения

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

Создается компонент домашней страницы, на которой размещены кнопки, позволяющие осуществить переход к действующим компонентам. Домашняя страница имеет пустую ссылку в маршрутизаторе, поэтому является стартовым «видом» при запуске приложения. Вид домашней страницы, содержит компоненты навигационного меню, футера, главного компонента с описанием приложения. Кнопка «+» является проводником в компоненту, позволяющему создавать тикеты клиентам (рис. 3.3). Кнопка доступ является проводником к компоненту авторизации.

Рисунок 3.3. Домашняя страница приложения



Компонент авторизации (см. рис. 3.4) пользователей содержит функцию авторизации в файле TypeScript (см. рис. 3.5). Функция использует элементы классов, импортируемые из сервисов каждого вида пользователей, функции сервисов по определению авторизованного пользователя. В случае совпадения вводимых в форму данных, происходит навигация к определенному компоненту, доступ к которому имеет лишь данный вид пользователей. Инициация функции происходит с момента отправки данных с формы, которые передаются как параметры функции.

Рисунок 3.4. Клиентские компоненты

Рисунок 3.5. Функция авторизации



Компонент авторизации далее направляет пользователя к специальным компонентам, зависящим от роли пользователя.

Для представления данных, находящихся в коллекциях Firebase, компоненты, предоставляющие эти данные, должны импортировать модули платформы, описать поля класса тикета (наименование, описание, электронная почта, суть тикета и т.д.). Также в процессе предоставления данных принимает участие метод map() класса Observable, совершающий обработку полученных от сервера Firebase результатов. Описываются элементы коллекции и документов Firebase, с помощью которых происходит запись и чтение информации в функциях. Функция добавления тикета вызывается событием заполнения формы, и направляет результат отправки данных формы в коллекцию данных. Функции предоставления и удаления документа содержат идентификатор документа как параметр. Подобные функции, имеющие доступ к разным коллекциям данных, реализованы в компонентах трех уровней службы поддержки с некоторыми ограничениями (рис. 3.6).

Рисунок 3.6. Модуль маршрутизации

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

Второй уровень поддержки имеет доступ к коллекции тикетов второго уровня поддержки (создание, чтение, удаление) и возможность создания тикета для коллекции тикетов третьего уровня поддержки (передача тикета следующему уровню). Представление тикетов, как и в первом уровне поддержки, реализовано с помощью расширяющейся панели (Material Design) (см. прил. D).

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

3.2. Развертывание системы взаимодействия с клиентами

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

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

Манифест представляет с собой JSON файл с описанием приложения. Файл, который необходим для каждого Веб-расширения (WebExtension). Определяются имя, версия приложения, а также некоторые скрипты. Наличие манифеста поднимает рейтинг приложения в оценке Google Dev Tools и помогает корректному отображению приложения.

После публикации приложения произведена оценка Google Dev Tools, показавшая следующие результаты (см. рис. 3.7).



Рисунок 3.7. Оценка приложения Lighthouse (Google Dev Tools)

Приложение не завершено, поэтому не произведены завершающие процедуры развертывания приложения (добавление скрипта для офлайн доступа к данным, минимизация текста CSS и HTML).



Заключение

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

Полученное приложение нацелено на реализацию понятия Прогрессивного Веб-Приложения (PWA) и выполнено с соблюдением современных практик создания приложений от Google. Приложение было тестировано с помощью расширения Lighthouse, входящего в ряд Инструментов Разработчика Google (Google Dev Tools).



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

1. Knorr, E. (2017). Five big questions about cloud computing. InfoWorld. URL: https://www.infoworld.com/article/2628968/cloud-computing/five-big-questions-about-cloud-computing.html [Дата обращения: 2 декабря 2017].

2. Oliver, A. (2017). What makes for a good software developer. InfoWorld. URL: https://www.infoworld.com/article/3214481/application-development/the-good-software-development-manifesto.html [Дата обращения: 8 декабря 2017].

3. Steinberg, R. (2017). Getting a head start on ITIL. [online] InfoWorld. URL: https://www.infoworld.com/article/2658775/techology-business/getting-a-head-start-on-itil.html [Дата обращения: 8 декабря 2017].

4. Tcherevik, D. (2017). What does the future hold for business applications?. InfoWorld. URL: https://www.infoworld.com/article/3239526/technology-business/what-does-the-future-hold-for-business-applications.html [Дата обращения: 13 декабря 2017].

5. Weiss, T. (2017). Is your CRM system meeting your enterprise's needs?. InfoWorld. URL: https://www.infoworld.com/article/2622394/crm/is-your-crm-system-meeting-your-enterprise-s-needs-.html [Дата обращения: 11 декабря 2017].

6. Kempter, S. (2011). ITIL CSI - Continual Service Improvement. IT Service Management | ITIL 2011 processes. URL: https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement [Дата обращения: 21 января 2018].

7. Orr, A., Blokkum, D., Turbitt, K., Frederieke, C.M, Prins, W. (2011). Best Practice Insights. Focus On: ITIL® Service Design For ITIL 2011. [Дата обращения: 5 января 2018].

8. Сорока, Е. Г. (2014). К вопросу о внедрении концепции ITIL/ITSM в Российской it- отрасли // Вестник СИБИТа. №4 (12). URL: http://cyberleninka.ru/article/n/k-voprosu-o-vnedrenii-kontseptsii-itil-itsm-v-rossiyskoy-it-otrasli [Дата обращения: 10 февраля 2018]. 

9. Титов, С. В. (2011) Этапы внедрения CRM-системы на предприятии // ТДР. №10. URL: http://cyberleninka.ru/article/n/etapy-vnedreniya-crm-sistemy-na-predpriyatii [Дата обращения: 1 февраля 2018].



Приложение А

Обработка заказа



Приложение B

Material Module

import { NgModule } from '@angular/core';

import { CommonModule } from '@angular/common';

import {MatToolbarModule} from '@angular/material/toolbar';

import {MatFormFieldModule} from '@angular/material/form-field';

import {MatInputModule} from '@angular/material/input';

import {MatCardModule} from '@angular/material/card';

import {MatButtonModule} from '@angular/material/button';

import {MatMenuModule} from '@angular/material/menu';

import {MatIconModule} from '@angular/material/icon';

import {MatListModule} from '@angular/material/list';

import {MatExpansionModule} from '@angular/material/expansion';

import {MatProgressSpinnerModule} from '@angular/material/progress-spinner';

import {MatTabsModule} from '@angular/material/tabs';

@NgModule({

imports: [

CommonModule,

MatToolbarModule,

MatFormFieldModule,

MatInputModule,

MatCardModule,

MatButtonModule,

MatMenuModule,

MatIconModule,

MatListModule,

MatExpansionModule,

MatProgressSpinnerModule,

MatTabsModule

],

exports: [

MatToolbarModule,

MatFormFieldModule,

MatInputModule,

MatCardModule,

MatButtonModule,

MatMenuModule,

MatIconModule,

MatListModule,

MatExpansionModule,

MatProgressSpinnerModule,

MatTabsModule

],

declarations: []

})

export class MaterialModule { }



Приложение C

Компоненты первого уровня поддержки



Приложение D

Компоненты второго уровня поддержки



Приложение E

Компонент третьего уровня поддержки

Размещено на Allbest.ru