назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [ 43 ] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


43

Взаимоотношения с Процессом Управления Конфнг}рацнями

Процесс Управления Конфигурациями отвечает за ввод детально!! инфорл!ацип о кол!по1!е1!тах услуг (Копф1ггура!и10!!П!>!х Ед1!И!1!и1х) И докумситаци!! (Согла1!1еи1!1 об Уров!1е Серв!1са - SLA) в Конф!1гурац1!0!П!у!о Базу Данных (CMDB) !! предоставление 1!!!(х)рма!пг!! нз aioii баз1)1. Поэтому создание !1Л1г моднф11!<:ация услу!Т1 !1ли со-ла!!!еиия влечет за co6oii 1!зме!!снпя в CMDB. Служба Service De.sk использует Конф!1!-ура!П1011ну10 Базу Данных для определения степени воздействия сбоев !!а услуги и для 1!олучения н!1фо1)ма!НП! из согла11!е!1!1Й SLA о времени реа1ирова1!Ня и времени разрешсн!1я сбоев. Е1иформац1!я из CMDB также ис!!ользуется пщ составлении отчетов о качестве Конф1П711а!И!0!!НЬ!Х Едп!1иц, что поз!юляст Про!1ессу У1!равления Уров!!ем Серв!1са под!хггав-лива1т> отчеты о качестве предосчавляемых услуг.

Взаимоотно1не1И1я с Процессом Управления Финансами ИТ

Если ИТ-ор!аниза!и1я в!,!ставляет заказчику счет за предосгавлс!1Ные услуги, то этот вопрос также должен быть отражс!! в SLA. Это мог>т быть од!!оразовь!е платежи или !!латежи за спе1Ц1алы!ые или дополнительные услуги. У1!равление ф1!!!ансами предоставляет Пр0!(сссу У!!равления УровР!ем Сервиса !1нфо1)ма!П11о о затратах на предоставление услу!, а также пн(})ормацию о методах и уро!)нях оплаты, !!еобход!1Мых для покрытия затрат иа предоставление услуг

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

Ниже дается подроб1и)е оп!1сан!!е эта!10в процесса, включая последо!1а!е7!Ы!ость дсйст!И1Й и виды работ.

10.4.1. Идентификация

По мере ус1и!ения зависимости бизнеса от ИТ-сервисов возрастает C!ipoc иа высококачестве!ПП)1е ИТ-услу1и. Пр!1емлемость качесчва услуги определяется ожиданиями заказчика, пос1оя!1НЬ!м упра-в.!ением этими ожидап!1ЯМ11, стабилы!остыо услуги и приемлемость!0 Уровня Расходов. Поэтому са-м!)1Й лучший С!!Особ обес!1счить соотве!СТву10!!1ий уровень Качества - обсужде1!ие этого вопроса с самим заказчи!<:ом.

Опыт показывает, что часто заказчики сами пе мо!ут четко опредеЛ!1ть свои ожидания, они просто прел!10ла!ают, что им будут предоставле!1ы некоторые услуги без каких-;!!1бо определеншлх до1-ово-реп1!0стей. Такое 1юс11рият!1е заказчиком npo!iecca прсдоставле!П1я ycjiy!- часто приводит к серьез-!!Ому !!сдопоп!1манию. И ЭТО еще раз !10дтверждает, насколько необходимо Руководителю Процесса Управления Уров!1ем CepBirca хорошо знать своих заказчиков, чтобы !1омочь разобрат!зСЯ, какие Услуги и 1!а каком Уро!П1е им fleilCTBHTCJibno 1!еобходпмы и с каким Уровнем Затрат.

Требо!1а1П1Я заказчиков должпы быть представлены в 1!0ддаю1!П1хся измерению 31!ачеииях, с тем чтобы можно б!)1ло их использовать !ip!i разработке и мопиторин!е ИТ-услуг Если л!етрик!-! пе coi-ласо-ва1!Ь! с заказчи!том, то !!ельзя будет 1троверить, насколько )слу!"и соот!1етству!от лости!Т1утым до1о-ворениостям. Процесс Управления Уровнем Сервиса играет ключеву!о \юлъ в п0!П1маиии и ог!реде-ле!П!и пожеланий заказчика.

ricpBiiiM iiiaroM к за!сл!Очснию Согла!!!епия о предоставляемых в настоящий момент или в буду!1ем ИТ-услугах должпь! стать идентифика!И!я и определение пот-реб!1остей заказчика в виде Требований к Уровню Услуг (Service Level Requirements - SLR). Помимо вы!10лиения это1-о вида деятель-HOCTI! в самом !1ачале данного !ipo!iecca, рекоме!1дуется делать это регуляр!!0 по за!!росам заказчика или но 1пи1циативе самой ИТ-организации и охватывать ею как новые, так и уже существую-иц1е услуги.



tо IFABAt-rHME VPOtiihSf M CFPBNCA (УСЛУГ)

10.4.2. Определение

0111)елслс1те области (диапазона) и глу6гны трсбоаапий заказчика рассматрпнается как процесс дпза1п1а (разработки) в рамках Процесса Управлешш Уровнем Сервисов. Согласно модели обеспечения качества стандарта ISO 9001 общий процесс дизайна состоит из следующих этапов: гобствеи-но дпза1"п, 1)азработка, ппста.мляцпя и соп]ЮВождснпс. Для того чтобы результаты выполнения иро-цссса дизайна отвечали т])ебоваииям заказчика, им необходимо управлять. Па протяжеппи всего процесса дизайна терлтн «внепчний» используется в othohichihi взаимоотнонгеннй с заказчиком, а «внут1зенппй» - с техничесгсоГ! по/щержкой внутри ИТ-оргаипзацпи. Процесс дигшйпа включает в себя таги, )1ачиная с дстализатш трсбовант! заказчика и оиределе)И1я нх в качестве стандартов и :!аканчипая раз[)абогкой технических условий для нредоставлешгя услуг

Определение внспншх стандартов

Первым этаном в с:оставленин количественного описапия- новых или существуюищх ИТ-услуг является определение или «переопределение» ожиданий заказчика в отношенш! услуг в целом. Ожидания заказчика формализуются в Требованиях к Уровню Услуг (SLR), в разработке kotojibix участвует вся организация заказчика. Обычно этот этан считается самой трудной частью Процесса Управления Уровнем Сервисов. Перед началом данного этапа Руководитель Процесса должен подгото-втгться к встрече с н])едс1ав1гтелями заказчика. Первым вопросом, которьи! следует задать, является: «Какой 14Т-сервис требуется и из каких элементов оп должен состоять?» Предоставлепие сервиса может повлечь за собой использование определенной части инфраструктуры, напри.мер, такой как -лобальиая сеть (Wide Area Network - WAN). Этот сервис может быть частью составной/сложной услу1-и, такой как доступ ко всей ин(1юрмациоипой системе, вк;ночая всю инфраструктуру (WAN, LAN, рабочие ставшие, приложеиия и т. д.).

Учасгвуюпте в ;-)гих встречах пользователи должны быть поделены на группы. Руководитель Процесса Уи1авления Уровнем Сервиса составляет список групп пользователей, их требовашит и полно-мочи11. Следуютцая ип(1)ормация необходима для определения Требований к Уровню Услу)"

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

•время и дни, в которые сервис должен быть доступен;

•требования к непрерывности сервиса;

•ИТ-функ1Тпи, иеобходимьЕС лля предоставления сервиса;

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

•ссылки на Соглап1епие об Уровне Сервиса, которое должно быть модифицировано или замеиело там, где это необходимо.

Результатом этапа дизайна является документ, сол,ержаии1Й Требования к Уровню Услуг (Service Level Rcquiremcnt.s - SLR) и подписанный Руководителем Процесса п заказчиком. Эти требования еще кюжно менять, пока соответ-сгвуюнхее подразделение работает mvi разработкой услуги, внед1)еггием и ведет соответствуюптс ciaKyiiKH. Изменения могут касаться, например, целесооб[)азпости предполагае-мых фугп<1ни"1 и ожидаемых затрат. Каждое такое изменение должно утверждаться обеими сторонами.

Преобразование во внучренние стандарты

На этапе составления специ()икагпп1 Требования к Уровню Услуг конкретизируются. Результатом работы на этом этапе будет получение сяедующей информации:

•одпозиачиое и подробное описаппе ИТ-услуг и необходимых компонентов;

•спегтфпкация метода внедрения и предоставления сервисов;

•специс1)икация процедуры контроля требусмоп) Уровня Качества.

scope

- Quentrfyins.

composite service.



Руководство бизнесом

Внешние документы

•Требования к Уровню Услуг

•Соглашение об Уровне Услуг > Каталог Услуг

Внутренние документы

»таблицы спецификаций • Операционные Соглашения об Уровне Услуг > Внешние Договогзы

Контроль документов

ИТ-подразделение

Рис. 10.2. Этап составления спецификаций (источник: OGC)

На этапе составления специфпкаиии рекомендуется разграничивать вненитие и внутрстше документы (рис. 10.2). Спсцпфпкации для внешнего использования уточняют согласованные с заказчиком цели, и контроль процесса дизайна осушеств-чястся с учетом этих целей. "Кпсие спеттфикацип составляются совместно с орга1П1зацией заказчика, и они служат входной информацией для внутренних спецификации.

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

Таблицы спецификаций дают подробное оппсание того, что хочет заказчик (внсшнт"! элемент), и того, как пожелания заказчика отразятся на работе ИТ-организацтпт (внутреншгй элемент). Таблицы не обязательно должигл подписываться двумя сторонами, но все равно oini попадают в сферу деятельности по KoHTpojHO документов. Каталог услуг может составляться на основе специ({)икаций сервисов, поэтому любые изменения в Уровнях Услуг должны быть немедленно отражены в Таблице спецификаций и в Каталоге услуг Вслед за этим пересматривается Соглашипте об Уровне Сервиса в соответствии с измененными спецификациями.

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

Рекомендуется включать всю управленческую информацию (Ключевые показатели Э(1)фектпвности) и внутренние и внеинтие спецификации в единый докумеш- для получения полной информации о вюгаде каждого нроцесса Сервис-мснеджмента в ИТ-услугн.

Service Specificalions (Spec sheets).

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [ 43 ] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]