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



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

Ключевые слова: IT-инфраструктура, оптимизация, автоматизация, децентрализованные сервисные системы, передача инцидентов

Рассматривается универсальная модель бизнес процессов, позволяющая повысить эффективность работы it специалистов в предприятиях с удаленными филиалами.

Объектом исследования является IT-инфраструктура предприятия с числом АРМ (Автоматизированное рабочее место) превышающим пять тысяч, а предметом — процесс обработки заявок средствами SCSM (System Center Service Manager), SC Orchestrator, Веб приложения dService, PowerShell.

Анализ бизнес-процессов обработки заявок в филиалах предприятия, выявляет недостатки:

1) Отсутствие четкой структуры базы знаний.

2) Отсутствие связи между классификатором проблем при подаче заявки и типовыми решениями по данной проблеме в базе знаний.

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

4) Отсутствие способа автоматической отправки пользователю ККС (Компьютерная корпоративная сеть) справочной информации по заявкам.

5) Отсутствие автоматизированного процесса передачи заявок между филиалами:

1. «Ручная» передача вложений через электронную почту.
2. «Ручная» обработка писем с вложениями из других филиалов.
3. «Ручное» прикрепление вложений к переданному инциденту.
4. «Ручное» закрытие исходного инцидента.

6) Отсутствие информации о переданной заявке (факт передачи, проведенные работы по затронутой проблеме, комментарии специалистов из другого филиала).

7) Отсутствие возможности отслеживания закрытия заявки в другом филиале, в результате чего появляются «висящие» открытые заявки в сервисных системах.

8) Отсутствие возможности передачи комментария к инциденту.

9) Отсутствие системы логов по переданным инцидентам.

Для решения подобного рода проблем, реализуется модель (Рисунок 1) бизнес-процессов, включающая в себя следующие этапы:

1) Создание заявки— осуществляется из веб портала, реализованного средствами SharePoint. В форме заявки есть ссылка на базу знаний и форум самообслуживания.

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

3) Передача инцидента на исполнение спомощью оповещения аналитика (специалиста it-службы)— происходит спустя два часа с момента создания заявки (если заявка не носит срочный характер). Оповещение делается через корпоративный мессенджер Microsoft Lync.

4) Работа над заявкой. В этот момент аналитик решает заявку своими силами, либо же передает инцидент в другой филиал.

5) Эскалация инцидента вдругой филиал (Рисунок 2, рисунок 3). Данный бизнес-процесс по сути является передачей заявки из одной сервисной системы в другую.

6) Разрешение инцидентов (выполнение). Закрытие инцидента и информирование пользователя.

Рис. 1. Общий вид универсальной

Рис. 2. Новая модель первичной передачи заявки модели бизнес-процессов

Рис. 3. Новая модель обновления инцидента

Для оценки эффективность модели используются следующие показатели:

1) Затраченные человеко-часы it специалистов на обработку заявки. Эта величина равна сумме рабочего времени it специалистов, потраченного на одну заявку. Данный параметр будет является средним значением для группы инцидентов.

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

3) Заявки, решенные без участия аналитика. Процент заявок, решенных пользователями.

4) Время, затраченное на передачу заявок между филиалами.

На данную модель так же, наложены ограничения:

1) Целостность данных. Атрибуты инцидента должны передаваться без потерь и искажений.

2) Норматив на первое взятие заявки. Данное ограничение направлено на повышение эффективности работы it служб. Им регулируется максимальное время на принятие заявки в работу.

3) Синхронизация переданных заявок. Система должна проводит синхронизацию между одинаковыми заявками в разных филиалах.

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

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

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

Модуль «базы знаний» решает следующие задачи:

1) Создается чёткая структура базы знаний (удобная навигация и интуитивно понятный интерфейс пользователя).

2) Формируются требования к оформлению документации.

3) Создается система тегов и ссылок для связи инцидента и статьи базы знаний.

4) Реализуются и настраиваются Runbook и управляющие скрипты.

Модуль «отправка справочной информации» позволяет решить задачи:

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

2) Создаётся шаблон для электронного письма Outlook.

3) Устанавливаются модули для интеграции PowerShell и Outlook.

4) Программно реализуются методы для получения из управляющего скрипта нужных данных (ID инцидента и полезные ссылки).

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

Модуль — «оповещение аналитиков» решает следующие задачи:

1) Программно реализуется метод для получения целевых инцидентов (созданных более двух рабочих часов назад).

2) Интегрируется PowerShell и Lync.

3) Создаётся шаблон сообщения.

4) Программно реализуется метод для загрузки в шаблон основных атрибутов инцидента.

5) Создается скрипт для привязки классификатора инцидентов к членам групп поддержки по затронутому программному обеспечению.

6) Программно реализуется метод отправки уведомлений аналитику.

Модуль «передача инцидентов между филиалами, решает задачи:

1) Создаются и настраиваются управляющие скрипты и Ранбуки (12 штук).

2) Находятся подходящие проекции для передачи нужных атрибутов.

3) Настраивается файрволл и доступ между серверами внутри филиалов.

4) Создаются системные учетные записи с необходимыми правами во всех филиалах.

5) Устанавливаются и подключаются SMLets на всех серверах SCSM и SC Orchestrator.

6) Создаётся буфер для вложений.

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

Таблица 1

Оценка эффективности модели

№	Показатель эффективности	Характеристика		Оценка эффективности
		До	После
1	Затраченные человеко-часы it специалистов на обработку заявки	17 минут	13 минут	Время работы над инцидентом снижено на 23,5 % Экономия (бюро) в месяц/год– / 55452 р. Экономия (Отдел) в месяц/год– 27726/ 332712р.
2	Процент заявок, не потребовавших участие высококвалифицированных специалистов	14,5 %	24,8 %	Число заявок обработанных без участия специалистов высокой квалификацией увеличено на 71 % Экономия (бюро) в месяц/год–768,8/ 9225,6 р. Экономия (Отдел) в месяц/год — 4612/ 55344 р.
3	Время, затраченное на передачу заявок между филиалами	13 минут	<1 мин.	Скорость передачи увеличена более чем в 13 раз Экономия (бюро) в месяц/год–4036,5 р / 48438 р. Экономия (Отдел) в месяц/год — 24219/ 581256 р.
4	Время, затраченное на мониторинг SCSM	40	-	Полностью исчезла необходимость в мониторинге SCSM Экономия (бюро) в месяц/год — 2588/ 31056 р. Экономия (Отдел) в месяц/год — 31056/ 372672 р.
3	Заявки, решенные без участия аналитика	-	14,4 %	Процент заявок, решенных без помощи аналитиков 14,4 % Экономия (бюро) в месяц/год — 9875,8/ 118510 р. Экономия (Отдел) в месяц/год –59255/ 711000 р.

Литература:

1. John, C. Microsoft System Center Optimizing Service Manager. — 2–2010: Gardners Books, 2010. — 452 с.
2. Beaumont, S. Microsoft System 2012 Service Manager Cookbook. — 1–2012: Gardners Books, 2012. — 530 с.
3. Холмс Л., Windows PowerShell карманный справочник — 1–2008: ЭКОМ Паблишерз, 2008. — 160 с.
4. Григорьев Я. Ю., Григорьева И. А., Трещев И. А. О подходах к стратегическому развитию информационных технологий в организации на примере высшего учебного заведения // Фундаментальные исследования. — 2014, № 8–2. — С. 290–295.
5. Григорьев Я. Ю. Григорьева А.Л, Максимов С. Б. Разработка модульных динамических структур сопровождения деятельности организации // Мир науки. — 2014, № 3. — С. 30.
6. Григорьева А. Л., Григорьев Я. Ю., Максимов С. Б., Трещев И. А. Разработка информационной системы университета. создание единого информационного пространства // Мир науки, культуры образования — 2014, № 2. — С. 1.
7. Григорьева А. Л., Григорьев Я. Ю., Упская О. К. Перспективы развития и некоторые проблемы подходов проектирования информационных систем высших учебных заведений // Мир науки, культуры, образования. — 2014. № 3. С. 31.
8. Григорьева А. Л., Григорьев Я. Ю. Проектирование и создание модулей информационной системы университета // Интернет-журнал Науковедение. — 2014. № 2 (21). С. 105.
9. Попов А. В., Петрова А. Н., Григорьев Я. Ю., Григорьева А. Л., Лошманов А. Ю. Разработка программного обеспечения для проведения заочных олимпиад // Международный журнал прикладных и фундаментальных исследований.- 2013. № 5. С. 171–172.