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

134

Проблема регламентации временных характеристик бизнес-процессов в сфере информационных технологий

Разыграев С. В.

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

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

При процессно-ориентированном подходе необходимо учитывать ситуацию внутри организации (внутреннюю политику, корпоративную культуру, численность и так далее). ITIL (IT Infrastructure Library), наиболее известный подход к ИТ Сервис-менеджменту, не дает каких-либо ограничений по типу организации, а, наоборот, описывает связи между видами деятельности, которые применимы в организациях любого типа. Это создает структурированную основу для обмена опытом между компаниями и изучения опыта динамично развивающихся организаций.

Одной из составляющих ИТ Сервис-менеджмента является управление инцидентами.

Управление инцидентами

Задачей Процесса Управления Инцидентами является уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом, обеспечивая наиболее быстрое восстановление работы пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Так как это требует тесного взаимодействия с пользователями, фокусной точкой Процесса Управления Инцидентами обычно является функция Service Desk, которая играет роль центра контактов пользователей с «внутренними» коллективами технических служб. Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры.

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

Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:

§ новый;

§ принят;

§ запланирован;

§ назначен;

§ активный;

§ отложен;

§ разрешен; ? закрыт.

В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или программного обеспечения, но также и Запросы на Обслуживание.

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

Примеры Запросов на Обслуживание:

§ вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;

§ запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;

§ запрос о замене пароля;

§ запросы на выполнение пакетных заданий, восстановление или авторизацию пароля; ? получение информации из базы данных.

Степень воздействия, срочность и приоритет

При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уровнях Услуг (Service Level Agreements - SLAs) Служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

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

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

§ срочность инцидента - приемлемая задержка разрешения инцидента для пользователя или бизнеспроцесса.

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

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

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

Приоритет = Срочность * Степень воздействия.

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

Табл. 1. Матрица определения приоритета запроса

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

134

Цель

Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement - SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов. Преимущества использования процесса ДЛЯ бизнеса в целом:

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

• повышение производительности работы пользователей;

• независимый, ориентированный на потребности заказчика мониторинг инцидентов;

• доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).

Для ИТ-организации:

• улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);

• эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;

• эффективное использование персонала;

• предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;

• повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database - CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item. - CI);

• повышение удовлетворенности пользователей и заказчиков.

Отказ от использования Процесса Управления Инцидентами

Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:

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

• пользователи могут перенаправляться к одним и тем же специалистам «по кругу» без успешного разрешения инцидента;

• специалисты могут постоянно отрываться от работы телефонными звонками пользователей, из-за чего им становится трудно эффективно выполнять свою работу;

• могут возникать ситуации, когда несколько человек будут работать над одним и тем же инцидентом, непродуктивно теряя время, и примут противоречивые решения;

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

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

Пример реализации процесса инцидентами и решение проблемы коллизии приоритетов

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

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

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

В конце месяца от бухгалтера поступает запрос о том, что у него произошли какие-то неполадки в системе. Согласно структуре предприятия бухгалтер является сотрудником среднего звена и запросу автоматически присваивается средняя срочность исполнения. Поскольку инцидент сказался только на одном сотруднике и на первый взгляд не влечет за собой критичных изменений в бизнес-процессах компании, степень воздействия определяется как средняя и запросу по матрице назначается средний приоритет и время разрешения не более 24 часов или трех рабочих дней (при классе обслуживания 8 часов в день, 5 дней в неделю). Запрос помещается в общую очередь и ждет времени его исполнения.

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

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

Решение в подобных случаях может быть следующим: ввести понятие «условно критичного приоритета». При настройке системы Service desk, обрабатывающей регистрируемые запросы, необходимо указать, что запросам, поступающим в конце месяца (например, в третьей декаде) от ответственного бухгалтера назначается приоритет «критический». Запросам, поступающим в остальное время, приоритет назначается согласно матрице. Таким образом, введение условно критичного приоритета позволит избежать случаев неверной трактовки важности запросов и критичного влияния инцидентов на бизнес-процессы организации.

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

<ЕСЛИ дата регистрации запроса принадлежит последней декаде месяца и автор запроса = ответственный бухгалтер ТО приоритет запроса = критический>

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

Список использованной литературы

1. Брукс П. Метрики для управления ИТ-услугами. - М.: Альпина Бизнес Букс, 2008.

2. Потоцкий М. Ю., Григорьев М. А. ИТ Сервис-менеджмент, введение. - М.: IT Expert, 2003.

3. Ребрин Ю. И. Управление качеством. - Таганрог: ТРТУ, 2004.

4. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. - М.: РИА «Стандарты и качество», 2008. - 408 с.

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