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

Оглавление

• Список терминов и сокращений
• Введение
• Глава 1. Основные сведения о разрабатываемой информационной системе
• 1.1 Взаимосвязь системы с информационными системами
• 1.2 Взаимосвязь системы с веб-порталами
• 1.3 Взаимосвязь разрабатываемого модуля с CRM системами
• Глава 2. Разработка CRM модуля приема и обработки заявок
• 2.1 Особенности разработки системы с точки зрения платформы MS Sharepoint 2010
• 2.1.1 Архитектура MS Sharepoint 2010
• 2.1.2 Основные возможности MS Sharepoint 2010, полезные для создания CRM модуля
• 2.1.3 Особенности разработки рассматриваемой системы
• 2.2 Описание бизнес-процессов CRM модуля
• 2.2.1 Модель технической поддержки "как есть"
• 2.2.2 Основные компоненты разрабатываемого CRM модуля
• 2.2.3 Описание бизнес-процессов CRM модуля
• 2.3 Основные требования к модулю приема и обработки заявок
• 2.4 Описание созданного решения
• 2.5 Экономическое описание решения
• Заключение
• Библиографический список
• Приложение А. Описание бизнес-процессов CRM модуля приема и обработки заявок
• Приложение Б. Техническое задание
• Приложение В. Исходные коды

Список терминов и сокращений

В работе встречаются следующие термины и сокращения, требующие разъяснения:

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

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

3. LMS - система управления обучением.

4. ИС - информационная система.

5. ARIS - методология проектирования бизнес-процессов.

Введение

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

Руководство пермского кампуса НИУ ВШЭ также всегда стремилось увеличить свои показатели, а именно - качество обучения студентов и работы преподавательского состава, предоставить им все возможности для комфортной деятельности в стенах университета. Именно поэтому происходит постоянное обновление технической аппаратуры кампусов, внедрение новых информационных систем, таких как LMS. Однако ряд проблем всё ещё остаётся актуальным для университета, и они могут быть решены путем внедрения новой информационной системы.

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

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

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

В контексте данной работы будет рассмотрен CRM модуль приема и обработки заявок пользователей с их техническими проблемами в пределах НИУ ВШЭ - Пермь с целью создания единой системы технической поддержки для учащихся и преподавателей.

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

Следует отметить, что аналогов такой системы для работы с учащимися не существует как в НИУ ВШЭ - Пермь, так и в других университетах города.

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

Объектом исследования является организация работы CRM систем.

Предметом исследования являются функциональные возможности MS Sharepoint 2010 для создания CRM модуля приема и обработки заявок.

Целью работы является проектирование и разработка CRM модуля приема и обработки заявок сотрудников и учащихся НИУ ВШЭ - Пермь как части системы технической поддержки ВУЗа.

Для достижения цели должны быть решены следующие задачи:

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

2. Изучение функциональных возможностей MS SharePoint 2010.

3. Уточнение требований к CRM модулю приема и обработки заявок.

4. Описание компонентов модуля и создание его схемы данных.

5. Создание моделей "как есть" для текущего процесса оказания технического обслуживания и "как должно быть" для разрабатываемого модуля в нотации ARIS.

6. Написание технического задания к разрабатываемому модулю.

7. Разработка модуля с использованием инструментов платформы MS Sharepoint 2010.

8. Создание описания решения и его программных компонентов.

9. Создание экономического описания разработанного решения.

Глава 1. Основные сведения о разрабатываемой информационной системе

Основная задача данной работы заключается в создании CRM модуля приема и обработки заявок как части информационной системы технической поддержки НИУ ВШЭ - Пермь. В сервис технической поддержки также входит модуль WfMS, ответственный за создание решений по проблемам пользователей. Описание проектирования и разработки данного модуля представлено в работе "Управление потоками работ вычислительного центра ВУЗа" [1].

В результате исследования, проведенного в 2013 году в рамках курсовой работы факультета бизнес-информатики, было обнаружено, что больше 60% студентов постоянно сталкиваются с различными проблемами при работе с учебными программами, и, помимо этого, сотрудники ВУЗа регулярно оставляют заявки на проведение различных внеплановых работ по техническому обслуживанию.

Решением данной проблемы может быть создание веб-портала с системой технической поддержки, в рамках которого будут функционировать две подсистемы: CRM и WfMS. Веб-портал было решено создавать на платформе MS Sharepoint 2010, так как данная платформа является лидирующей в области создания различных корпоративных сайтов.

В первую очередь необходимо подробнее изучить основные теоретические понятия работы. Таким образом, для создания веб-портала CRM модуля сервиса технической поддержки НИУ ВШЭ - Пермь необходимо четко понимать, что из себя представляют информационные системы, CRM системы и веб-порталы, а также сопоставить данные понятия с разрабатываемой системой.

1.1 Взаимосвязь системы с информационными системами

Организации различных типов: большие и малые, частные и некоммерческие, стали полагаться на информационные системы, которые повсеместно используются в различных ежедневных операциях, а также в процессах планирования и принятия решений. Эффективное использование информационных технологий стало основным фактором успеха в современном обществе. Так, в контексте данной работы будет рассмотрена система технического обслуживания студентов и преподавателей НИУ ВШЭ - Пермь, способная решать их технические проблемы в режиме реального времени, что обеспечивает увеличение эффективности учебного и рабочего процесса.

Система технической поддержки НИУ ВШЭ - Пермь разбивается на два модуля, ответственных за выполнение определенных задач. К этим модулям относятся: CRM модуль, ответственный за работу с клиентами, и WfMS модуль, занимающийся разработкой решения технических проблем пользователя. В контексте данной работы будет рассмотрена часть проектирования и разработки CRM модуля.

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

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

Признаки такой системы:

1. Элементы системы взаимосвязаны и взаимодействуют в рамках системы.

2. Каждый элемент системы может в свою очередь рассматриваться как самостоятельная система, но он выполняет только часть функций системы.

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

4. Подсистемы могут взаимодействовать как между собой, так и с внешней средой и изменять при этом свое содержание или внутреннее строение [4].

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

Успешное применение ИС требует понимания бизнеса и его внешней среды. Например, чтобы построить ИС, которая поддерживает заключение сделок на Нью-Йоркской фондовой бирже, необходимо понять процедуры, связанные с покупкой и продажей акций, облигаций, опционов, и так далее, а также учитывать то, как все они связаны государственными законами. Так, для успешного внедрения такой системы в НИУ ВШЭ - Пермь необходимо четко понимать все бизнес-процессы, протекающие внутри университета.

Также необходимо понимать разницу между компьютерами и информационными системами. Компьютеры, оснащенные специализированными программными средствами, являются технической базой и инструментом для информационных систем. Информационная система, в свою очередь, немыслима без персонала, взаимодействующего с компьютерами и телекоммуникациями. Так и сервис технической поддержки НИУ ВШЭ - Пермь обязательно требует наличия дежурных инженеров, ответственных за разработку решений и их предоставление пользователям в некоторых случаях.

Информационная система может быть определена с двух точек зрения: одна из них касается её функций, а другая относится к ее структуре. С функциональной точки зрения; информационная система является технологически реализованным средством записи, хранения и распространения языковых выражений, а также для поддержки вывода решений. Со структурной точки зрения; информационная система состоит из набора людей, процессов, данных, моделей, технологий и частично формализованного языка, образуя сплоченную структуру, которая служит некоторым организационным целям или функциям [5].

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

Таким образом, с функциональной точки зрения, сервис технической поддержки НИУ ВШЭ - Пермь будет определен через бизнес-процессы, протекающие внутри него и всего университета, данные бизнес-процессы рассмотрены в соответствующей главе. Структуру данной системы с точки зрения части CRM также можно посмотреть в этой главе на диаграмме ARIS.

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

Три операции в информационной системе производят информацию, которая необходима организациям для процессов принятия решений, управления, анализа проблем и создания новых продуктов или услуг. Этими операциями являются ввод данных, их обработка и вывод [3, 5, 6]. Блок ввода данных собирает исходные данные из организации или ее внешней среды. Блок обработки преобразует входную необработанную информацию в более значимую, содержательную форму. Блок вывода данных передает обработанную информацию людям, которые будут работать с ней, или другим операциям системы, в которых она будет использоваться. Информационные системы также требуют определенных операций по обеспечению обратной связи, предусматривающей вывод соответствующей информации о системе от пользователей к работникам компании с целью улучшения системы и устранения ошибок внутри неё. Взаимосвязь рассмотренных операций представлена на рисунке ниже:

Рисунок 1.1. Основные операции, протекающие в информационных системах

Все эти операции имеют место быть как для сервиса технической поддержки, так и отдельно для её CRM модуля. Рассмотрим вкратце выполнение данных операций внутри модуля.

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

Основные компоненты CRM модуля сервиса технической поддержки НИУ ВШЭ - Пермь представлены ниже:

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

2. Оборудование: физическое компьютерное оборудование, устройства связи, носители информации.

3. Программное обеспечение: необходимые для работы программы и процедуры.

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

5. Телекоммуникации: средства связи (веб-портал).

1.2 Взаимосвязь системы с веб-порталами

CRM модуль сервиса технической поддержки НИУ ВШЭ - Пермь представляет собой веб-портал, на котором пользователи могут оставлять заявки со своими техническими проблемами и следить за ходом их выполнения.

Для более точного определения необходимо подробней остановиться на определении, типах и назначении веб-порталов.

Веб-портал для пользователей - сайт в компьютерной сети, который предоставляет пользователю различные интерактивные сервисы, которые работают в рамках этого сайта, такие как поиск информации, чаты, блоги, новостные ленты и т.д. Веб-портал может состоять из нескольких сайтов, если они объединены под одним доменным именем [7, 8].

Также порталы функционируют как точки доступа к информации в Интернете или сайты, которые помогают пользователям в поиске нужной информации через Интернет. Такие порталы представляют информацию из различных источников в единообразном виде, их также называют навигационными сайтами [8].

По специализации информации порталы разделяют на горизонтальные и вертикальные.

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

Вертикальный портал - портал узкой тематической направленности, предоставляющий различные сервисы для пользователей сети по определенным интересам и ориентированный на полный охват тематики или области деятельности [7, 8].

По направленности на пользователя порталы разделяют на публичные и корпоративные.

Корпоративный портал - совокупность информационных систем и баз данных предприятия, организации или учреждения, представленных в сети Интернет. Корпоративный портал предоставляет сотрудникам компании (или её постоянным партнерам) строго персонифицированный вход в её автоматизированную систему управления (информационную систему подготовки принятия решений, экспертную систему, систему совместной работы, систему управления бизнес-процессами и т.д.) [7, 8].

Публичный портал - является диаметральной противоположностью корпоративного портала. Публичный портал предоставляет любому посетителю любую информацию и любые сервисы [7].

Таким образом, можно сказать, что веб-портал CRM модуля системы технической поддержки НИУ ВШЭ - Пермь будет являться корпоративным и вертикальным порталом, то есть он обладает узкой направленностью на техническое обслуживание пользователей и является точкой доступа лишь для учащихся и сотрудников университета.

1.3 Взаимосвязь разрабатываемого модуля с CRM системами

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

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

CRM - это процесс управления всеми видами взаимодействия компании со своими клиентами, включающий поиск новых клиентов, а также процессы продаж и обслуживания [9]. Приложения CRM предназначены для более глубокого понимания и улучшения взаимоотношений компаний с клиентами, объединив все возможные виды взаимодействия с клиентами воедино.

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

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

Таким образом, центром каждой CRM системы являются клиенты, и основная цель внедрения подобного рода систем включает максимизацию уровня их удовлетворенности и приверженности услугами и продуктами компании [10]. Программные продукты CRM решений предоставляют все необходимые инструменты для автоматизации управления взаимодействием с клиентами. Однако следует понимать, что CRM система не является просто программой, ведь даже наиболее крупные системы являются лишь отдельными элементами в процессах, направленных на удержание старых клиентов и поиск новых.

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

Система обслуживания клиентов позволяет компаниям управлять операциями по обслуживанию, независимо от того, осуществляются ли они через телефонные информационные центры, контактные центры, посредством веб-портала или при личном контакте работника с клиентом. Такие CRM системы позволяют компаниям обрабатывать входящие и исходящие сообщения по предоставлению услуг по всем возможным каналам взаимодействия с клиентом. Данный тип систем позволяет компаниям увеличить эффективность работы за счёт снижения затрат на обслуживание, улучшение качества обслуживания, увеличения производительности труда и повышения удовлетворенности клиентов [11].

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

В условиях работы с большим количеством технологического оборудования компании и технических проблем, связанных с его использованием, организация работы системы обслуживания является иной. Как правило, она включает в себя операции по определению и решению проблем, которые должны быть проведены по месту нахождения оборудования. В этих случаях, система обслуживания может предусматривать наличие сервисного специалиста, которому предоставляется информация о проблеме, руководство по ремонту и другая полезная информация по оборудованию [12].

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

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

1. Сбор информации о технических проблемах пользователей через веб-портал.

2. Предоставление пользователям решений по их техническим проблемам.

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

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

Глава 2. Разработка CRM модуля приема и обработки заявок

2.1 Особенности разработки системы с точки зрения платформы MS Sharepoint 2010

Основная задача данной работы состоит в проектировании и разработке веб-портала CRM модуля системы технической поддержки НИУ ВШЭ - Пермь, поэтому важным аспектом работы является выбор средства разработки данного портала. В качестве такого средства был выбран инструмент MS Sharepoint 2010, который позволяет создавать корпоративные порталы и организовывать на них рабочие процессы различной сложности в зависимости от протекающих в системе бизнес-процессов.

В общем Microsoft Sharepoint 2010 может быть использован для создания сайтов, предоставляющих пользователям возможность для совместной работы. Создаваемые на платформе Sharepoint сайты могут быть использованы в качестве хранилища различной информации, документов, а также как вики страницы или блоги.

2.1.1 Архитектура MS Sharepoint 2010

Иерархия решений на SharePoint выглядит следующим образом (см. рис. 2.1 [13]):

Рисунок 2.1. Иерархия решения в среде MS Sharepoint 2010

1. 1. Ферма серверов - элемент верхнего уровня логической архитектуры. По размерам делятся на малые (2 веб-сервера и сервер баз данных), средние (2 веб-сервера, 2 сервера приложений и несколько серверов баз данных) и крупные. По топологии - одноуровневые (SharePoint и сервер баз данных на одном компьютере), двухуровневые (SharePoint и сервер баз данных на разных серверах) и трехуровневые (веб-серверы, серверы приложений и сервера баз данных на разных уровнях).

2. Веб-приложение - вебсайт служб IIS, который используется SharePoint.

3. Семейство сайтов - набор вебсайтов с одним владельцем и общими параметрами администрирования.

4. Сайт - одна или несколько связанных веб-страниц и других элементов, которые хранятся внутри семейства сайтов.

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

6. Библиотека - частный вид списка для хранения документов [13].

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

2.1.2 Основные возможности MS Sharepoint 2010, полезные для создания CRM модуля

Рассмотрим возможности Sharepoint 2010, которые используются для реализации CRM модуля системы технической поддержки университета.

Данная среда предоставляет возможности для решения следующих задач:

1. Автоматизация бизнес-процессов.

2. Совместная работа.

3. Дополнительные разработки.

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

Автоматизация бизнес-процессов

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

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

Совместная работа

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

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

Дополнительные разработки

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

2.1.3 Особенности разработки рассматриваемой системы

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

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

· Завершенные заявки.

· Актуальные заявки.

· Многоразовые заявки.

· Заявки текущего пользователя.

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

2.2 Описание бизнес-процессов CRM модуля

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

2.2.1 Модель технической поддержки "как есть"

Как уже было отмечено в начале работы, в НИУ ВШЭ - Пермь на сегодняшний момент существует определенный протокол действий по обеспечению технической поддержки студентов и сотрудников университета, который представлен на рисунке ниже:

Рисунок 2.2. Модель технического обслуживания "как есть"

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

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

Далее будет рассмотрена модель разрабатываемого CRM модуля приема и обработки заявок пользователей.

2.2.2 Основные компоненты разрабатываемого CRM модуля

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

1. Пользователь - студент или сотрудник НИУ ВШЭ - Пермь, направляющий заявку со своей проблемой системе.

2. Дежурный инженер - работник сервиса технической поддержки НИУ ВШЭ - Пермь, отвечающий за работу с клиентом. Его основной задачей в рамках рассматриваемого модуля является выявление дублирующих заявок и составление списка многоразовых заявок.

Эти агенты будут взаимодействовать с различными модулями системы в той или иной степени.

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

Заявка может находиться в следующих состояниях:

· Активная - по данной заявке выполняется работа.

· Дублирующая - такая заявка уже есть в "активных", обработка по ней не ведется, но решение предоставляется её инициатору после того, как оно будет готово для другой такой же заявки.

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

· Завершенная - работа по заявке завершена, решение по проблеме предоставлено пользователю, сама заявка помещается в архив портала.

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

· Одноразовые - вводятся пользователем самостоятельно на соответствующей странице портала.

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

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

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

Она связана с CRM модулем через общую папку в сети Интернет, представляющую собой библиотеку документов Sharepoint, куда из CRM модуля после добавления пользователем одноразовой заявки поступает текстовый файл с описанием проблемы пользователя, по которой в базе данных производится поиск возможного решения. Результаты поиска после этого отправляются в виде текстового файла в общую папку. При разработке нового решения WfMS модулем, данное решение вместе с соответствующей технической проблемой также заносятся в базу данных через интерфейс общей папки.

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

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

· "0 | Идентификатор заявки | Описание технической проблемы".

· "1 | Описание технической проблемы пользователя | Решение технической проблемы пользователя | 0 или 1".

Первая цифра определяет операцию, которую база данных должна будет выполнить. То есть, "0" подразумевает операцию поиска возможного решения по проблеме, а "1" - добавление новой записи в базу данных. При этом, в первом случае файл будет называться "Search" + "Идентификатор заявки", а во втором - "AddToDB" + "Идентификатор заявки". Во втором случае последним элементом строки файла может быть либо "0" либо "1", "0" означает, что для данного решения требуется участие дежурного инженера, а "1" - что оно не требуется.

База данных после проведения операции поиска возможного решения может передавать в общую файлы следующего содержания:

· "Идентификатор заявки | 1".

· "Идентификатор заявки | 0 | 0 или 1 | Решение технической проблемы пользователя".

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

В контексте разрабатываемого CRM модуля приема и обработки заявок хранение и организация данных в самой системе осуществляются средствами списков MS Sharepoint. Таким образом, структура данных была спроектирована и нормализована до третьей нормальной формы, после чего все списки Sharepoint создавались на её основе. Структура данных представлена на рисунке ниже, красным цветом на ней выделены компоненты, относящиеся к CRM модулю:

Рисунок 2.3. Структура данных системы

Так, основным списком CRM модуля, в рамках которого происходит обработка пользовательских данных, является список заявок. Списки задач, ресурсов и назначений являются списками WfMS модуля, который не рассматривается в рамках данной работы и отвечает за разработку решений технических проблем пользователя.

На рисунке ниже представлена укрупненная структура данных CRM модуля:

Рисунок 2.4. Укрупненная структура данных CRM модуля

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

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

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

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

Рисунок 2.5. Схема разрабатываемого портала

Так, из схемы видно, что конкретно к CRM модулю приема и обработки заявок относится список заявок и библиотека документов, представляющая собой общую папку в сети Интернет. При этом общий список модулей доступен обоим модулям системы и обеспечивает их взаимодействие. Внешняя база данных не входит напрямую в интерфейс портала, при этом она является внешним компонентом CRM модуля приема и обработки заявок. При этом программное расширение Sharepoint, обеспечивающее взаимодействие с базой данных, является обработчиком событий, созданным в среде Visual Studio на языке C#. Подробно разработанные компоненты системы рассмотрены в разделе 2.4 "Описание решения".

Рассмотренная информация по компонентам системы и типам заявок представлена на диаграмме прецедентов на рисунке ниже:

Рисунок 2.6. Диаграмма прецедентов

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

2.2.3 Описание бизнес-процессов CRM модуля

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

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

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

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

4. Завершение работы по заявке - если заявка является одноразовой, то её решение фиксируется во внешней базе данных CRM модуля для дальнейшего возможного использования. Все заявки при этом помещается в архив портала, также клиенту предлагается оценить работу системы обслуживания. Если заявка клиента была размещена на главной странице портала, то она удаляется.

Бизнес-процессы модуля приема и обработки заявок можно посмотреть на диаграммах в нотации ARIS в приложении А. На рисунке А.1 в приложении А представлен процесс работы системы по одной заявке, включающий различные входные и выходные параметры, а также различных агентов, участвующих в процессе работы CRM модуля.

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

Рассмотрим детально основные процессы, описанные в системе.

1. Прием заявки (см. рис. А.2 в приложении А).

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

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

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

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

Все периодические заявки выполняются в соответствии с временным промежутком, указанным пользователем (день, неделя, месяц, квартал, полугодие).

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

2. Подготовка решения по заявке (см. рис. А.3 в приложении А).

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

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

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

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

3. Предоставление решения (см. рис. А.4 в приложении А).

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

В данном случае пользователю высылается уведомление о том, что по его заявке было подготовлено решение. Если решение не требует участия дежурного инженера, то оно высылается пользователю, а если участие требуется, то в модуль WfMS отправляется уведомление о выделении дежурного инженера на задачу. После этого пользователь должен указать помогло ли ему данное решение, если нет, то заявка вновь пересылается в WfMS модуль для разработки нового решения, если да, то выполняется процесс завершения работы по заявке.

4. Завершение работы по заявке (см. рис. А.5 в приложении А).

Входными данными является решенная заявка пользователя, выходными - завершение работы системы по заявке.

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

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

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

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

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

2.3 Основные требования к модулю приема и обработки заявок

управление алгоритмизация клиент заявка

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

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

Система представляет собой веб-портал, созданный в среде MS Sharepoint 2010. Модуль предназначен для автоматизации получения и обработки заявок пользователей с их техническими проблемами. Пользователями данной системы являются студенты и сотрудники НИУ ВШЭ - Пермь.

Для осуществления взаимодействия CRM и WfMS модулей системы технической поддержки НИУ ВШЭ - Пермь, необходимо, чтобы они были реализованы в пределах одной фермы MS Sharepoint 2010 с использованием программных доработок на языках С# и Javascript.

Взаимодействие CRM и WfMS модулей осуществляется через общий список, куда первый модуль заносит данные о проблеме, а второй - о конечном решении технической проблемы.

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

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

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

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

...