Современная электронная библиотека ModernLib.Net

ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

ModernLib.Net / Van Jan / ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL - Чтение (стр. 11)
Автор: Van Jan
Жанр:

 

 


9.3.3. Варианты организации Службы Service Desk

Существует несколько вариантов организации Служб Service Desk. Наиболее распространенными являются следующие:

? Централизованная Служба Service Desk как единая точка контакта для всех пользователей, воз­можно с отдельной Службой Service Desk, расположенной ближе к пользователям бизнес-прило­жений (Service Desk с разделением функций).

? Локальные (распределенные) Службы Service Desk, расположенные на нескольких объектах. Обычно такое деление Службы Service Desk усложняет управление.

? Виртуальная Служба Service Desk, когда ее географическое расположение не имеет значения в связи с использованием коммуникационных и Интернет-технологий.

Централизованная Служба Service Desk

На рис. 9.2 показана структура Централизованной Службы Service Desk с разделением функций. Ес­ли ИТ-организация несет ответственность и за предоставление услуг, и за поддержку информацион­ных систем, то лучше всего, чтобы Служба Service Desk была для пользователей единой точкой кон­тактов. В этом случае Service Desk отвечает за прием, регистрацию, мониторинг хода обработки и эс­калацию звонков. Функция поддержки бизнес-операций может являться частью функций Службы Service Desk или же за это может отвечать отдельная группа поддержки, контролируемая Службой Service Desk Для такой организации работы требуется общая система регистрации инцидентов. Если ИТ-организация не несет ответственности за поддержку бизнес-операций, тогда служба под­держки бизнес-операций будет действовать от лица пользователей в тех случаях, когда требуется поддержка со стороны поставщика ИТ-услуг.



Рис. 9.2. Служба Service Desk с разделением функций


Такой подход может сочетаться с организацией "моста" с операционной средой (т. е. точкой кон­центрации руководства операционной деятельностью, которой может выступать, например, Служба Service Desk в сочетании с отделом эксплуатации ). Это может быть целесообразно для обеспечения взаимодействия между Службой Service Desk и руководством операционной деятельностью , вклю­чая Управление Сетями, Серверами и т. д. Такое взаимодействие Службы Service Desk с функцио­нальными подразделениями ИТ обеспечивает быстрое реагирование в тех случаях, когда Служба Service Desk не может сразу же устранить ошибки. В идеале эти подразделения должны размещать­ся близко друг к другу.

Распределенная Служба Service Desk

Распределенная служба размещается в разных зданиях или даже в разных городах и регионах. На рис 9.3 представлен пример распределенной Службы Service Desk. При использовании такой струк­туры целесообразно выбрать один из предлагаемых ниже вариантов:

? Центральная точка контактов, где звонки принимаются и далее маршрутизируются в локальные службы поддержки. Центральная Служба Service Desk является для пользователей начальной точ­кой контактов, где регистрируются инциденты. Современное программное обеспечение маршру­тизации звонков способствует повышению эффективности работы Службы Service Desk в разре­шении инцидентов.

? Локальные точки контактов с центральной Службой Service Desk предназначены для отслежива­ния и мониторинга инцидентов. Данный подход часто используется в тех случаях, когда у локаль­ной организации свой язык и корпоративная культура, а также когда у организации достаточно много специфических приложений собственной разработки для каждого направления бизнеса. Например, у компании в химической отрасли может быть более трехсот категорий собственных приложений, а общее количество приложений – около тысячи. В такой ситуации единственным практическим решением является распределение функций Службы Service Desk между различны­ми направлениями бизнеса, т. к. для решения инцидентов требуются специфические знания в конкретной области. Локальная ответственность за затраты на поддержку может служить дополни­тельным мотивирующим фактором в такой структуре.


Рис. 9.3. Распределенная Служба Service Desk с централизованным управлением (источник: OGC)


? Центр обработки звонков (Call Center). Этот вариант становится все более популярным, и его ча­сто используют провайдеры и поставщики услуг. По центральному номеру телефона, обычно бес­платному, можно получить доступ к голосовому меню, из которого пользователь выбирает пункт, по которому требуется помощь, например, электронная почта или офисные приложения. Звонок затем направляется к специалисту соответствующей группы поддержки. Эти группы могут нахо­диться в разных местах, но пользователь об этом может даже не подозревать.

Виртуальная Служба Service Desk

Виртуальная служба Service Desk является современной специализированной версией распреде­ленной службы. Она состоит из нескольких локальных Служб Service Desk, которые образуют единую (виртуальную) службу, поскольку современные телекоммуникационные и Интернет-тех­нологии делают месторасположение несущественным фактором. В таком случае Служба Service Desk и группы поддержки могут располагаться где угодно. Имея локальные службы в разных вре­менных зонах, такая служба обеспечивает круглосуточную поддержку пользователей (концепция "следуя за солнцем"). Недостатком такой организации является трудность предоставления под­держки на местах.

В последнее время мы видим возможности самостоятельного получения помощи пользователями (самообслуживания - self-help) как форму "автоматизированной" функциональности Службы Ser­vice Desk.

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

9.3.4. Персонал Службы Service Desk

Требования к персоналу Службы Service Desk определяются ее миссией и структурой. Ниже даются возможные варианты основных способов построения и требования к персоналу, вытекающие из по­ставленных задач:

? Центр обработки звонков (Call Center): производит только запись/регистрацию звонков и не предоставляет какой-либо поддержки. Обращения перенаправляются к специалистам соответст­вующих подразделений для обработки. В некоторых случаях можно автоматизировать запись и маршрутизацию обращений с помощью голосовых меню.

? Неквалифицированная Служба Service Desk или Служба регистрации звонков: все звонки реги­стрируются, описываются в общих чертах и затем сразу маршрутизируются. Служба Service Desk в основном выполняет диспетчерские функции, и для обработки поступающих звонков ей необходимы стандартные процедуры работы и сценарии обработки обращений (опросники). Для обеспе­чения успешной работы необходимо наличие опытного руководителя и хорошей дисциплины. Преимуществом данного подхода является стандартизация приема и регистрации инцидентов, а недостатком – более длительное время реакции и более низкая степень решения инцидентов при первом обращении по сравнению с квалифицированной Службой Service Desk.

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

? Экспертная Служба Service Desk: персонал данной службы знает всю ИТ-инфраструктуру и рас­полагает экспертными знаниями, позволяющими решать инциденты самостоятельно.

9.3.5. Технологии для работы Службы Service Desk

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

? интеграция инструментальных средств сервис-менеджемента с системами Управления ИТ инфра­структурой;

? коммуникационные технологии, такие как Computer Telephone Integration (CTI) или Voice Over Internet Protocol (VOIP);

? системы интерактивного речевого меню (Interactive Voice Response – IVR);

? электронная почта (E-Mail);

? факс-серверы (факс через электронную почту или Интернет);

? инструментальные средства перенаправления звонков на пейджеры, мобильные телефоны и пор­тативные компьютеры;

? инструментальные средства поиска и диагностики неисправностей (базы знаний, системы приня­тия решения по ситуации);

? автоматизированные инструментальные средства Управления Сетями и Системами;

? Интранет и Интернет-порталы для самостоятельного доступа пользователей.

9.4. Виды деятельности

9.4.1. Ответы на обращения

Обращение (звонок) – это контакт пользователя со Службой Service Desk. Все обращения пользо­вателей должны регистрироваться для облегчения дальнейшей обработки, мониторинга хода обра­ботки и предоставления метрик, необходимых для контроля над процессом.

Существует две категории обращений:

? Инциденты: по существу, это все обращения, за исключением тех, что связаны со стандартными изменениями:

? Сообщения об ошибках: реальные сбои в инфраструктуре и жалобы на услуги.

? Запросы на Обслуживание : в библиотеке ITIL Запросы на Обслуживание классифицируются как инциденты, но они не предполагают наличия сбоя в инфраструктуре. Эти Запросы также не попадают в сферу действия Процесса Управления Изменениями. Примером такого Запроса мо­гут послужить вопросы типа "Как мне сделать?", Запросы на Информацию, например, Запросы о Статусах Систем, Запросы на Документацию или получение рекомендации, Запросы на Смену паролей, Запросы на Запуск Пакетных Заданий, восстановление файлов или получение инфор­мации из базы данных, Запросы на расходные материалы (включая замену мыши, клавиатуры и т. д., если они не являются Конфигурационными Единицами), на предоставление документации, например, руководства пользователя и т. д.

? Изменения: в большинстве случаев это стандартные Запросы на Изменения (RFC). В некоторых случаях Служба Service Desk также отвечает за перемещение оборудования. Стандартное измене­ние на практике представляет собой типовое (рутинное) изменение инфраструктуры, которое вы­полняется по установившейся известной схеме (процедуре) и является согласованным (одобрен­ным) решением в ответ на какие-либо требования или группу требований. Примерами стандартно­го изменения может служить апгрейд PC для использования специального программного обеспе­чения; настройка PC, установка стандартного набора программного обеспечения и подключение к сети новых сотрудников; простые стандартизированные настройки и заказ стандартных рабочих станций, периферийных устройств и локальных приложений. Основное различие между Запросом на Обслуживание и стандартным изменением состоит в том, что первый регистрируется как инцидент, который не требует изменения в ИТ-инфраструктуре, в то время как второй регистрируется как изменение и требует проведения изменения в ИТ-инфраструктуре.

Примечание. Согласно библиотеке ITIL оба типа обращений (сообщения об ошибках и Запросы на Обслуживание) рассматриваются как "инциденты", т. к. они обрабатываются по достаточно близ­ким правилам. С другой стороны, ITIL допускает использование отдельных процедур для обработки Запросов на Обслуживание, которые отделены от Процесса Управления Инцидентами.

9.4.2. Предоставление информации

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

9.4.3. Взаимодействие с поставщиками

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

9.4.4. Операционные задачи

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

9.4.5. Мониторинг инфраструктуры

Служба Service Desk может иметь в своем распоряжении инструментальные средства, помогающие определению степени воздействия сбоев на работу критически важных систем, таких как маршрути­заторы, серверы, шлюзы, приложения и базы данник Часто эти средства автоматически обнаружи­вают сам сбой или угрозу его возникновения и передают информацию в Процесс Управления Ин­цидентами. Службе Service Desk необязательно применять эти средства, т. к. обнаружение сбоев яв­ляется главной задачей операционных подразделений ИТ, которые и передают эту информацию Службе Service Desk

9.5. Эффективность

Удовлетворенность заказчика или пользователя является основным показателем эффективности ра­боты Службы Service Desk. Примерами Ключевых параметров эффективности (KPI) могут быть:

? скорость ответа на телефонные звонки (например, на 90% телефонных звонков отвечают в течение X секунд);

? скорость перенаправления звонков на вторую линию поддержки в течение X минут (если звонок нельзя разрешить на уровне Service Desk);

? восстановление сервиса в течение допустимого времени и в соответствии с условиями Соглаше­ния об Уровне Услуг (SLA);

? своевременное информирование пользователей о текущих и будущих изменениях и ошибках.

Некоторые показатели эффективности можно определить только на основе результатов опроса за­казчиков, например такие как:

? Насколько вежливо специалисты Service Desk общаются по телефону?

? Предоставляются ли пользователям хорошие рекомендации по способу предотвращения инци­дентов?

9.5.1. Отчеты руководству

Служба Service Desk должна регулярно (например, раз в полгода) проверять, насколько ее работа отвечает заданным стандартам. Примерами метрик являются:

? процент инцидентов, которые могут решаться на Уровне Service Desk без перенаправления на другие уровни поддержки (например, на вторую или третью линии поддержки или к поставщику);

? количество обработанных звонков на одно рабочее место/пользователя и общее количество звон­ков, обработанных Службой Service Desk;

? среднее время решения инцидентов (по степени воздействия) или время, необходимое для выпол­нения Запроса на Обслуживание. Следует указывать как непосредственное время на выполнение, так и общее время от открытия до закрытия инцидента;

? отчеты телефонной станции (РАВХ) о среднем времени ответа на телефонный звонок, количестве звонков, прерванных пользователями, средней продолжительности звонков и соответствующих метрик на каждого специалиста Службы Service Desk.

Для этих метрик могут быть определены стандарты, по которым возможно отслеживание улучше­ния или ухудшения в предоставлении услуг. Эффективность Службы Service Desk также может быть измерена путем проведения регулярных опросов и анкетирования пользователей в компании.

9.5.2. Критические факторы успеха

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

Если пользователи пытаются установить контакты напрямую со специалистами, их следует направ­лять в Службу Service Desk.

Для того, чтобы поддержка, оказываемая Службой Service Desk была сфокусированной, следует тщательно прорабатывать Каталог услуг, Соглашения об Уровне Услуг (SLA) и Операционные Сог­лашения об Уровне Услуг (OLAs).

Глава 10 Управление Уровнем Сервиса (Услуг)

10.1. Введение

Управление Уровнем Сервиса (Услуг) – это процесс, в рамках которого происходят переговоры по вопросам предоставления услуг, производится определение, измерение (оценка), управление и улучшение качества ИТ-услуг при соблюдении приемлемого Уровня Затрат. Все эти задачи должны решаться в условиях быстро меняющихся потребностей бизнеса и быстро развивающихся техноло­гий. Процесс Управления Уровнем Сервиса помогает найти нужный баланс между предложением и спросом на услуги требуемого Уровня Качества, их легкостью в использовании и стоимостью. И по­ставщик, и заказчик должны четко осознавать, что услуги не только поставляются, но и используют­ся. Это понимание реализуется в разработке, согласовании и выполнении Соглашений об Уровне Услуг (SLA), Операционных Соглашений об Уровне Услуг (OLA), Внешних Договоров (UC) и Плана Обеспечения Качества Услуг (SQP).

10.1.1. Основные понятия

Поставщики и заказчики ИТ-услуг

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

? Заказчик – это представитель организации, у которого есть полномочия на заключение соглаше­ний от лица организации на получение ИТ-услуг. Поэтому заказчик и конечный пользователь ус­луг – не одно и то же.

? Поставщик – это представитель организации, у которого есть полномочия на заключение согла­шений о предоставлении ИТ-услуг.

Требования к Уровню Услуг (Service Level Requirements – SLR)

Требования к Уровню Услуг представляют собой детальное описание потребностей заказчика, они используются при разработке, модификации и инициировании услуг. Такие требования можно ис­пользовать в качестве прототипа (кальки) для разработки услуги и соответствующего ей Соглаше­ния об Уровне Сервиса (SLA), а также как проектное задание (design assignment).

Таблицы спецификации сервисов (Service Specification Sheets – Spec Sheets)

Таблицы спецификаций используются для описания зависимости отношений между функциональ­ностью (согласованной с заказчиком и поэтому определяемой извне, с точки зрения поставщика) и технологией (используемой в организации и потому управляемой изнутри) и содержат детальную спецификацию услуги. Таблицы помогают преобразовать Требования к Уровню Сервисов (внешние спецификации) в технические определения, необходимые для предоставления этой услуги (внут­ренние спецификации). Кроме того, они описывают связи между соглашениями SLA, OLA и UC. Таблицы спецификаций являются важным инструментом мониторинга соответствия внутренних спецификаций внешним.

Каталог услуг (Service Catalog)

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

Соглашение об Уровне Услуг (Service Level Agreement – SLA)

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

Программа улучшения сервиса (Service Improvement Program – SIP)

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

План обеспечения качества услуг (Service Quality Plan – SQP)

План обеспечения качества сервиса является важным документом, так как в нем содержится вся ин­формация, необходимая для управления ИТ-организацией. В нем определены параметры процессов сервис-менеджмента и операционного управления. Если Соглашение SLA определяет что мы будем предоставлять, то План SQP определяет как мы будем это предоставлять. В плане обеспечения каче­ства определены цели улучшения для каждого процесса в форме Показателей качества (Performance indicators). Например, для Процесса Управления Инцидентами план определяет время разрешения для инцидентов в зависимости от различной степени воздействия, а для Процесса Управления Из­менениями – время цикла и затраты на стандартные изменения, например, такие как перемещение сотрудников. Для всех процессов определяются виды отчетов и сроки их предоставления. Показате­ли качества разрабатываются на основе Требований к Уровню Услуг и заносятся в Таблицы специ­фикаций. Если в предоставлении услуг участвуют внешние поставщики, например, когда к службе Service Desk или к обслуживанию персональных компьютеров привлекаются внешние ресурсы, тог­да Показатели качества определяются во Внешних Договорах.

Операционное Соглашение об Уровне Услуг (Operational Level Agreement – OLA)

Это соглашение с внутренним ИТ-подразделением, в котором конкретизируются договоренно­сти о предоставлении определенных элементов сервисов, например, доступности сети или дос­тупности серверов печати. Например, если соглашение SLA содержит временные показатели в разрешении инцидентов с высоким приоритетом, то Операционное Соглашение об Уровне Услуг (OLA) должно определять цели для каждого элемента цепочки поддержки (параметры для службы Service Desk – время ответа на звонки, эскалация инцидентов и т. д., параметры для Службы поддержки сети – сроки расследования и устранения сетевых ошибок и т. д.). Операци­онные Соглашения об Уровне Услуг помогают ИТ-организации в общем процессе предоставле­ния услуг.

Внешний Договор (Underpinning contract – UC)

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

10.2. Цель процесса

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

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

Преимущества использования процесса

В целом, введение в практику Процесса Управления Уровнем Сервиса может дать следующие преи­мущества:

? ИТ-услуги разрабатываются в соответствии с Требованиями к Уровню Услуг и, следовательно, бу­дут отвечать ожиданиям заказчика;

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

? если ИТ-организация выставляет счета заказчику за пользование ИТ-услугами, то заказчик смо­жет сопоставить Уровень Качества услуг с предъявленной в счете стоимостью;

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

? улучшаются отношения с заказчиками и повышается уровень удовлетворенности потребителей ИТ-услуг;

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

10.3. Процесс

Управление Уровнем Сервиса – это процесс, который связывает поставщика ИТ-услуг и заказчика. Этот процесс имеет следующие задачи:

? интеграцию элементов, необходимых для предоставления ИТ-услуг;

? документирование услуг путем четкого описания их элементов в различных документах;

? описание предоставляемых заказчику услуг на понятном и удобном для заказчика языке;

? согласование ИТ-стратегии с потребностями бизнеса;

? контролируемое улучшение предоставления ИТ-услуг.

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



Рис. 10.1. Процесс Управления Уровнем Сервисов


В рамках Процесса Управления Уровнем Сервиса выполняются следующие виды деятельности:

? Идентификация – идентификация потребностей заказчика, управление взаимоотношениями и внутреннее продвижение ИТ-организации. Понимание бизнес-процессов и потребностей заказчи­ка.

? Определение – определение требуемых услуг в соответствии с потребностями и запросами заказ­чика. Услуги определяются в виде Требований к Уровню Услуг и Таблиц спецификаций услуг. Ре­зультатом выполнения этого вида работ является создание Плана обеспечения качества услуг.

? Окончательное оформление соглашения – заключительный этап работы над соглашением, т. е. обсуждение с заказчиком требуемого Уровня Сервисов и связанных с этим затрат, закрепление до­стигнутых договоренностей в Соглашении об Уровне Сервиса (SLA). Подкрепление соглашения SLA Операционными Соглашениями об Уровне Услуг (OLA) и Внешними Договорами (UC). Сос­тавление или обновление Каталога Услуг с указанием в нем доступных для заказчиков услуг.

? Мониторинг – мониторинг Уровней Сервисов.

? Отчетность – составление Отчетов об Уровне Сервисов. Регулярное предоставление отчетов за­казчику и ИТ-организации о реальных текущих Уровнях Предоставления Услуг в сравнении с об­щим достигнутым Уровнем (Service Level Achievement).

? Анализ (пересмотр) – совместный с заказчиком анализ сервисов с целью определения направле­ний его улучшения. Возможно инициирование Программы улучшения сервиса, если это необходи­мо. Деятельность включает в себя частые контакты с заказчиком и обмен мнениями о предостав­ляемых услугах. Результатом такого вида деятельности может стать новое или пересмотренное Соглашение об Уровнях Сервиса.


  • Страницы:
    1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20