Управление конфигурациями
Цель процесса — оказание помощи в управлении экономическим значением (economic value) ИТ — сервисов (комбинация требований клиентов, качества и затрат) за счет поддержания логической модели инфраструктуры ИТ и ИТ — сервисов, а также предоставление информации о них другим бизнес-процессам. Это реализуется путем идентификации. мониторинга, контроллинга и обеспечения информации о Конфигурационных Единицах (КЕ) и их версиях. Владелец процесса — Change Manager. Важно не путать процессы Управление конфигурациями и Управление активами. Управление активами — учетный процесс для мониторинга аморизации активов. Процесс отвечает за поддержку записей в базе информации о цене, амортизации, подразделениях, владеющих этими активами. Управление конфигурациями — отвечает за поддержание информации о взаимоотношениях между КЕ и за стандартизцию КЕ. Процесс отвечает за мониторинг информации о статусе КЕ, их местоположении и всех изменениях КЕ.
Деятельность по обеспечению процесса:
- Планирование: определение стратегии, правил и целей для реализации процесса, определение инструментария и ресурсов, определение интерфейсов с другими процессами, проектами, поставщиками и т.д.
- Идентификация: Разработка модели данных для записи в базу конфигураций всех компонент инфраструктуры ИТ, отношений.между ними, а также информации о владельцах этих компонент, их статусе и соответствующей документации. Принципы идентификации вытекают из задач Управления сервисами. Например, если предъявляются требования к безопасности, то необходимо учитывать MAC- адрес. При выборе именования КЕ как правило рекомендуется, чтобы имя было логичным и неизменяемым. В качестве неудачного приводится пример имени персонального компьютера, которое включает в себя имя комнаты, где он находится: pcroom313. Для PC это может быть верно потому, что при переносе его в другую комнату, возникнет рассогласование с логикой построения. Либо имя менять, либо мириться с тем, что компьютер pcroom313 находится в комнате, например, 314. В то же время, для таких КЕ, как маршрутизатор, имя, отражающее местоположение разумно и рекомендуется Cisco: «We also recommend identifying DHCP ranges and adding them to the DNS, including the location of the users. This may be a portion of the IP address or a physical location. An example might be «dhcp-bldg-c21-10» to «dhcp-bldg-c21-253″, which identifies IP addresses in building C, second floor, wiring closet 1.» При возникновении инцидента имя маршрутизатора даст информацию необходимую для скорейшего восстановления сервиса.
- Общие рекомендации по соглашениям именования:
- наименования оборудования должны легко читаться и быть понимаемыми пользователями, бирки на нем должны быть надежно закреплены. Наименования должны быть согласованы с провайдерами, осуществляющими оутсорсинг и/или поставщиками третьих фирм.
- документы, находящиеся под контролем процесса (SLA, процедуры, рабочие инструкции и пр.) должны содержать указание на КЕ (номер версии, дату и т.п.)
- копии программного обеспечtния должны храниться в DSL — Definitive Software Library.
Очевидно, что при развитой инфраструктуре количество компонентов может быть очень велико и не все эти компоненты нужны для предоставления и поддержки сервисов. Поэтому необходимо определить «Сферу охвата (Scope)» и «Глубину детализации (Level of Detail)» для всего множества КЕ. Сфера охвата (Scope) определяет, какая часть инфраструктуры будет находиться под контролем процесса. Например, мы можем охватывать только сервера и маршрутизаторы. Правильный выбор Сферы охвата очень важен на начальном этапе внедрения процесса Управление конфигурациями. Глубина детализации (Level of Detail) — важный аспект, определяющий в дальнейшем отношения между КЕ. Отношения, как правило рассматриваются следующие: физические («родители — дети», «соединенная») и логические («копия» и «использует», когда одна единица использует другую).
- Контроль: Это означает, что процесс контролирует все изменения КЕ, кем бы они не производились (например процессами Change Management или Incident Management).
- Мониторинг статуса: В процессе жизни статус КЕ может меняться от «заказано» до «исключено из конфигурации». Задача процесса отслеживать реальный статус КЕ, содержащихся в базе.
- Верификация: Насколько информация в базе конфигураций соответствует реальности?
- Отчеты: Отчеты руководству и другим процессам для осуществления их эффективного выполнения.
Возможные трудности при внедрении:
- распределение ответственностей внутри организации;
- выбор КЕ;
- попытки обойти процедуры, установленные процессом;
- трудности верификации.
10.1. Введение
Управление Уровнем Сервиса (Услуг) – это процесс, в рамках которого происходят переговоры по вопросам предоставления услуг, производится определение, измерение (оценка), управление и улучшение качества ИТ-услуг при соблюдении приемлемого Уровня Затрат. Все эти задачи должны решаться в условиях быстро меняющихся потребностей бизнеса и быстро развивающихся технологий. Процесс Управления Уровнем Сервиса помогает найти нужный баланс между предложением и спросом на услуги требуемого Уровня Качества, их легкостью в использовании и стоимостью. И поставщик, и заказчик должны четко осознавать, что услуги не только поставляются, но и используются. Это понимание реализуется в разработке, согласовании и выполнении Соглашений об Уровне Услуг[156] (SLA), Операционных Соглашений об Уровне Услуг[157] (OLA), Внешних Договоров[158] (UC) и Плана Обеспечения Качества Услуг[159] (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. Процесс Управления Уровнем Сервисов
В рамках Процесса Управления Уровнем Сервиса выполняются следующие виды деятельности:
• Идентификация – идентификация потребностей заказчика, управление взаимоотношениями и внутреннее продвижение[160] ИТ-организации. Понимание бизнес-процессов и потребностей заказчика.
• Определение – определение требуемых услуг в соответствии с потребностями и запросами заказчика. Услуги определяются в виде Требований к Уровню Услуг и Таблиц спецификаций услуг. Результатом выполнения этого вида работ является создание Плана обеспечения качества услуг.
• Окончательное оформление соглашения – заключительный этап работы над соглашением, т. е. обсуждение с заказчиком требуемого Уровня Сервисов и связанных с этим затрат, закрепление достигнутых договоренностей в Соглашении об Уровне Сервиса (SLA). Подкрепление соглашения SLA Операционными Соглашениями об Уровне Услуг (OLA) и Внешними Договорами (UC). Составление или обновление Каталога Услуг с указанием в нем доступных для заказчиков услуг.
• Мониторинг – мониторинг Уровней Сервисов.
• Отчетность – составление Отчетов об Уровне Сервисов. Регулярное предоставление отчетов заказчику и ИТ-организации о реальных текущих Уровнях Предоставления Услуг в сравнении с общим достигнутым Уровнем (Service Level Achievement).
• Анализ (пересмотр) – совместный с заказчиком анализ сервисов с целью определения направлений его улучшения. Возможно инициирование Программы улучшения сервиса, если это необходимо. Деятельность включает в себя частые контакты с заказчиком и обмен мнениями о предоставляемых услугах. Результатом такого вида деятельности может стать новое или пересмотренное Соглашение об Уровнях Сервиса.
Для эффективной работы Процесса Управления Уровнем Сервиса требуется наличие других Процессов Поддержки и Предоставления услуг. Все эти процессы в определенной степени содействуют успешному Управлению Уровнем Сервисов. При определении услуги и соответствующего Уровня предоставления необходимо учитывать степень развития Процессов Поддержки Услуг. Ниже дается общее описание взаимоотношений Управления Уровнем Услуг с другими процессами.
Взаимоотношения со Службой Service Desk
Хотя Служба Service Desk является функцией (функциональным подразделением), а не процессом, ее взаимосвязь с Процессом Управления Уровнем Сервиса является особенно важной. Служба Service Desk является начальной точкой контактов для пользователей, и ее цель в случае возникновения сбоя – восстановить согласованный Уровень Предоставления Услуг как можно скорее посредством Процесса Управления Инцидентами. Поскольку данная служба напрямую контактирует с пользователями, она может предоставить ценную информацию об их восприятии Уровня Сервисов (степени удовлетворенности). Обычно существует сильная зависимость между степенью удовлетворенности пользователя и заказчика. Служба Service Desk также играет важную роль в определении времени реагирования и времени разрешения при возникновении сбоя в предоставлении сервисов.
Взаимоотношения с Процессом Управления Доступностью
Процесс Управления доступностью отвечает за реализацию и оптимизацию доступности услуг. Управление Уровнем Сервиса предоставляет Процессу Управления доступностью входную информацию о требуемом Уровне Доступности ИТ-услуг, и этот процесс, в свою очередь, дает Управлению Уровнем Услуг информацию о реально существующем Уровне Доступности ИТ-сервисов.
Взаимоотношения с Процессом Управления Мощностями
Задача Процесса Управления Мощностями – управлять мощностями и пропускной способностью ИТ-инфраструктуры. Для этого создается План мощностей (Capacity Plan), который детализирует текущее использование инфраструктуры и прогнозирует ее будущее использование. Содействие Процесса Управления Мощностями состоит в том, что он предоставляет Управлению Уровнем Сервиса информацию о степени воздействия новой услуги или расширения уже имеющейся услуги на общий Уровень ИТ-мощностей, а также о том, находится ли потребление конкретной услуги в заранее согласованных пределах.
Управление Уровнем Услуг предоставляет Процессу Управления Мощностями информацию об ожидаемом текущем и будущем Уровне Использования Услуги, которое уже согласовано или будет согласовано с заказчиком.
Взаимоотношения с Процессами Управления Инцидентами и Проблемами
Процессы Управления Инцидентами и Проблемами являются хорошими индикаторами эффективной реализации соглашений SLA. В частности, Процесс Управления Инцидентами играет особенно важную роль в скорейшем восстановлении услуг после возникновения сбоя.
Процесс Управления Проблемами помогает оптимизировать стабильность услуг благодаря постоянно предпринимаемым им мерам по предотвращению возникновения ошибок.
Наличие механизмов разрешения инцидентов и проблем является необходимым условием для предоставления высококачественных услуг. Процесс Управления Уровнем Сервиса использует информацию из этих процессов при составлении своих отчетов заказчику.
Взаимоотношения с Процессом Управления Изменениями
В соглашении SLA могут быть определены изменения, которые запрашивает организация заказчика, и соглашения, которые будут регулировать эти изменения (кому изменения адресованы, какое время цикла, затраты, способы информирования организации и т. д.). Изменение может повлиять на уже согласованные Уровни Сервисов.
Взаимоотношения с Процессом Управления Релизами
Многие ИТ-услуги состоят в предоставлении аппаратного обеспечения вместе со сделанным на заказ или готовым программным обеспечением. Процесс Управления Релизами ведет мониторинг соглашений, заключенных в рамках Процесса Управления Уровнем Сервисов, о предоставлении аппаратного и программного обеспечения. Процесс Управления Уровнем Сервиса подготавливает отчеты о качестве ИТ-сервисов на основе информации, получаемой из отчетов Процесса Управления Релизами.
Взаимоотношения с Процессом Управления Непрерывностью ИТ-услуг
Процесс Управления Непрерывностью ИТ-услуг отвечает за быстрое восстановление ИТ-сервисов в случае катастрофы, а также он ведет мониторинг действий и процедур, необходимых для осуществления этого восстановления. Соглашения с заказчиком по данным вопросам заключаются в рамках Процесса Управления Уровнем Сервисов. Предпринимаемые в случае бедствия меры и связанные с ними затраты затем входят составной частью в Соглашение об Уровне Сервиса. Также может быть достигнута договоренность, что в случае чрезвычайных обстоятельств некоторые ИТ-сервисы не будут использоваться или будут временно сокращены.
Изменения в услуге и связанном с ней соглашении SLA могут потребовать модификации уже разработанных мер и процедур по обеспечению непрерывности услуг.
Взаимоотношения с Процессом Управления Безопасностью
Для эффективно действующего Процесса Управления Уровнем Сервиса большое значение могут иметь меры безопасности, связанные с ИТ-сервисом. Как у ИТ-организации, так и у заказчика могут быть определенные требования к безопасности. Соответствующие договоренности определяются в рамках Соглашения об Уровне Сервиса. Управление безопасностью гарантирует, что принимается согласованные меры безопасности, ведется их мониторинг и составляются отчеты для Процесса Управления Уровнем Сервисов.
Взаимоотношения с Процессом Управления Конфигурациями
Процесс Управления Конфигурациями отвечает за ввод детальной информации о компонентах услуг (Конфигурационных Единицах) и документации (Соглашений об Уровне Сервиса – SLA) в Конфигурационную Базу Данных (CMDB) и предоставление информации из этой базы. Поэтому создание или модификация услуги или соглашения влечет за собой изменения в CMDB. Служба Service Desk использует Конфигурационную Базу Данных для определения степени воздействия сбоев на услуги и для получения информации из соглашений SLA о времени реагирования и времени разрешения сбоев. Информация из CMDB также используется при составлении отчетов о качестве Конфигурационных Единиц, что позволяет Процессу Управления Уровнем Сервиса подготавливать отчеты о качестве предоставляемых услуг.
Взаимоотношения с Процессом Управления Финансами ИТ
Если ИТ-организация выставляет заказчику счет за предоставленные услуги, то этот вопрос также должен быть отражен в SLA Это могут быть одноразовые платежи или платежи за специальные или дополнительные услуги. Управление финансами предоставляет Процессу Управления Уровнем Сервиса информацию о затратах на предоставление услуг, а также информацию о методах и уровнях оплаты, необходимых для покрытия затрат на предоставление услуг.
10.4. Виды деятельности
Ниже дается подробное описание этапов процесса, включая последовательность действий и виды работ.
10.4.1. Идентификация
По мере усиления зависимости бизнеса от ИТ-сервисов возрастает спрос на высококачественные ИТ-услуги. Приемлемость качества услуги определяется ожиданиями заказчика, постоянным управлением этими ожиданиями, стабильностью услуги и приемлемостью Уровня Расходов. Поэтому самый лучший способ обеспечить соответствующий Уровень Качества – обсуждение этого вопроса с самим заказчиком.
Опыт показывает, что часто заказчики сами не могут четко определить свои ожидания, они просто предполагают, что им будут предоставлены некоторые услуги без каких-либо определенных договоренностей. Такое восприятие заказчиком процесса предоставления услуг часто приводит к серьезному недопониманию. И это еще раз подтверждает, насколько необходимо Руководителю Процесса Управления Уровнем Сервиса хорошо знать своих заказчиков, чтобы помочь разобраться, какие Услуги и на каком Уровне им действительно необходимы и с каким Уровнем Затрат.
Требования заказчиков должны быть представлены в поддающихся измерению значениях, с тем чтобы можно было их использовать при разработке и мониторинге ИТ-услуг. Если метрики не согласованы с заказчиком, то нельзя будет проверить, насколько услуги соответствуют достигнутым договоренностям. Процесс Управления Уровнем Сервиса играет ключевую роль в понимании и определении пожеланий заказчика.
Первым шагом к заключению Соглашения о предоставляемых в настоящий момент или в будущем ИТ-услугах должны стать идентификация и определение потребностей заказчика в виде Требований к Уровню Услуг (Service Level Requirements – SLR). Помимо выполнения этого вида деятельности в самом начале данного процесса, рекомендуется делать это регулярно по запросам заказчика или по инициативе самой ИТ-организации и охватывать ею как новые, так и уже существующие услуги.
10.4.2. Определение
Определение области (диапазона)[161] и глубины требований заказчика рассматривается как процесс дизайна (разработки) в рамках Процесса Управления Уровнем Сервисов. Согласно модели обеспечения качества стандарта ISO 9001 общий процесс дизайна состоит из следующих этапов: собственно дизайн, разработка, инсталляция и сопровождение. Для того чтобы результаты выполнения процесса дизайна отвечали требованиям заказчика, им необходимо управлять. На протяжении всего процесса дизайна термин «внешний» используется в отношении взаимоотношений с заказчиком, а «внутренний» – с технической поддержкой внутри ИТ-организации. Процесс дизайна включает в себя шаги, начиная с детализации требований заказчика и определения их в качестве стандартов и заканчивая разработкой технических условий для предоставления услуг.
Определение внешних стандартов
Первым этапом в составлении количественного описания[162] новых или существующих ИТ-услуг является определение или «переопределение» ожиданий заказчика в отношении услуг в целом. Ожидания заказчика формализуются в Требованиях к Уровню Услуг (SLR), в разработке которых участвует вся организация заказчика. Обычно этот этап считается самой трудной частью Процесса Управления Уровнем Сервисов. Перед началом данного этапа Руководитель Процесса должен подготовиться к встрече с представителями заказчика. Первым вопросом, который следует задать, является: «Какой ИТ-сервис требуется и из каких элементов он должен состоять?» Предоставление сервиса может повлечь за собой использование определенной части инфраструктуры, например, такой как глобальная сеть (Wide Area Network – WAN). Этот сервис может быть частью составной/сложной услуги[163], такой как доступ ко всей информационной системе, включая всю инфраструктуру (WAN, LAN, рабочие станции, приложения и т. д.).
Участвующие в этих встречах пользователи должны быть поделены на группы. Руководитель Процесса Управления Уровнем Сервиса составляет список групп пользователей, их требований и полномочий. Следующая информация необходима для определения Требований к Уровню Услуг:
• описание функций, которые должен предоставить запрашиваемый сервис, с точки зрения заказчика;
• время и дни, в которые сервис должен быть доступен;
• требования к непрерывности сервиса;
• ИТ-функции, необходимые для предоставления сервиса;
• ссылки на текущие операционные методы и стандарты качества, которые должны учитываться при определении сервиса;
• ссылки на Соглашение об Уровне Сервиса, которое должно быть модифицировано или заменено там, где это необходимо.
Результатом этапа дизайна является документ, содержащий Требования к Уровню Услуг (Service Level Requirements – SLR) и подписанный Руководителем Процесса и заказчиком. Эти требования еще можно менять, пока соответствующее подразделение работает над разработкой услуги, внедрением и ведет соответствующие закупки. Изменения могут касаться, например, целесообразности предполагаемых функций и ожидаемых затрат. Каждое такое изменение должно утверждаться обеими сторонами.
Преобразование во внутренние стандарты
На этапе составления спецификаций Требования к Уровню Услуг конкретизируются. Результатом работы на этом этапе будет получение следующей информации:
• однозначное и подробное описание ИТ-услуг и необходимых компонентов;
• спецификация метода внедрения и предоставления сервисов;
• спецификация процедуры контроля требуемого Уровня Качества.
Рис. 10.2. Этап составления спецификаций (источник: OGC)
На этапе составления спецификации рекомендуется разграничивать внешние и внутренние документы (рис. 10.2). Спецификации для внешнего использования уточняют согласованные с заказчиком цели, и контроль процесса дизайна осуществляется с учетом этих целей. Такие спецификации составляются совместно с организацией заказчика, и они служат входной информацией для внутренних спецификаций.
Внутренние спецификации согласуются с внутренними целями ИТ-организации, достижение которых означает удовлетворение потребностей заказчика. Разграничение между внутренними и внешними спецификациями может оказаться особенно полезным уже после того, как Процесс Управления Уровнем Сервиса запущен в работу. При таком подходе ИТ-организация не будет беспокоить заказчика различными техническими вопросами. Начиная с этого момента, Управление Уровнем Сервиса означает стремление поддерживать соответствие внутренних спецификаций внешним. Этому содействуют выполнение таких действий, как Контроль документов и Внутренний анализ (ревью), в ходе которых ведется регистрация относящихся к данному вопросу документов, управление версиями и организуются регулярные аудиторские проверки.
Таблицы спецификаций[164] дают подробное описание того, что хочет заказчик (внешний элемент), и того, как пожелания заказчика отразятся на работе ИТ-организации (внутренний элемент). Таблицы не обязательно должны подписываться двумя сторонами, но все равно они попадают в сферу деятельности по Контролю документов. Каталог услуг может составляться на основе спецификаций сервисов, поэтому любые изменения в Уровнях Услуг должны быть немедленно отражены в Таблице спецификаций и в Каталоге услуг. Вслед за этим пересматривается Соглашение об Уровне Сервиса в соответствии с измененными спецификациями.
План обеспечения качества услуг (Service Quality Plan – SQP)
Рекомендуется включать всю управленческую информацию (Ключевые показатели эффективности) и внутренние и внешние спецификации в единый документ для получения полной информации о вкладе каждого процесса Сервис-менеджмента в ИТ-услуги.
10.4.3. Договор
После завершения этапа составления спецификаций, ИТ-организация трансформирует бизнес-потребности в ИТ-ресурсы и Конфигурационные Элементы. Далее эта информация будет использована для составления или модификации следующих документов.
Соглашение об Уровне Сервиса
При разработке структуры данного документа вначале рекомендуется определить общие аспекты, такие как сетевые услуги для всей компании, и разработать общую сервисную модель соглашений до начала переговоров с заказчиком. Соглашение может иметь иерархическую структуру, аналогичную структуре организации заказчика, и может быть представлено в виде рамочного соглашения с определенным количеством иерархических уровней. У каждого Уровня может быть своя степень детализации. Верхние Уровни отражают договоренности по общим услугам, предоставляемым всей организации. На Нижних Уровнях содержится информация, имеющая отношение к конкретным заказчикам.
Структура Соглашения об Уровне Услуг зависит от ряда переменных, таких как:
• Физические аспекты организации:
• Аспекты культуры:
— язык, на котором составляются документы (для международных организаций);
— взаимоотношения между ИТ-организацией и заказчиком;
— политика выставления счетов[165];
— тип организации: коммерческая или некоммерческая.
• Характер бизнес-деятельности:
— общие положения и условия;
— часы работы – 5×8 часов или 7×24 часа
Внешние Договоры и Операционные Соглашения об Уровне Услуг
Все имеющиеся Внешние Договоры (UC) и Операционные Соглашения об Уровне Услуг (OLA) должны быть пересмотрены на этапе дизайна. Участвующие в этой работе должны иметь информацию обо всех соглашениях OLA и договорах UC, которые относятся к предоставлению конкретной услуги. Ссылки в результате деятельности по Контролю документов могут помочь в уточнении связей с таблицами спецификаций.
Каталог услуг
При составлении Каталога услуг могут быть полезны следующие рекомендации:
• используйте язык заказчика. Избегайте технического жаргона и используйте терминологию из соответствующей области бизнеса;
• постарайтесь взглянуть на проблему с точки зрения заказчика и придерживайтесь такого подхода при сборе нужной информации;
• создайте привлекательный макет каталога, так как ИТ-организация использует этот документ для своей презентации заказчикам;
• постарайтесь сделать этот документ доступным для наибольшего количества потенциальных заинтересованных лиц, например, путем опубликования его на сайте сети Интранет или на CD-ROM.
10.4.4. Мониторинг
Мониторинг Процесса Управления Уровнем Сервиса можно проводить, только если Уровни Услуг заранее четко определены и соответствуют внешним целям. Также должна существовать возможность измерения Уровня Услуг с точки зрения заказчика. Мониторинг не должен ограничиваться техническими аспектами процесса, он также должен затрагивать процедурные вопросы. Например, до тех пор, пока пользователь не будет проинформирован о восстановлении сервиса, он будет считать его недоступным.
Процессы Управления доступностью и мощностями обычно предоставляют информацию о достижении технических целей, связанных с Уровнями Услуг. В некоторых случаях информация также поступает из Процессов Поддержки услуг, особенно от Процесса Управления Инцидентами. Однако недостаточно замерять только внутренние параметры, так как это не даст представления о восприятии услуг заказчиком. Поэтому необходимо замерять/оценивать и такие параметры, как время реагирования, время эскалации и время, затраченное на поддержку. Полное представление о процессе можно получить только путем объединения информации, получаемой как от систем, так и от Сервис-менеджмента.
10.4.5. Создание отчетов
Отчеты заказчику (отчеты о сервисах) должны предоставляться в сроки, оговоренные в Соглашении SLA В этих отчетах сравниваются фактически предоставляемые Уровни Сервисов с согласованными Уровнями. Примерами отчетов могут быть:
• доступность сервисов и время простоя в указанные периоды;
• среднее время реагирования в пиковые периоды;
• скорость транзакций в пиковые периоды;
• количество функциональных ошибок в ИТ-сервисе;
• частота и длительность периода деградации сервисов (Услуги не достигают согласованного Уровня);
• среднее количество пользователей в пиковые периоды;
• количество успешных и безуспешных попыток нарушить систему безопасности;
• количественное соотношение использованных мощностей[166] сервисов;
• количество завершенных и незавершенных (открытых) изменений;
• стоимость предоставленных услуг.
10.4.6. Анализ (ревью)
Уровень Сервисов нужно регулярно анализировать, уделяя при этом внимание следующим аспектам:
• Соглашению об Уровне Услуг с момента последнего анализа;
• проблемам, возникшим с услугами;
• выявлению тенденций работы услуг;
• изменению услуг в пределах Согласованных Уровней Сервиса;
• изменению процедур и расчетов стоимости дополнительных ресурсов;
• последствию сбоев при предоставлении Согласованных Уровней Услуг.
Если не удалось организовать предоставление ИТ-услуг на Согласованном Уровне, следует согласовать действия по исправлению ситуации, например:
• разработать Программу улучшения услуг (Service Improvement Program – SIP);
• выделить дополнительный персонал и ресурсы;
• изменить Уровни Сервисов, определенные в Соглашении SLA;
• модифицировать Соглашения OLA и Внешние Договоры UC.
Во многих организациях, в которых вводится Процесс Управления Уровнем Сервисов, ведутся обсуждения, требуется ли определение санкций в связи с несоблюдением договоренностей. Это трудный вопрос, поскольку Процесс Управления Уровнем Сервиса базируется на взаимодействии ИТ-подразделения с пользователями ИТ-услуг, часто в рамках одной организации. В такой ситуации, когда и ИТ-подразделение, и пользователи работают над достижением одних и тех же корпоративных целей, маловероятно, чтобы применение санкций и тем более денежных штрафов отвечало бы корпоративным интересам. Было бы намного разумнее, исходя из общих интересов, договориться о совместных мерах по предотвращению сбоев в предоставлении Согласованных Уровней Услуг. Тем не менее, возможно применение санкций в отношении внешнего поставщика. В этом случае, скорее всего, нужно заключать юридически обязывающий договор (Внешний Договор), а не Соглашение об Уровне Сервиса.
10.5. Контроль процесса
Для оптимизации процесса и его контроля следует определить ряд критических факторов успеха, а также показателей качества для оценки и улучшения процесса.
10.5.1. Критические факторы успеха и ключевые показатели эффективности
Успех Процесса Управления Уровнем Сервиса зависит от следующих факторов:
• наличия Руководителя Процесса, обладающего знаниями как в области информационных технологий, так и в области бизнеса;
• четкости в формулировании целей процесса и роли процесса;
• проведения оповещения, в ходе которого люди получат информацию о процессе, будет достигнуто его понимание и поддержка с их стороны;
• четкости поставленных задач, полномочий и ответственностей в рамках процесса, разграничения контроля процесса и операционных задач (контактов с заказчиками).
Приведенные ниже показатели качества можно использовать для определения эффективности и результативности[167] Процесса Управления Уровнем Сервисов:
• параметры сервисов, включенные в Соглашения SLA;
• параметры Соглашения SLA, поддерживаемые Операционным Соглашением об Уровне Услуг (OLA) и Внешними Договорами (UC);
• параметры Соглашений SLA, за которыми ведется мониторинг, и о недостатках которых составляются отчеты;
• параметры Соглашений об Уровне Сервиса, которые регулярно анализируются;
• параметры Соглашений об Уровне Сервиса, для которых удалось достичь согласованных уровней сервиса;
• выявленные недостатки, включенные в план улучшений;
• действия, предпринятые по исправлению указанных недостатков;
• выявленные тенденции с учетом реального Уровня Сервиса.
10.5.2. Отчеты руководству[168]
Отчеты руководству в отличие от Отчетов об Уровне Сервисов предназначены не для заказчика, они нужны для целей контроля или Управления Процессом. В них могут входить метрики о реально существующих Уровнях Сервисов и сведения о тенденциях, например:
• количество заключенных Соглашений SLA;
• количество случаев несоблюдения заключенных соглашений SLA;
• стоимость оценки и мониторинга Соглашений SLA;
• степень удовлетворенности заказчиков, определяемая по результатам опросов;
• статистические данные об инцидентах, проблемах и изменениях;
• результаты предпринимаемых действий по улучшению сервисов.
10.5.3. Функции и роли
Контроль за Процессом Управления Уровнем Сервиса осуществляет Руководитель Процесса. Он должен обеспечить эффективность процесса и достижение заданных результатов. Это не обязательно означает, что роль Руководителя Процесса обязательно исполняет один человек. Во многих организациях есть несколько Руководителей Процесса Управления Уровнем сервисов, каждый из которых отвечает за одну или несколько услуг или групп заказчиков.
Ответственность
Руководитель Процесса Управления Уровнем Сервиса отвечает за:
• создание и обновление Каталога Услуг;
• создание и поддержание эффективного Процесса Управления Уровнем Сервисов, включая:
• определение структуры Соглашения об Уровне Сервиса;
• заключение Операционных Соглашений об Уровне Услуг с Внутренними Поставщиками;
• заключение Внешних Договоров с Поставщиками;
• обновление существующей Программы улучшения услуг;
• ведение переговоров с заказчиками, заключение и поддержка Соглашений об Уровне Сервиса, Операционных Соглашений об Уровне Услуг и Внешних Договоров;
• анализ качества работы ИТ-организации и улучшение качества по мере необходимости.
10.6. Проблемы и затраты
10.6.1. Проблемы
В процессе работы могут возникнуть следующие проблемы:
• В результате внедрения Процесса Управления Уровнем Сервиса установились деловые отношения с заказчиком, что требует привлечения всего ИТ-персонала к работе по заключенным соглашениям. В этой ситуации, возможно, потребуется изменение корпоративной культуры в компании.
• Заказчикам может потребоваться помощь в составлении Требований к Уровню Сервисов.
• Может оказаться очень трудным представить ожидания заказчиков в виде поддающихся оценке стандартов и конкретных цифр расходов.
• Руководитель Процесса должен быть умеренным и реалистичным в своих обещаниях при обсуждении соглашений, пока не будут разработаны инструментарии, процедуры, План обеспечения качества услуг (SQP) и Внешние Договоры. Лучше придерживаться стратегии постепенных улучшений.
• Легко ошибиться в расчетах накладных расходов, связанных с мониторингом и оценкой Уровней Сервисов. В больших организациях может потребоваться отдельный персонал на выполнение этих видов работ.
• На практике многие ИТ-организации приступают к составлению проекта Соглашения об Уровне Сервиса, пропуская этап анализа требований заказчика, этап дизайна и разработки Плана обеспечения качества сервисов (SQP). Это может привести к возникновению процесса, которым трудно управлять и у которого нет четких, поддающихся оценке стандартов.
• Документы, появляющиеся в рамках Процесса Управления Уровнем Сервиса и сам процесс могут стать самоцелью вместо достижения цели процесса – стать средством установления хороших отношений между заказчиком и поставщиком ИТ-сервисов.
10.6.2. Затраты
Расходы, связанные с внедрением Процесса Управления Уровнем Сервисов, можно разделить на следующие категории:
• расходы на персонал (Руководитель Процесса и команда проекта);
• расходы на обучение;
• расходы на документацию;
• расходы на помещение, аппаратное и программное обеспечение;
• расходы на операционные виды деятельности, связанные с обновлением Плана Обеспечения Качества Сервисов (SQP), Соглашений об Уровне Сервиса и Каталога Услуг.
Примечания:
ITIL является зарегистрированной торговой маркой агентства CCTA/OGC
Период времени, который требует планирования. – Прим. ред.
Service Level Agreements – SLA.
Operational Level Agreements – OLA.
Underpinning Contracts – UC.
Service Quality Plan – SQP.
Услуги интеллектуальной сети
В рекомендациях ITU-T Q.1211 различают два термина «service» — услуга, и «service feature» — компонент (свойство) услуги.
Согласно Q.1290 услугой является самостоятельное коммерческое предложение, характеризуемое одним или более компонентами (возможностями), открытыми для дополнения. Компонент услуги является ее специфической частью, который в совокупности с другими услугами и компонентами услуг может составлять часть самостоятельного коммерческого предложения, определяя составляющую, которая может быть различима пользователем.
Согласно Q.1211 набор CS-1 включает 25 видов услуг, которые должны поддерживаться сетями PSTN, ISDN и PLMN. Наиболее распространенные сегодня виды услуг представлены в таблице 3, где кроме англоязычного термина и аббревиатуры даются их значения и краткие пояснения.
Следует отметить, что определение набора услуг является одним из первых этапов при создании ИС в конкретном регионе и зависит от требований, сложившихся на местном рынке услуг связи.
Табл.3. Услуги набора CS-1
Аббревиатура
Automatic Alternative Billing (Автоматический альтернативный биллинг)
Предоставляет возможность вести учет стоимости разговора с любого ТА с помощью специальной системы биллинга, не имеющей отношения к линиям вызывающего и вызываемого абонентов.
Abbreviated Dialing (Сокращенный набор)
Услуга предоставляет пользователю осуществление вызова, используя, например, номер из 4-х цифр, даже в том случае, когда вызывающий и вызываемый абоненты обслуживаются разными коммутаторами.
Account Card Calling (Вызов по предоплаченной карте)
Предоставляет возможность оплачивать разговор с любого ТА с помощью счета, указываемого набором дополнительного номера.
Credit Card Calling (Вызов по кредитной карте)
Позволяет выполнять любые вызовы с любого ТА, оплачивая их по кредитной карте.
Call Distribution (Распределение вызовов)
Дает возможность направлять вызовы на другие номера в соответствии с программой переадресации и приоритетами.
Call forwarding (Направленный вызов)
Пользователь может направлять поступившие к нему вызовы на терминал с другим номером. Включение и отключение услуги осуществляется самим пользователем.
Conferencing (Телефонная конференция)
Услуга позволяет нескольким абонентам принять участие в одном разговоре.
Call Rerouting Distribution (Перемаршрутизация вызова)
Позволяет получать все входящие вызовы даже при занятом номере или других трудностях с установлением соединения (все вызовы, включая пейджерные сообщения и электронную почту, переводятся на другой номер и ставятся на автоответчик или в очередь).
Follow-me diversion (Функция «следуй за мной»)
Позволяет сохранить доступ к абоненту при его перемещении.
Freephone (Бесплатный вызов)
Бесплатная телефонная служба, или «свободный телефон». Разговор при данном типе вызова состоится, если вызываемый абонент согласится его оплатить (в США эта услуга называется «Служба 800»).
Mass Calling (Опрос населения)
Позволяет проводить опросы населения по телефону. Абонент после вызова слышит объявление и просьбу набрать одну из нескольких цифр на телефоне, чтобы выразить свое предпочтение. Все ответы регистрируются.
Malicious Call Identification (Идентификация вызова злоумышленников)
Позволяет выявить злоумышленников, записывая коды вызывающего и вызываемого абонентов и время вызова, удерживая вызов и сообщая оператору.
Originating Call Screening (Ограничение исходящей связи)
Дает возможность вводить ограничения на исходящую связь в определенное время или в соответствии с другими условиями.
Premium Rate (Приплата, передача части оплаты вызываемому абоненту)
Позволяет пользоваться информационными услугами с дополнительной оплатой (часть стоимости вызова оплачивает вызывающая сторона, выступающая в роли поставщика дополнительной услуги, т.е пользователь оплачивает стандартные телефонные услуги и дополнительные услуги. В США эта услуга называется «Служба 900»).
Split charging (Перераспределение оплаты)
Позволяет распределять оплату за разговор между абонентами.
Televoting (Телефонное голосование)
Дает возможность посылать вызов на конкретный номер с последующим речевым сообщением или дополнительным набором определенного кода.
Virtual Private Network (Виртуальная частная сеть)
Часть имеющихся линий связи и коммутаторов объединяются в частную сеть, функционирование которой определяется пользователем, в том числе номера для пользователей этой сети, их права и приоритеты, маршрутизация вызовов и т.д.
Universal Access Number (Универсальный номер)
Данная услуга дает возможность пользователю, имеющему несколько географически распределенных терминальных устройств, быть доступным другим пользователям по единому универсальному номеру в соответствии с определенной им маршрутизацией входящих вызовов.
Universal Personal Telecommunication (Универсальная персональная связь)
Позволяет абоненту пользоваться входящей и исходящей связью по единому номеру при его перемещении вне зависимости от сетевой инфраструктуры и местоположения.
Описание некоторых услуг набора CS-1
Набор услуг 1 ИС (CS-1, SC1) — общим числом 25 услуг и 38 свойств (основополагающих и вспомогательных), которые имеют две общие характеристики:
- услуга вызывается единственным пользователем (single ended);
- выполнение услуги контролируется единственной точкой контроля услуги (single control).
Ниже приведено описание наиболее часто используемых услуг ИС, вошедших в набор СS-1:
- Услуга «800» (Freephone, FPH)
- Услуга «Вызов по предоплаченной карте» (Account Card Calling, ACC)
- Услуга «Вызов по кредитной карте» (Credit Card Calling, CCC)
- Услуга «Приплата» (Premium Rate, PRM)
- Услуга «Виртуальная частная сеть» (Virtual Private Network, VPN)
- Услуга «Телеголосование» (VOT)
Глобальная функциональная плоскость Вторая плоскость модели — глобальная функциональная плоскость (GFP) согласно Q.1203 включает следующие основные элементы:
- базовый процесс обработки вызовов (BCP);
- независимые от услуг конструктивные блоки (SIB);
- точки инициации (POI) и точки завершения (POR).
Блоки SIB обеспечивают выполнение стандартных многократно используемых сетевых функций. Базовый процесс обработки вызовов является специализированным SIB, который взаимодействует с другими блоками посредством точек инициации и завершения. Если в процессе обработки вызова встретится одна из точек инициации, то это приводит к определенной последовательности обращений к блокам SIB. По завершении этой последовательности обращений осуществляется воздействие на процесс обработки вызова, зависящее от точки завершения. В результате такого взаимодействия может быть обеспечена услуга или компонент услуги. Таким образом, BCP описывает процесс обработки вызовов базовой сети связи из которой осуществляется запрос на услуги IN. Определенные на первом уровне INCM, услуги декомпозируются на компоненты и на плоскости GFP, объединяются в один или несколько SIB, которые при взаимодействии определяют глобальную логику услуги GSL (Global Service Lojic). На рисунке 12 показан процесс взаимодействия GSL и BCP осуществляемый через точки POI и POR.
Рис.12. Взаимодействие GSL и BCP В таблице 4 дано определение точек инициации и завершения для набора услугCS-1. Для обеспечения услуг, определенных в CS-1, необходимо наличие в IN блоков SIB, определенных в таблице 5. Выполняемые блоками SIB операции и данные, необходимые для их выполнения, специфицированы в рекомендации ITU-T Q.1213. Заметим, что Европейский институт стандартов электросвязи (ETSI) требует наличия в IN дополнительно еще семи блоков SIB. Распределенная функциональная плоскость На уровне третьем INCM (плоскость DPF) общесетевые функции определены в виде отдельных функциональных объектов (FE). Специфицированные на плоскости GFD блоки SIB реализуются на плоскости DFP в виде последовательности функциональных объектов (FEA), в результате выполнения которой возникают информационные потоки IF (Information Flows). В CS-1 определено 60 различных IF, соответствующих процедурам прикладного протокола INAP. Узлы ИС, как правило, выполняют одну или несколько функций, которые делятся на три основные категории: функции, относящиеся к управлению вызовом, функции, относящиеся к управлению услугами и функции, обеспечивающие услуги (эксплуатационная поддержка и администрирование сети). Данные функции определены в таблице 6. Функция коммутации услуг SSF тесно связана с функцией управления вызовом CCF. Обычно считается, что эти две функции образуют единый пакет SSF/CCF. Запрос на услугу как правило заключается в снятии трубки телефона и набору некоторого количества цифр. Роль функции коммутации услуг заключается в том, чтобы зафиксировать вызов и сформировать стандартный запрос. Функция управления вызовом не «интеллектуальна», но запрограммирована так, чтобы распознать запрос на услугу и послать его функции управления услугами SCF. Функция управления услугами SCF декодирует полученный запрос и интерпретирует его в контексте предоставляемых ИС услуг. После этого формулируется, кодируется и посылается стандартное подтверждение, отсылаемое функции коммутации услуг SSF. Процесс формулирования подтверждения может включать выполнение комплекса программ, в том числе, контакт с вызываемым абонентом и обращение к функции поддержки данных SDF. Функция коммутации услуг SSF, получив от SCF подтверждение, декодирует и интерпретирует его, а затем посылает функции управления вызовом CCF инструкции о том, как осуществить процесс установления соединением. В процессе формулирования подтверждения от SCF к SSF может потребоваться диалог между SCF и вызывающим или вызываемым абонентом. Такой диалог обычно заключается в отправке подсказки и получении некоторой последовательности цифр. Функция управления услугами SCF не имеет средств для непосредственного осуществления такого диалога, который происходит не иначе, как с помощью функции специализированных ресурсов SRF. Обычно SCF обращается к SRF с запросом о соединении абонента с соответствующим устройством, входящим в SRF (например, с речевым автоинформатором), и о необходимости получить от абонента определенные данные. Для понимания концепции интеллектуальной сети важно знать следующее:
- Только функция управления вызовом CCF уполномочена контролировать процесс установления и разъединения соединения.
- Взаимодействие функции коммутации услуг SSF и функции управления вызовом CCF является услугонезависимым. Поэтому SSF и CCF не должны содержать ничего, зависимого от услуг, предоставляемых ИС.
- В случае сбоев выполнения функции управления услугами SCF возможностей функций SSF/CCF должно быть достаточно для завершения вызова и соответствующего уведомления вызывающего и вызываемого абонентов.
- Функция коммутации услуг SSF в любой момент времени не должна взаимодействовать более, чем с одной функцией управления услугами SCF.
- Допускается взаимодействие между несколькими SCF и SSF, но так, чтобы не нарушалось условие 4.
- Только функция управления услугами SCF обладает всем необходимым для формулирования запросов к SRF, SSF и обработки ответов от них.
- Не допускается какого-либо взаимодействия между SSF и SRF иначе, как через SCF.
- Функция управления услугами SCF должна обладать возможностями для того, чтобы по инициативе вызываемого или вызывающего абонента приостановить предоставление услуги, но затем, в некоторый момент возобновить его по инициативе того же абонента.
В отличие от описанного порядка взаимодействия между SSF, SCF и SRF, который осуществляется по инициативе абонентов, функции, касающиеся обеспечения услуг, инициируются операторами сети. Эти функции не связаны с каким-либо вызовом абонента или предоставлением конкретной услуги. Функции SMF, SMAF и SCEF могут использоваться для удаления или изменения уже имеющихся услуг, а также для создания новых услуг. Это достигается путем изменения информации в SSF, SCF, SDF и SRF. Причем такие изменения не должны отражаться на качестве предоставляемых в этот момент услуг. Схема взаимосвязи функций набора CS-1, определяющая архитектуру плоскости DFP, представлена на рисунке 13.
Рис.13. Архитектура распределенной функциональной плоскости (по Q.1214)Физическая плоскость На четвертом уровне INCM согласно Q.1205определяются физические объекты (Physical entities — PE), способы отображения функциональных объектов на физические и описываются способы реализации сетевых элементов ИС. На рисунке 14 представлена физическая плоскость ИС.
Рис.14. Физическая плоскость ИС (по Q.1205) Основными требованиями к структуре ИС являются:
- сетевые функции выполняются в узлах IN;
- в узле может выполняться одна или более функций;
- выполнение общей сетевой функции не может совместно осуществляться несколькими узлами;
- два различных узла могут выполнять одинаковые сетевые функции;
- узлы должны иметь стандартные интерфейсы;
- распределение сетевых функций по узлам и стандартные интерфейсы не должны зависеть от услуг, предоставляемых сетью.
Физическая плоскость состоит из следующих физических объектов:
- SSP (Service Switching Point): узел коммутации услуг. Кроме обеспечения пользователям доступа в сеть и выполнения любых необходимых для коммутации функций, SSP обеспечивает доступ к интеллектуальной сети. Он должен быть связан с узлами, выполняющими функции управления услугами (SCF), например, с узлами управления услугами SCP.
- SCP (Service Control Point): узел управления услугами. Этот узел имеет набор программ, обеспечивающих выполнение услуг и, возможно, обработки данных, получаемых от пользователей IN. SCP выполняет функцию управления услуг SCF и, возможно, функцию поддержки данных SDF. SCP имеет прямой доступ к узлу поддержки данных SDP либо может подсоединяться к нему через сеть сигнализации. При этом узел SDP может входить как в ту же сеть, что и узел SCP, так и в другие сети. Через сеть сигнализации SCP может быть связан с узлом коммутации услуг SSP и интеллектуальной периферией (IP).
- SDP (Service Data Point): узел поддержки данных. Данный узел содержит данные, необходимые для предоставления индивидуализированных услуг, т.е. выполняет функцию поддержки данных. Доступ к SDP может быть получен либо через сеть сигнализации, либо через узел управления услугами SCP или узел обеспечения услуг SMP. Различные узлы поддержки данных могут быть связаны друг с другом.
- IP (Intelligent Peripheral): узел интеллектуальной периферии. Интеллектуальная периферия содержит средства, делающие услуги сети удобными для пользователей, например: запись речи пользователя, устройство распознавания речи, синтезатор речи. IP выполняет функции специализированных ресурсов SRF, функцию коммутации услуг SSF и функцию управления вызовом CCF. Последние две функции используются для обеспечения доступа к средствам, входящим в IP, который осуществляется по запросу из узла коммутации услуг SSP.
- AD (Adjunct): вспомогательный узел управления. Данный узел аналогичен узлу управления услугами SCP, но имеет непосредственную связь с узлом коммутации услуг SSP. Связь между вспомогательным узлом управления и узлом коммутации услуг поддерживается по высокоскоростному каналу.
- SN (Service Node): узел услуг. Данный узел напрямую связан с одним или более узлами коммутации услуг SSP и выполняет функции управления услугами SCF, поддержки данных SDF, специализированных ресурсов SRF, а также функции коммутации услуг SSF и управления вызовом CCF. При этом функции SSF/CCF в узле услуг тесно связаны с функцией управления услугами SCF и недоступны из других узлов, выполняющих функцию управления услугами. Данный узел имеет возможности как у узлов коммутации услуг, управления услуг и интеллектуальной периферии, вместе взятых.
- SSCP (Service Switcing and Control Point): узел коммутации и управления услугами. Данный узел объединяет узлы коммутации и управления услугами и выполняет функции коммутации услуг SSF, управления вызовом CCF, управления услугами SCF, поддержки данных SDF, управлением доступа вызова CCAF и, возможно, функцию специализированных ресурсов SRF.
- SMP (Service Management Point): узел обеспечения услуг. Данный узел выполняет функции SMF,SMAF и функцию среды создания услуг SCEF. Он может быть связан с любым узлом IN. Этот узел может управлять базами данных, тестировать сеть, управлять нагрузкой и проводить измерения различных характеристик сети.
- SCEP (Service Creation Environment Point): узел среды создания услуг. Данный узел выполняет функцию среды создания услуг и служит для разработки, формирования, тестирования и внедрения услуг в пункте их обеспечения SMP.
- SMAP (Service Management Access Point): узел доступа к системе эксплуатационной поддержки и администрирования услуг. Данный узел дает некоторым избранным пользователям доступ к узлам обеспечения услуг SMP.
Физические объекты могут содержать один и более нижеприведенных функциональных объектов (Functional Entities, FEs):
- CCF (Call Control Function) — функция управления вызовом;
- CCAF (Call Control Agent Function) — функция посредника управления вызовом;
- SCF (Service Control Function) — функция управления услугами;
- SDF (Service Data Function) — функция данных услуги;
- SRF (Special Resource Function) — функция специализированных ресурсов;
- SSF (Service Switching Function) — функция коммутации услуг;
- SMF (Service Management Function) — функция администрирования услуги;
- SCEF (Service Creation Environment Function) — функция среды создания услуги;
- SMAF (Service Management Access Function) — функция доступа администрирования услуги.
В заключение к данному разделу еще раз подчеркнем, что концептуальная модель представляет собой абстрактное средство для создания услуг IN путем их последовательного описания «сверху вниз».
Библиотека ITIL. Проектирование услуг
Назначение (purpose) процесса. Процесс должен предоставить единый источник согласованной информации обо всех услугах и обеспечить доступ к нему для всех, кому такой доступ разрешен.
Цель (goal) процесса. Процесс должен обеспечить создание и поддержание Каталога услуг, содержащего точную информацию обо всех эксплуатируемых услугах и услугах, готовящихся к запуску в эксплуатацию.
Задача (objective) процесса. Обрабатывать информацию, содержащуюся в Каталоге услуг, обеспечивать ее точность для действующих услуг и услуг, готовящихся к запуску в эксплуатацию, в реальной среде. Эта информация включает детальное описание услуги, ее статус, интерфейсы и зависимости от других услуг.
Границы процесса. Процесс включает следующие активности:
- определение услуги;
- создание и поддержание точного Каталога услуг;
- интерфейсы, зависимости и согласованность Каталога услуг и Портфеля услуг;
- интерфейсы и зависимости между всеми услугами (включая поддерживающие услуги), содержащимися в Каталоге, и Системой управления конфигурацией 19 англ. Configuration Management System ;
- интерфейсы и зависимости между всеми услугами и поддерживающими их компонентами и Элементами конфигурации 20 англ. Configuration Items , содержащимися в Каталоге услуг и Системе управления конфигурацией.
Ценность для бизнеса. Каталог услуг представляет собой главный источник информации об ИТ-услугах, предоставляемых организацией — провайдером услуг. Это означает, что все сферы бизнеса могут видеть точную, согласованную картину ИТ-услуг, их описания и статусы. Каталог позволяет потребителю увидеть, какие услуги используются, какие предполагается использовать, какие бизнес-процессы их используют, а также ожидаемый уровень качества услуг.
Политики, принципы и базовые концепции
Каждая организация должна разработать и поддерживать политику, относящуюся к содержанию Портфеля и Каталога услуг. Политика должна определять детальность описания и статус каждой услуги. Политика должна также определять ответственности за поддержание каждого раздела Портфеля услуг (т. е. Воронки услуг и Каталога услуг), а также границы и содержание разделов.
Часто имеет смысл включать в Каталог услуг иерархию услуг, точно указывая, что за услуга располагается на каждом уровне иерархии (например, «бизнес-услуга», видимая потребителю, или «инфраструктурная услуга»). Инфраструктурные услуги, такие как услуги сети, услуги приложений, хотя и невидимы для потребителя, также должны быть включены в Каталог услуг. Таким образом, иерархии могут содержать потребительские и связанные с ними услуги: поддерживающие, разделяемые и услуги, связанные с предоставлением потребителю физических объектов.
Рис. 12.3. Структура Каталога услуг
В простейшей форме Каталог услуг может представлять собой матрицу или электронную таблицу. Часто Портфель услуг и Каталог услуг интегрируют в Систему управления конфигурацией. Определяя услуги как Элементы конфигурации и выстраивая их, если нужно, в иерархию, организация получает возможность связывать события, такие как инциденты или запросы на изменение, с услугами, которые эти события затрагивают. Это позволяет организовать мониторинг услуг и построение отчетов с использованием интегрированного инструмента (например, «выдать число инцидентов, связанных с данной конкретной услугой»). Поэтому существенно, что изменения Портфеля или Каталога услуг выполняются с применением процесса » Управление изменениями 21 англ. Change Management «.
Каталог услуг используется в ряде других процессов ядра ITIL , в частности «Планирование непрерывности услуг» и «Управление мощностями».
Некоторые организации предпочитают иметь только Каталог бизнес-услуг или только Каталог технических услуг (см. рис. 12.3). Желательно тем не менее, чтобы существовали оба каталога и чтобы объединяющий их Каталог услуг входил частью в Портфель услуг. Комбинация каталогов очень полезна для быстрой оценки влияния инцидентов и изменений на бизнес.
Активности процесса, методы выполнения, технические приемы
Ключевые активности процесса:
- согласование и документирование определения услуги с участием всех заинтересованных сторон;
- взаимодействие с процессом «Управление портфелем услуг» для согласования содержимого Портфеля услуг и Каталога услуг;
- создание и поддержание Каталога услуг и его содержимого в связи с Портфелем услуг;
- взаимодействие с бизнесом и процессом «Управление непрерывностью ИТ-услуг» относительно зависимостей между бизнес-единицами, их бизнес-процессами и поддерживающими ИТ-услугами (эти зависимости описаны в Каталоге бизнес-услуг);
- взаимодействие с командами техподдержки, поставщиками услуг и процессом » Управление конфигурацией » относительно интерфейсов и зависимостей между ИТ-услугами, поддерживающими услугами, компонентами и Элементами конфигурации (эти зависимости и интерфейсы описаны в Каталоге технических услуг);
- взаимодействие с процессами «Управление взаимоотношениями с бизнесом» и «Управление уровнем услуг», для обеспечения соответствия информации в Каталоге актуальной информации о бизнесе и бизнес-процессах.
Триггеры, входы, выходы и интерфейсы
Источниками информации для процесса служат:
- бизнес-стратегия и ИТ-стратегия организации, планы, финансовые планы, данные о текущих и будущих требованиях бизнеса из Портфеля услуг;
- данные импакт-анализа, содержащие информацию о влиянии услуг на бизнес, приоритетности услуги и связанных с ней рисках или изменениях требований к услуге;
- бизнес-требования: подробности о любых согласованных, новых или изменившихся бизнес-требованиях из Портфеля услуг;
- портфель услуг;
- система управления конфигурацией;
- обратные связи от других процессов.
Триггеры процесса 22 Так в ITIL v.3 называются события, запускающие процесс. — это изменения бизнес-требований и услуг. Поэтому главные источники триггеров — это запросы на изменение и процесс «Управление изменениями». Изменения могут заключаться в появлении новых услуг, модификации существующих услуг, удалении услуг.
Выходами процесса являются:
- документация и соглашение об «определении услуги»;
- обновления Портфеля услуг: все услуги должны иметь текущий статус и связанные с ними требования;
- Каталог услуг, содержащий для каждой действующей и вводимой в эксплуатацию услуги детальное описание и текущий статус, а также ее интерфейсы и зависимости.
Управление информацией
Ключевая информация, с которой работает процесс, содержится в Каталоге услуг. Она поступает главным образом из Портфеля услуг и от бизнеса. В последнем случае источником является либо процесс «Управление взаимоотношениями с бизнесом», либо «Управление уровнем услуг». Информация должна быть проверена перед помещением ее в Каталог. Информация и Каталог поддерживаются с помощью процесса «Управление изменениями».
Ключевые показатели эффективности процесса
Два основных показателя эффективности процесса:
- количество услуг в Каталоге в процентном отношении к общему количеству оказываемых услуг, введенных в эксплуатацию;
- число зафиксированных отклонений данных Каталога от существующих в реальности.
Примеры других возможных показателей:
- осведомленность бизнес-пользователей об оказываемых услугах, т. е. увеличение степени завершенности Каталога бизнес-услуг по отношению к реально реализованным услугам (в процентах);
- осведомленность ИТ-персонала о технологиях, поддерживающих услуги:
- увеличение степени завершенности Каталога технических услуг по отношению к ИТ-компонентам, поддерживающим услуги (в процентах);
- уровень доступности информации для службы Service Desk, измеряемый процентом инцидентов, обработанных без обращения к информации, связанной с услугами.
Проблемы, критические факторы успеха и риски
Основная проблема с процессом «Управление Каталогом услуг» — это необходимость поддержания точного Каталога услуг как составляющей Портфеля услуг, входящего в Систему управления конфигурациями CMS 23 от англ. Configuration Management System и Систему управления знаниями об услугах SKSM 24 от англ. Service Knowledge Management System . Наилучший метод решения проблемы состоит в том, чтобы начать с разработки автономных баз данных или электронных таблиц, содержащих данные из Каталога бизнес-услуг и Каталога технических услуг, а затем включить их в CMS и SKMS. Тот факт, что Каталог услуг и Портфель услуг являются существенными источниками информации, которую персонал ИТ использует и сопровождает, должен стать частью корпоративной культуры.
Основные критические факторы успеха процесса «Управление Каталогом услуг» следующие:
- точный Каталог услуг;
- осведомленность бизнес-пользователей о предоставляемых услугах;
- знание ИТ-персоналом технологий, поддерживающих услуги.
Риски, связанные с созданием и поддержкой точного Каталога услуг, следующие:
- неточность данных в Каталоге и отсутствие строгого контроля за его изменениями;
- недостаточное использование Каталога в действующих процессах;
- неточность информации об услугах, полученной от бизнеса, ИТ-специалистов и из Портфеля услуг;
- инструменты и ресурсы, требующиеся для поддержки информации в Каталоге;
- неудовлетворительный доступ к точной информации процесса «Управление изменениями»;
- неудовлетворительный доступ к информации из CMS и SKMS, а также неадекватность и неактуальность этих систем;
- обман, в связи с фактом использования Портфеля и Каталога услуг;
- неадекватный уровень детальности информации: слишком низкий, что затрудняет поддержку, либо слишком высокий, что обесценивает информацию. Уровень информации должен соответствовать уровням детализации CMS и SKMS.
Приведенное описание процесса, несмотря на некоторые повторы и местами излишнее многословие, хорошо структурировано и компактно. Это характерно для всех процессов, описанных в книге «Проектирование услуг».
В заключение я хотел бы вернуться к вопросу о том, что такое услуга в ITIL v.3. Теперь, после обсуждения назначения и структуры Каталога услуг, стал более понятен подход ITIL v.3 к определению услуги.
Сама концепция Каталога подразумевает, что состав услуг относительно стабилен. Появление качественно новых услуг происходит вследствие глобальных изменений бизнеса. Поскольку услуги непосредственно связаны с использованием определенных ресурсов, необходимым условием стабильности состава услуг является стабильность состава и характеристик этих ресурсов. Возникает вопрос: какие ресурсы предприятия следует считать стабильными, а какие — нет? Конечно, нас интересуют не все ресурсы, а только те, которые связаны с услугами ИТ-организации. Перечень относительно стабильных ресурсов мог бы выглядеть примерно так:
- Информация, характеризующая предприятие: оргструктура, основные функции.
- Бизнес-процессы, описания ролей, кадровая информация, правила информационного обмена.
- Основные бизнес-объекты (высокоуровневые модели данных).
- Приложения, функциональность, пользовательские интерфейсы, правила доступа, политика безопасности.
- Нормативно-справочная информация.
- ИТ-инфраструктура, коммуникационные средства, сети.
Вот несколько примеров услуг, использующих эти ресурсы.
Услуга по предоставлению доступа к приложениям с использованием единого пароля связана со стабильностью состава приложений.
Услуги корпоративной системы электронного документооборота обусловлены постоянством оргструктуры, ролей в оргструктуре и бизнес-процессах, стабильностью правил информационного обмена внутри предприятия.
Услуги по подготовке регламентного отчета, например, об отгрузках на определенную дату, услуги по предоставлению доступа к информации о складских остатках или по выполнению определенных бухгалтерских транзакций обусловлены стабильностью бизнес-процессов и основных бизнес-объектов.
Наконец, услуга по автоматизированному предоставлению управленческой отчетности предполагает стабильность бизнес-процессов, оргструктуры и основных бизнес-объектов.
На противоположном полюсе находятся короткоживущие и нестабильные ресурсы организации. К ним относятся, например, ресурсы субподрядчиков, привлекаемых для выполнения проектов, временно доступные аппаратные ресурсы, предназначенные к выводу из эксплуатации приложения. Существуют и короткоживущие бизнес-процессы, например проведение маркетинговых кампаний. Разрабатывать услуги с использованием таких ресурсов чаще всего не имеет смысла.
И наконец, есть промежуточная область, где находятся ресурсы с промежуточной продолжительностью жизни. Представим себе организацию, которая, в частности, занимается проектной деятельностью по разработке систем, но выполняет и другие функции. Нужно ли разрабатывать внутреннюю услугу по расчету рентабельности проекта на произвольную дату? Имеет ли смысл создавать услугу для клиентов по сопровождению разработанных систем? Если маркетинговые кампании проводятся регулярно, имеет ли смысл услуга оценки результативности кампании? На эти вопросы невозможно ответить вне конкретного контекста, и ответ, конечно, будет в большой мере субъективным.
Поэтому, строго говоря, следовало бы считать Каталог просто определением услуг и условиться, что услугой по определению является то и только то, что содержится в Каталоге. Смысл определения услуги и помещения ее в Каталог только в том, чтобы контролировать работу определенного набора информационных ресурсов, связанных с определенными активами пользователя (см. рис. 10.3). Набор услуг, таким образом, становится набором индикаторов, сигнализирующих о взаимодействии организации с ее информационными ресурсами. Наблюдение за индикаторами позволяет, в частности, принимать обоснованные решения о развитии этих ресурсов.
Краткие итоги
В лекции кратко рассмотрено содержание второй книги ITIL v.3 — «Проектирование услуг» и подробно проанализированы структура Каталога услуг и процесс «Управление каталогом услуг». Делается вывод о Каталоге услуг как механизме, поддерживающем принятие решений, касающихся развития информационных ресурсов.
Вопросы
- Какие процессы входят в Проектирование услуг?
- Что такое Каталог услуг? Какова его структура?
- В чем состоят назначение, цель и задача процесса «Управление Каталогом услуг?
- Каковы входы, выходы и триггеры процесса «Управление Каталогом услуг»?
- Каковы основные активности процесса «Управление Каталогом услуг»?