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

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

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

Введение

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

· осуществляется учебная, научно-исследовательская, общественная и административная деятельность;

· имеются в наличии соответствующие элементы корпоративной информационной системы.

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

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

НИУ ВШЭ _ Пермь, в силу ряда причин, не имеет автоматизированной системы управления обслуживающими видами деятельности компьютерного центра. При нарастающем объеме нагрузки, есть риски снижения управляемости не только этим структурным подразделением, но и риски нарушения непрерывности бизнес-процессов в целом. В целях обеспечения технического обслуживания студентов и сотрудников университета создан сервис технической поддержки, включающей в себя модуль Customer Relationship Management и Workflow Management System.

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

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

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

Целью исследования является проектирование и разработка WfMS для пермского кампуса НИУ ВШЭ.

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

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

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

1. Изучить теоретический материал, необходимый для проектирования и разработки WfMS.

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

3. Изучить функциональные особенности MS SharePoint 2010.

4. Разработать техническое задание для WfMS.

5. Разработать модели основных бизнес-процессов WfMS.

6. Спроектировать схему данных WfMS.

7. Разработать WfMS.

1. Использование автоматизированных систем в службах технического обслуживания

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

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

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

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

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

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

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

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

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

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

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

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

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

Таким образом, решение о разработке и внедрении системы технической поддержки в пермском кампусе НИУ ВШЭ может быть обусловлено несколькими факторами:

· неоптимальное распределение ресурсов КЦ университета при выполнении задач по заявкам;

· возможность оптимизации некоторых из существующих процессов КЦ;

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

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

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

При проектировании системы было решено, что она будет состоять из двух частей: модуля CRM, отвечающую за прием заявок, и Workflow Management System, ответственную за выполнение этих заявок. Именно WfMS является объектом исследования в данной работе.

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

Инициатором работы системы технической поддержки является студент, либо сотрудник университета: он обращается с конкретной проблемой с целью получить решение. Следующий уровень - первая линия поддержки. Роль первой линии поддержки выполняет CRM: эта часть службы технической поддержки регистрирует и обрабатывает заявки, затем в рамках этого уровня выполняется попытка найти решение проблемы, например, путем поиска подобных проблем в базе данных CRM. Если же проблема не может быть решена, то в действие вступает второй уровень технической поддержки - WfMS. В общем, система будет спроектирована таким образом, что CRM выступает в роли front-end модуля, то есть той части, которая взаимодействует с клиентом, предоставляя ему результат работ, а WfMS - back-end разработка, отвечающая за выполнение основных процессов, скрытых от глаз пользователя.

Как и любое структурное подразделение, КЦ должен использовать в своей работе определенные документы и процедуры. Так, при создании службы технической поддержки одним из вспомогательных инструментов может быть ITIL - библиотека, содержащая в себе лучшие практики по организации работы в области информационных технологий. Если говорить в целом, то важность этой библиотеки заключается в том, что многие серьезные ИТ-предприятия и подразделения ориентируются на разработанный стандарт BSI 15 000, который послужил основой и практически идентичен ISO 20 000, стандарту управлению и обслуживания ИТ-сервисов.

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

1) Спроектировать систему технической поддержки, определив для нее требования и функционал.

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

3) Параллельно разработать CRM и WfMS, протестировать их.

4) Провести интеграцию двух систем, с целью обеспечения их правильного взаимодействия.

5) Ввести в эксплуатацию сервис технической поддержки.

6) Обеспечить поддержание функционирования сервиса.

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

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

1.2 Общая теория по Workflow Management Systems

В текущем параграфе будет рассмотрена теория, которая будет изучена перед этапами проектирования и разработки WfMS.

Основные определения WfMS.

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

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

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

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

На данный момент существует несколько международных стандартов, направленных на работу с системами управления потоками работ:

1. Workflow Management Coalition (WFMC).

2. World Wide Web Consortium.

3. Organization for the Advancement of Structured Information Standards.

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

Теоретическое описание WfMS с помощью стандарта Workflow Reference Model.

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

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

1. Build-time functions. Встроенные временные функции, задающиеся определением и моделированием рабочих процессов. На данном архитектурном уровне происходит выполнение заранее заданных функций, цель которых заключается в описании текущего бизнес-процесса. Бизнес-процесс, описанный до этого каким-либо способом человеком, переводится в формальное представление, понимаемое системой. Данное преобразование происходит с помощью анализа и моделирования, а результат этих манипуляций принято называть «моделью процесса» или «метаданными процесса». Модель процесса состоит из набора действий и переходами между ними, которые выполняются согласно заранее определенным правилам и процедурам. Эти действия могут выполняться как человеком, так и компьютером. Определение процесса может представляться в любом формате: от текстового до описания рабочих процессов с помощью формальных языков, например, с помощью спецификации XML Process Defenition Language (XPDL), предложенной WFMC. Так же стоит отметить, что некоторые процессы допускают изменение их определения прямо в ходе их выполнения.

2. Run-time control functions. Функции контроля во время выполнения, ответственные за управление рабочими процессами и последовательности, которые рассматриваются как отдельные части рабочих процессов. На этапе происходит анализ процессов. С помощью специальных программных средств осуществляется: создание и управление рабочими процессами, создание, планирование и управление задачами, определение и распределение человеческих и технических ресурсов. Уровень выполнения процесса связывает его формальное описание и реальный вид, включающий пользователей и программные средства. Важнейшим элементом данного уровня является служба создания и управления потоками работ. Она создает и удаляет процессы, задает рабочие процессы и взаимодействие с ресурсами.

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

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

· наличие спецификаций для определения процессов и их взаимодействий;

· способность к взаимодействию с другими системами;

· вызов сторонних приложений;

· способность к взаимодействию с пользователями и их клиентскими приложениями;

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

Языки описания бизнес-процессов.

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

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

· XML Process Definition Language.

Спецификация XPDL, предложенная Workflow Management Coalition, представляет собой формальную модель для описания рабочих процессов, относящихся к любым сферам деятельности.

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

· Business Process Modeling Language.

Business Process Modeling Language представляет собой абстрактную модель и XML-язык для описания рабочих процессов различного типа.

BPML, в отличие от XPDL, является языком блочной структуры. Элементарными блоками, из которых строится модель рабочего процесса в BPML, являются «действия» (Activity). В данной спецификации различается три типа процессов:

1. Nested Process. Вложенный процесс, как и любое действие, может быть включен в родительский процесс.

2. Compensation Process. Процесс, обеспечивающий освобождение ресурсов, после завершения других процессов.

3. Exception Process. Процесс, обрабатывающий исключаемые события.

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

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

· BPEL4WS.

Business Process Execution Language - язык на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия веб-служб и включает в эту модель поддержку транзакций.

Появился BPEL4WS путем слияния языков WSFL и XLANG. Эти языки основаны на разных моделях: WSFL базируется на теории графов, XLANG - на иерархии тегов XML.

В языке BPEL выделяется два вида процессов: абстрактный и исполняемый. Первый ответственен за протокол обмена сообщениями, а второй содержит в себе функции выполнения «действий», обработку исключений и т.д. «Действия» делятся на примитивные и структурные, которые в свою очередь разделяются на различные типы. BPEL идейный наследник BPML, однако он намного сложнее и обширнее своего предшественника.

Использование одного из этих языков поможет в проектировании системы. WfMS состоит не только из программных средств, но и включает в себя аппаратуру и технический персонал ВУЗа, потому наиболее подходящим языком является XML Process Definition Language. В рамках проводимой работы не требуется углубляться до описания каждого рабочего процесса, тем не менее, основная идея при разработке WfMS заключается в декомпозиции заявок на задачи, которые представляют из себя рабочие процессы. И согласно идеологии XPDL задачи будут определяться как рабочие процессы, включающие в себя участников процесса, задействованные ресурсы и, в случае необходимости, переходы между задачами.

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

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

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

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

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

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

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

Во-вторых, должны быть внедрены два основных процесса: процесс принятия и обработки заявок и процесс их выполнения. От правильности формирования данных процессов может зависеть степень успешности функционирования службы в целом. В качестве вспомогательных инструментов для построения подобных процессов принято использовать содержимое ITIL или стандарта ISO 20 000.

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

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

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

Существует несколько видов служб технической поддержки:

1) Централизованная служба поддержки.

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

2) Локальная или распределенная служба технической поддержки.

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

· Центральная точка приема заявок. Подразумевает наличие единой точки приема заявок, которая затем отправляет обработанные заявки по локальным службам поддержки.

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

3) Виртуальная служба технической поддержки.

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

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

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

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

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

1.4 Основные особенности и функциональные возможности MS SharePoint 2010

Microsoft SharePoint 2010 - это платформа для совместной работы, обеспечивающая повышение производительности труда и управление контентом в знакомой среде Microsoft Office.

Уровни иерархии MS SharePoint представлены на рисунке 1.1:

Рисунок 1.1. Уровни иерархии MS SharePoint

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

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

Третий слой - коллекция сайтов. Представляет собой «корневой» сайт, для которого могут создаваться дочерние сайты.

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

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

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

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

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

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

Таким образом, SharePoint 2010 предоставляет обширный выбор инструментов для разработки WfMS. Их использование позволит реализовать нужный функционал, создавая при этом нетривиальные решения.

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

Помимо общего обзора сложившейся ситуации в университете и планам по разработке системы технической поддержки, была приведена теоретическая информация относительно WfMS, которая включает в себя международные стандарты, применяемые на практике в данной предметной области. Были рассмотрены и определены требования для разрабатываемой системы, языки описания бизнес-процессов, применяемые для формализации рабочих процессов. По итогам обзора было решено использовать стандарты Workflow Management Coalition, а именно: WfRM, как стандарт, используемый при создании системы управления потоками работ и основные принципы языка XPDL, используемго для описания процессов.

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

Вторая глава будет посвящена практической части работы, в ней будут освещены следующие этапы создания WfMS:

· рассмотрение особенностей проектирования WfMS;

· моделирование основных процессов WfMS;

· построение схемы данных;

· анализ использования MS SharePoint в рамках создания WfMS;

· разработка WfMS, включающая в себя составление документации к системе.

2. Моделирование и разработка WfMS НИУ ВШЭ - Пермь

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

2.1 Использование MS SharePoint 2010 при разработке WfMS НИУ ВШЭ - Пермь

В качестве заказчика на разработку WfMS выступает факультет бизнес-информатики НИУ ВШЭ - Пермь и одним из его требований является разработка системы с помощью MS SharePoint 2010.

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

· создавать порталы, способные хранить и оперировать с данными разных типов;

· настраивать сервисы под определенные нужды в рамках исследуемой предметной области;

· разрабатывать ряд программных решений и надстроек, позволяющих выполнять нетривиальные операции;

· организовывать совместную работу.

Разрабатываемая служба технической поддержки будет представлять собой веб-портал, созданный с помощью MS SharePoint 2010. Основными элементами этого портала будут списки и программные решения, созданные с применением различных технологий и языков программирования, таких как C#, JavaScript, ASP.NET.

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

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

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

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

Дежурный инженер. Член инженерно-технического и исполнительного персонала WfMS, ответственный за выполнение порученных ему задач.

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

Таким образом, список задач, в зависимости от представления, отображает:

1) Актуальные задачи.

2) Архивные задачи.

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

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

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

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

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

2.2 Моделирование основных бизнес-процессов WfMS НИУ ВШЭ - Пермь

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

Особенности проектирования WfMS НИУ ВШЭ - Пермь.

В предыдущем параграфе были описаны преимущества MS SharePoint, используемые при создании системы. Кроме того, там было кратко рассказано о некоторых особенностях WfMS, которым посвящен данный параграф.

С общими требованиями можно ознакомиться в приложении Б, в котором содержится ТЗ на разработку WfMS НИУ ВШЭ - Пермь.

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

Интероперабельность. WfMS должна быть способна к взаимодействию с CRM системой. Системы взаимодействуют путем использования общих списков MS SharePoint на портале службы технической поддержки.

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

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

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

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

Ранее были описаны роли, исполняемыми людьми в рамках WfMS, однако стоит четко их различать и выделять зоны их ответственности:

Оператор отвечает:

· за декомпозицию заявки на задачи;

· за назначение ответственного исполнителя (дежурного инженера) на задачу;

· за распределение ресурсов на задачи (в зависимости от ситуации - совместно с дежурным инженером);

· за архивирование и восстановление задач.

Дежурный инженер ответственен:

· за выполнение поставленной оператором задачи;

· за заполнение форм отчетности по проделанной работе.

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

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

· Актуальная - задача находится на стадии выполнения.

· Архивная - задача, по тем или иным причинам, отправленная в архив.

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

Построение моделей основных бизнес-процессов WfMS НИУ ВШЭ - Пермь

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

Первым этапом моделирования является постановка задачи. Задача может быть поставлена в любой форме: в виде словесного описания, графического или в виде программного кода. Второй этап - формализация. Он включает в себя создание модели на выбранном формальной языке, опираясь на поставленную задачу. Перед тем как преступить к построению модели важно выбрать инструменты и стандарты. Модель разрабатываемой WfMS может быть построена с помощью различных нотаций, таких как: ARIS, IDEF0/SADT, UML и других.

Было решено, что для построения процессов системы будет использоваться нотация ARIS eEPC. Методология была выбрана благодаря простоте своего освоения и наглядности полученных результатов.

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

В рамках основного бизнес-процесса выполнения заявки отображаются основные процессы, протекающие в WfMS.

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

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

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

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

Реализация функционала распределения ресурсов на задачи является наиважнейшей частью WfMS как признак автоматизированной системы. Быстрое и правильное назначение ресурса позволит скоординировать действия КЦ и ВШЭ - Пермь как предприятия вообще.

Было решено классифицировать ресурсы на три вида:

1. Трудовые ресурсы. Человеческие ресурсы, предполагается, что ресурсами этого вида будут сотрудники КЦ.

2. Материальные ресурсы. Обычные технические, аппаратные, программные и другие вспомогательные средства. Разделяются на расходные материалы и обычные.

3. Денежные ресурсы.

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

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

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

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



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

2.2 Разработка схемы данных

После моделирования основных процессов необходимо определить структуру данных. Изначально была разработана схема БД для WfMS и CRM. Она была нормализована и приведена к третьей нормальной форме. Реализацию схемы БД можно было осуществить с помощью любой СУБД, например, MySQL, но так как разработка системы ведется с помощью MS SharePoint 2010, то логичней, быстрей и рациональней использовать уже существующий инструментарий хранения информации: списки SharePoint, которые схожи в конструкции с таблицами БД.

Однако изначально схема БД разрабатывалась не под формат списков и библиотек, потому важно было правильно спроецировать составленную схему БД на формат списков SharePoint. На рисунке 2.2 представлена схема классов в формате списков:



Рисунок 2.2. Схема классов сервиса технической поддержки

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

· Список задач. Этот список содержит задачи, которые получились путем декомпозиции заявки.

· Список ресурсов. Содержит в себе информацию об имеющихся ресурсов КЦ.

· Список назначений. Содержит информацию о назначениях ресурсов на задачи.

· Общий список модулей. Смежный список, который обеспечивает взаимодействие WfMS и CRM модуля.

2.3 Описание разработанной системы

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

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

Разработка осуществлялась с использованием технологий MS SharePoint 2010 и ASP.NET, основным языком программирования был C#. Так же использовался JavaScript для генераций сообщений пользователю.

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

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

2. Список ресурсов. Отображает сведения об имеющихся ресурсах, в том числе тип конкретного ресурса и доступное количество.

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

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

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

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

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

Создание и редактирование элементов списка задач должно производиться оператором и дежурным инженером. При создании и редактировании элементов можно изменять только следующие поля:

· ИД. Идентификатор задачи.

· Название задачи.

· Идентификатор заявки. Код заявки, по которой создана задача.

· Время закрытия задачи. Заполняется дежурный инженером или оператором по завершению задачи.

· Текущее состояние. Может содержать одно из трех значение: «Задача выполняется», «Задача приостановлена» и «Задача завершена». Заявка не может быть закрыта, пока все задачи по ней не будут находиться в состоянии «Задача завершена».

· Описание решения задачи. Содержит описание действий дежурного инженера по выполнению задачи.

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

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

За работу со списком назначений, списком ресурсов и списком задач отвечает разработанное решение «WfMS.WebParts.AllocateResources», включающее в себя веб-части назначения и освобождения ресурсов:

· Веб-часть "GetResourcesWebPart". Визуальная веб-часть, реализует функционал назначения ресурсов на задачи.

· Веб-часть "FreeResourcesWebPart". Визуальная веб-часть, реализует функционал освобождения ресурсов.

Ручное добавление, архивирование и редактирование элементов списка назначений не предусматривается.

Список назначений выполняет ряд функций:

· Он позволяет проводить анализ и мониторинг доступности ресурсов.

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

· Позволяет вести историю назначений, путем добавления элементов списка в архив.

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

...