В данной статье описывается альтернативный метод создания заявки, в котором оптимизируется взаимодействие между пользователем и специалистом, сокращается время на создание заявки, автоматизируется процесс передачи заявки между двумя системами.
Ключевые слова: заявка, метод, процесс, оптимизация, автоматизация, пользователь, специалист
Рассматривается IT-структура промышленного предприятия.
Одной из важнейших задач, которыми занимаются IT-службы, является техническая поддержка и сопровождение, которые на данном предприятии осуществляются следующим образом:
1) При возникновении проблемы на программном или аппаратном уровне, пользователь обращается к специалисту группы технической поддержки, соответствующей данной проблеме, посредством телефона либо службы обмена мгновенными сообщениями.
2) Специалист, со слов пользователя, создает инцидент (заявку) в консоли System Center Service Manager (SCSM).
3) После решения проблемы, специалист (аналитик, в идеологии SC Service Manager) закрывает инцидент в консоли и пишет комментарий по разрешению.
Текущая организация процессов имеет несколько недостатков:
1) При отсутствии аналитика на своем рабочем месте, проблема зафиксирована не будет.
2) Распределение нагрузки на специалистов одной группы поддержки в большинстве случаев неравномерно.
3) Необходимость создания заявки специалистом отнимает время и требует контроля.
4) Ввиду того, что консоль SCSM установлена только у специалистов, пользователю недоступна информация о состоянии заявки.
С целью оптимизации процессов IT-служб с точки зрения временных затрат, а также кадровой организации, появляется необходимость разработки централизованной сервисной системы, позволяющей сформированную задачу представить в виде заявки, которая представляет собой форму с набором параметров, разделенных на два блока. Первый блок определяет пользователя системы, создающего заявку, второй блок содержит поля, необходимые для решения проблемы.
Проектируемый сервис должен обладать следующими характеристиками:
1) Он должен быть доступен для любого пользователя с любого компьютера.
2) Должна быть простая и понятная для пользователей система навигации и управления.
3) Система должна однозначно определять проблему.
4) Должна быть предусмотрена система личных кабинетов.
На основе вышеописанных требований разрабатывается проект службы подачи заявок.
Данная служба помещается на главном сайте компании, к которому каждый пользователь имеет доступ.
Разработка сервиса осуществляется на платформе SharePoint. В отличие от обычных сайтов он обладает широким функционалом для совместной работы, содержит различные библиотеки, списки со всевозможными типами данных и т. п. Для написания сайта используются следующие технологии:
– HTML — для разметки содержащейся текстовой информации;
– JavaScript — для написания логики программы;
– CSS (Cascading Style Sheets) — каскадные таблицы стилей, используются для описания внешнего вида документа, написанного с использованием языка разметки, в данном случае HTML.
Учитывая, что процесс обработки инцидентов в консоли System Center Service Manager не изменяется, появляется необходимость в интеграции между консолью и SharePoint. Для этого используется программная оболочка Microsoft PowerShell с подключением дополнительных модулей.
Доступ к сервису осуществляется с помощью аутентификации пользователя с использованием корпоративной службы каталогов Active Directory. Структура сервиса содержит следующие функции: Новая заявка, Мои заявки, Поиск заявки.
Этапы создания новой заявки:
1) Классификация проблемы — пользователь выбирает форму заявки, наиболее подходящую под описание его проблемы.
2) На основе выбранной формы производится генерация структуры заявки. Структура может содержать поля как обязательные, так и опциональные.
3) После заполнения всех полей осуществляется проверка правильности введенной в обязательные поля информации. При допущении ошибок, появляется предупреждение и подсвечиваются поля с ошибками.
4) При отправке, заявка регистрируется в системе и распределяется по группам решения проблем.
Список всех созданных пользователем заявок, сгруппированных по состояниям, в котором можно узнать состояние инцидента, а также комментарий специалиста, если он был разрешен, содержится в разделе «мои заявки».
Раздел «поиск заявки» предназначен для диспетчера, например, для поиска заявки, созданной другим пользователем.
В процессе реализации проекта появляются следующие трудности:
1) В связи с большим количеством форм заявок у пользователя появляются сложности с выбором правильной формы из длинного списка. Разработана двухуровневая система навигации, где сначала определяется класс проблемы, затем появляются формы, соответствующие этому классу.
2) В целях корректного создания заявки и дальнейшей её маршрутизации в IT-среде необходимо, чтобы все ключевые поля были заполнены без ошибок. Учитывая человеческий фактор, ошибки неизбежны. Данная проблема решается следующим способом:
При вводе нескольких символов в ключевое поле, появляется список доступных вариантов для заполнения с учетом уже введенной информации. Список подгружается из соответствующей базы данных. В связи с тем, что осуществлять доступ к базе данных при каждом запросе с точки зрения производительности нецелесообразно, синхронизация с БД происходит инкрементально (если обнаруживается обновленная запись, то изменяется только она), а информация берется уже из списка в SharePoint.
Таким образом, упрощается процесс заполнения заявки пользователем и исключается вероятность ввода несуществующих параметров.
3) Некоторые формы, в зависимости от выбранных параметров, должны создавать и распределять инциденты на разные группы поддержки. Учитывая вариативность проблем, создание простого, но универсального алгоритма не представляется возможным. Реализация алгоритма для каждой формы отдельно усложняет процесс дальнейшей настройки.
Создается древовидная структура, где элементами первого уровня являются подразделения. Элементами второго уровня являются группы поддержки. Элементы третьего уровня содержат работы, выполняемые определенной группой.
При заполнении формы определяется работа, требующая решения, которая проходит по структуре и ищет соответствующий элемент. При совпадении очевидным способом определяются параметры, необходимые для отправки заявки на релевантную группу поддержки.
Такая организация структуры легко изменяется и масштабируется без необходимости в программировании.
Данная система протестирована и уже функционирует на предприятии, соответствуя всем предусмотренным требованиям.
Литература:
- John, C. Microsoft System Center Optimizing Service Manager. — 2–2010: Gardners Books, 2010. — 452 с.
- Григорьев Я. Ю., Григорьева И. А., Трещев И. А. О подходах к стратегическому развитию информационных технологий в организации на примере высшего учебного заведения // Фундаментальные исследования. — 2014, № 8–2. — С. 290–295.
- Григорьев Я. Ю. Григорьева А.Л, Максимов С. Б. Разработка модульных динамических структур сопровождения деятельности организации // Мир науки. — 2014, № 3. — С. 30.
- Григорьева А. Л., Григорьев Я. Ю., Максимов С. Б., Трещев И. А. Разработка информационной системы университета. создание единого информационного пространства // Мир науки, культуры образования — 2014, № 2. — С. 1.
- Григорьева А. Л., Григорьев Я. Ю., Упская О. К. Перспективы развития и некоторые проблемы подходов проектирования информационных систем высших учебных заведений // Мир науки, культуры, образования. — 2014. № 3. С. 31.
- Григорьева А. Л., Григорьев Я. Ю. Проектирование и создание модулей информационной системы университета // Интернет-журнал Науковедение. — 2014. № 2 (21). С. 105.
- Попов А. В., Петрова А. Н., Григорьев Я. Ю., Григорьева А. Л., Лошманов А. Ю. Разработка программного обеспечения для проведения заочных олимпиад // Международный журнал прикладных и фундаментальных исследований.- 2013. № 5. С. 171–172.
