Соглашение об уровне сервиса

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

Структура Соглашения об Уровне Услуг зависит от ряда переменных, таких как:

• Физические аспекты организации:

- размер организации;

- сложность;

- географическое распределение.

• Аспекты культуры:

- язык, на котором составляются документы (для международных организаций);

- взаимоотношения между ИТ-организацией и заказчиком;

- политика выставления счетов;

- однородность бизнес-деятельности;

- тип организации: коммерческая или некоммерческая.

• Характер бизнес-деятельности:

- общие положения и условия;

- часы работы — 5x8 часов или 7x24 часа.

Внешние договоры и операционные соглашения об уровне услуг

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

Каталог услуг

При составлении Каталога услуг могут быть полезны следующие рекомендации:

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

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

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

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

Управление уровнем сервиса

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. Анализ влияния отказа компонентов (cfia)
34. Расчеты доступности сервиса

Мониторинг

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

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

Создание отчетов

Отчеты заказчику (отчеты о сервисах) должны предоставляться в сроки, оговоренные в Соглашении SLA. В этих отчетах сравниваются фактически предоставляемые Уровни Сервисов с согласованными Уровнями. Примерами отчетов могут быть:

§ доступность сервисов и время простоя в указанные периоды;

§ среднее время реагирования в пиковые периоды;

§ скорость транзакций в пиковые периоды;

§ количество функциональных ошибок в ИТ-сервисе;

§ частота и длительность периода деградации сервисов (Услуги не достигают согласованного Уровня);

§ среднее количество пользователей в пиковые периоды;

§ количество успешных и безуспешных попыток нарушить систему безопасности;

§ количественное соотношение использованных мощностей сервисов;

§ количество завершенных и незавершенных (открытых) изменений;

§ стоимость предоставленных услуг.

Анализ (ревью)

Уровень Сервисов нужно регулярно анализировать, уделяя при этом внимание следующим аспектам:

§ Соглашению об Уровне Услуг с момента последнего анализа;

§ проблемам, возникшим с услугами;

§ выявлению тенденций работы услуг;

§ изменению услуг в пределах Согласованных Уровней Сервиса;

§ изменению процедур и расчетов стоимости дополнительных ресурсов;

§ последствию сбоев при предоставлении Согласованных Уровней Услуг.

Если не удалось организовать предоставление ИТ-услуг на Согласованном Уровне, следует согласовать действия по исправлению ситуации, например:

§ разработать Программу улучшения услуг (Service Improvement Program — SIP);

§ выделить дополнительный персонал и ресурсы;

§ изменить Уровни Сервисов, определенные в Соглашении SLA;

§ модифицировать процедуры;

§ модифицировать Соглашения OLA и Внешние Договоры UC.

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

Управление финансами ит

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

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

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

Категории затрат

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

Для каждого продукта или сервиса можно определить затраты, прямо или косвенно связанные с ним:

· Прямые затраты: затраты, связанные конкретно и исключительно с какой – либо ИТ – услугой. Например, виды деятельности и материалы, прямо и однозначно связанные с определенным сервисом (аренда телефонной линии для доступа к сети Интернет).

Управление финансами ит

· Косвенные затраты: затраты, не связанные прямо и однозначно с какой – либо ИТ – услугой. Примерами могут быть затраты на помещения, услуги по поддержке (например, Управление Сетью) и административные расходы (включая затраченное время).

Управление мощностями

Задачей Процесса Управления Мощностями является предоставление в нужное время и в экономически эффективной форме необходимых мощностей для обработки и хранения данных, обеспечивая соответствующий баланс мощностей в ИТ-организации. Хорошее Управление Мощностями исключает панические закупки в последнюю минуту или покупку самой большой системы «на всякий пожарный случай». Подобные ситуации дорого обходятся. Многие центры обработки данных, например, постоянно работают с недогрузкой на 30-40% или больше. Это не так плохо, если у вас небольшое количество серверов. Но если у вас сотни и тысячи серверов, как у многих ИТ-организаций масштаба предприятия, то эти проценты означают потерю огромных финансовых средств.

Управление Мощностями отвечает за решение следующих вопросов:

• Оправдываются ли затраты на приобретение мощностей для обработки данных с точки зрения потребностей бизнеса, и используются ли эти мощности наиболее эффективным образом (соотношение стоимости и мощности)?

• Адекватно ли соответствуют имеющиеся мощности как текущим, так и будущим запросам заказчика (соотношение спроса и предложения)?

• Работают ли имеющиеся мощности с максимальной эффективностью (настройка производительности)? Когда точно необходимо устанавливать дополнительные мощности?

Процесс Управления Мощностями направлен на постоянное предоставление необходимых ИТ-ресурсов, соответствующих текущим и будущим потребностям заказчика, в нужное время (там, где они требуются) и за приемлемую цену.

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