Методическое руководство для подготовки к экзаменам по ISO 20000

Методическое руководство для подготовки к профессиональным экзаменам ISO 20000 Foundation / ISO 20000 Foundation Bridge ...

Author: Лариса Будкова | Роман Журавлёв.

17 downloads 959 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Методическое руководство для подготовки к профессиональным экзаменам ISO 20000 Foundation / ISO 20000 Foundation Bridge

Издание компании Cleverics. Авторы – Лариса Будкова, Роман Журавлёв. Редактор – Олег Скрынник.

Будкова Л., Журавлёв Р. «Методическое руководство для подготовки к профессиональным экзаменам ISO 20000 Foundation и ISO 20000 Foundation Bridge» / Будкова Л., Журавлёв Р. – М.: Клеверикс, 2010. – 123 с.

© Все права на издание, оформление, распространение – ООО «Клеверикс», 2010-2011 www.cleverics.ru

Информационная поддержка и распространение – портал Real ITSM www.realitsm.ru

Настоящее учебное пособие аккредитовано институтом EXIN как самостоятельный и самодостаточный продукт. www.itsm-iso20k.ru Все права защищены. Данное методическое руководство, равно как и любая его часть, могут свободно и бесплатно распространяться в бумажном и электронном виде при соблюдении следующих обязательных условий:

•

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

•

при распространении явным образом указаны авторы, включая наименование компании Cleverics;

•

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

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


2

1. 2.

Кому предназначено это методическое руководство .................4 Стандарт ISO/ IEC 20000 .............................................................. 7 2.1. Краткая история ISO/IEC 20000 ............................................................ 8 2.2. Область применения и структура стандарта......................................... 9 2.3. Связь с ITIL ............................................................................................... 10 2.4. Сертификация компаний ........................................................................ 11 2.5. Сертификация специалистов .................................................................12 3. Экзамен «ITSM Foundation according to ISO/IEC 20000» ......... 16 3.1. Что надо знать об экзамене .................................................................... 17 3.2. Требования к экзамену ............................................................................ 17 3.3. Ответы на вопросы .................................................................................. 18 3.3.1. Услуги ............................................................................................................. 18 3.3.2. Качество ........................................................................................................ 20 3.3.3. ITSM (управление ИТ-услугами) ............................................................... 23 3.3.4. Процессы ....................................................................................................... 24 3.3.5. Постоянное улучшение ............................................................................... 26 3.3.6. Про другие стандарты и подходы .............................................................. 28 3.3.7. Требования к системе управления ИТ-услугами (в соответствии с Частью 1 стандарта ISO/IEC 20000) ........................................................................... 29 3.3.8. Требования к управлению и совершенствованию процессов ITSM ..... 29 3.3.9. Требования к процессам контроля ............................................................ 32 3.3.10. Требования к процессам управления взаимоотношениями ИТ и бизнеса 36 3.3.11. Требования к процессам предоставления услуг ...................................... 40 3.3.12. Требования к процессам поддержки услуг .............................................. 43 3.3.13. Рекомендации и практики по управлению услугами (в соответствии Частью 2 ISO/IEC 20000) ............................................................................................. 44 3.3.14. Рекомендации и практики для управления и совершенствования процессов ITSM .............................................................................................................. 44 3.3.15. Рекомендации и практики в области планирования и выполнения управления услугами .....................................................................................................47 3.3.16. Рекомендации и практики для процессов контроля .............................. 50 3.3.17. Рекомендации и практики для процессов управления взаимоотношениями ИТ и бизнеса ............................................................................ 63 3.3.18. Рекомендации и практики для процессов предоставления услуг .........73 3.3.19. Рекомендации и практики для процессов поддержки услуг ..................79

3.4. Пробный экзамен .................................................................................... 85 3.5. Анализ пробного экзамена и комментарии к ответам ...................... 96 4. Заключение ................................................................................116 Приложение 1. Список литературы.................................................. 117 Приложение 2. Основные термины и определения стандарта ISO/IEC 20000....................................................................................119 Приложение 3. Информация о ключевых компаниях .................. 122 EXIN 123 Cleverics ................................................................................................................. 123


3

1.

Кому предназначено это методическое руководство


4

Существует негласное правило: повышение влияния какой-либо отрасли или сферы деятельности на достижение целей бизнеса приводит к созданию системы координат, позволяющей оценивать эту деятельность, а затем – к согласованию этой системы координат заинтересованными сторонами. Верно и обратное: появление стандарта в какой-либо отрасли или сфере деятельности свидетельствует не только об осознании значимости этой сферы, но и о признании возможности и необходимости управления ею. Выход в свет в конце 2005 года международного стандарта ISO/IEC 20000 стал значимым событием для ИТ-сообщества именно потому, что не только подтвердил рост интереса к ИТ, но фактически стал символом международного признания ITSM (управления ИТ-услугами) как верного и повсеместно реализуемого подхода к управлению ИТ. Компании во всем мире получили подтверждение необходимости решения задач по управлению ИТ-услугами (область применения стандарта), официальные требования ко всем аспектам деятельности по управлению ИТуслугами (первая часть стандарта) и краткие рекомендации по организации, контролю и совершенствованию этой деятельности (вторая часть стандарта). Очевидно, что каждой компании, вставшей на непростой путь системного управления ИТ-услугами, необходимы сотрудники, знающие и понимающие структуру и содержание стандарта. Для того чтобы обеспечить наличие в компании такой компетенции, нужно решить несколько задач:

• выделить тех специалистов, квалификационный рост которых в этой области интересен компании;

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

• описание структуры и области применения стандарта ISO/IEC 20000, его истории и текущего положения в ИТ-мире, взаимосвязи с ITIL v2 и ITIL v3;

• схему и описание уровней сертификации специалистов в области управления ИТ-услугами, основанной на стандарте ISO/IEC 20000;

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

• обзор стандарта и комментарии к нему, подготовленные и структурированные в соответствии с официальными требованиями к экзамену Foundation.


5

Это руководство адресовано менеджерам и специалистам по ИТ, которые хотят проанализировать свою текущую практику управления, используя требования и положения стандарта ISO/IEC 20000. Также руководство ориентировано на специалистов, заинтересованных в подтверждении уровня своих знаний в области управления ИТ-услугами путем сертификации на основе международного стандарта ISO/IEC 20000. .


6

2. Стандарт ISO/ IEC 20000


7

2.1. Краткая история ISO/IEC 20000 Международная организация по стандартизации (International Organization for Standardization) утвердила стандарт ISO/IEC 20000 15 декабря 2005 года. Международный стандарт был основан на британском стандарте BS 15000, который определял требования к системе управления, используя подход, принятый в ISO 9000, но с акцентом на контроли, необходимые для успешного управления ИТ-услугами. BS 15000 был принят в ноябре 2000 года по инициативе itSMF-UK – единственного по-настоящему независимого международного объединения профессионалов в сфере управления ИТ-услугами. Эта некоммерческая организация – один из основных участников деятельности по развитию и продвижению передовых практик, стандартов и квалификационных схем с 1991 года. itSMF (IT Service management forum) предоставляет доступ к источникам информации, мнениям экспертов, площадкам для профессионального общения, чтобы помочь руководителям и сотрудникам преодолевать сложности, с которыми они встречаются при организации управления ИТ-услугами, и помочь им в создании систем управления, обеспечивающих высокое качество услуг для внешних и внутренних заказчиков. В состав itSMF входит более 6000 компаний по всему миру, представленных более чем 70000 участников. В разных странах действует более 50 отделений форума. Каждое отделение является самостоятельным юридическим лицом, обладающим широкой автономией. Также существует объединяющая эти отделения структура

itSMF International, поддерживающая

идеологическое единство сообщества. В течение нескольких следующих лет после принятия стандарта BS 15000, itSMF-UK, выступавший и как сертифицирующий орган, получил множество запросов от различных организаций на проведение сертификационного аудита. География запросов показывала, что интерес к стандарту вышел за пределы Великобритании. В итоге было принято решение об инициации процедуры введения международного стандарта. В свою очередь, BS 15000 был основан на Своде практик по управлению услугами (DISC PD005), утвержденном Британским институтом стандартизации (BSI) в конце 1990-х. На сегодняшний момент в мире зарегистрировано 38 официальных сертифицирующих организаций (RCB, Registered Certification Body), которые проводят сертификационный аудит соответствия систем управления ИТуслугами требованиям стандарта ISO/IEC 20000 (право проведения аудита предоставлено им itSMF International).


8

Сертифицированных систем управления ИТ-услугами в мире уже более 500, и еще более 100 находятся в стадии прохождения аудита. По числу сертифицированных систем управления ИТ-услугами лидируют Китай (более 80) и Япония (более 70). В России свыше 25 компаний успешно прошли сертификацию своих систем управления ИТ-услугами на соответствие стандарту ISO/IEC 20000. Полный и актуальный реестр этих компаний доступен по адресу http://www.realitsm.ru/reestr-iso-20000

2.2. Область применения и структура стандарта Стандарт ISO/IEC 20000 состоит из двух частей. Часть 1 определяет требования к поставщику ИТ-услуг по организации предоставления заказчикам управляемых услуг приемлемого качества. Первая часть стандарта может использоваться:

• Коммерческими организациями, которые собираются предлагать свои услуги (например, при участии в тендерах на оказание услуг);

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

• Поставщиками услуг для сравнительной оценки уровня собственной системы управления ИТ-услугами;

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

• Организациями, стремящимся к улучшению услуг посредством эффективного применения процессов, позволяющих контролировать и повышать качество услуг. Часть 2 предлагает краткий свод практических рекомендаций по организации, контролю и совершенствованию системы управления ИТ-услугами с целью соответствия требованиям первой части. Модель системы управления ИТ-услугами, предлагаемая в рамках стандарта ISO/IEC 20000, состоит из процессной модели (13 процессов, разделенных на 5 групп) и двух областей управления верхнего уровня: «Планирование и реализации системы управления ИТ-услугами» и «Планирование и внедрение новых/измененных услуг». Кроме этого в стандарте содержатся требования к самой системе управления ИТ-услугами.


9

2.3. Связь с ITIL Библиотека ITIL явилась отправной точкой для создания и развития стандарта. Благодаря материалам ITIL, общемировому интересу к их изучению и применению на практике, de-facto сформировались как общий язык в области управления ИТ-услугами, так и общее понимание необходимого уровня зрелости системы управления ИТ-услугами. Это естественным образом привело к официальной стандартизации. Однако, в ходе разработки стандарта в процессную модель, предложенную ITIL v2, был внесен ряд изменений и дополнений. Основной акцент был сделан на создании целостной системы управления (а не набора отдельных процессов) и реализации идеи контроля и совершенствования на протяжении всего жизненного цикла ИТуслуги на основе цикла PDCA (Plan-DO-Check-Act). Некоторые изменения и дополнения были учтены авторами ITIL v3.


10

Таблица 1. Сравнительная информация об ITIL v2, ITIL v3, ISO/IEC 20000. ITIL v2

ITIL v3

ISO/IEC 20000

Лучшие практики (Best practice)

Хорошие практики (Good practice)

Требования (нормы) и свод практических рекомендаций

Процессноориентированная модель

Модель, ориентированная на жизненный цикл ИТуслуги

Система управления ИТуслугами, ориентированная на постоянное совершенствование

10 процессов, разделенные на 2 группы (Предоставление услуг, Поддержка услуг) и 1 функция (Service Desk)

26 процессов, 5 стадий жизненного цикла услуг (Стратегия услуг, Проектирование услуг, Преобразование услуг, Эксплуатация услуг, Постоянное улучшение услуг) и 4 функции

13 процессов, разделенные на 5 групп (Предоставление услуг, Управление взаимодействием, Процессы контроля, Процессы разрешения, Управление релизами) и 2 верхние области управления (Планирование и реализация системы управления услугами, Планирование и внедрение новых/изменяемых услуг)

Сертификация специалистов

Сертификация специалистов и программного обеспечения

Сертификация компаний и сертификация специалистов

2.4. Сертификация компаний Появление стандарта ISO/IEC 20000 дало возможность ИТ-компаниям и внутренним ИТ-департаментам, позиционирующим себя как зрелых поставщиков услуг, формально подтвердить полноту и эффективность реализованной

системы

управления

ИТ-услугами

путем

сертификации

на

соответствие требованиям стандарта. Доступны два варианта сертификации: отдельная сертификация системы управления ИТ-услугами (получение сертификата ISO/IEC 20000 и права использовать соответствующий логотип) или расширение охвата действующей сертификации ISO 9000 (если компания обладает соответствующей сертификацией). Срок действия сертификата – 3 года. В течение срока действия сертификата должны проводиться дополнительные проверки (инспекции) не реже 1 раза в год охватом около 50% от первоначальной сертификации. По окончании трех лет проводится повторная сертификация охватом около 70% от первоначальной (если не изменяются ключевые параметры: сертифицируемая область, размер компании и так далее). Длительность сертификационного аудита рассчитывается по специальным методикам/правилам исходя из размера компании, области охвата сер-


11

тификации, количества площадок и других факторов. Примерная длительность – 5-10 рабочих дней. Компания, готовящаяся к сертификации, может заказать до трех предварительных аудитов. Необходимость и длительность предварительного аудита определяется самой компанией. Результаты предварительного аудита не учитываются при сертификации (сертификация предполагает полную проверку, а не только устранение замечаний предварительного аудита). В России, несмотря на серьёзный интерес к стандарту, немногие выбрали путь сертификации компании (на сегодняшний день в России сертифицировано чуть более 25 систем управления ИТ-услугами). Сертификация компании – это выбор либо тех, для кого предоставление ИТ-услуг – основной бизнес, либо крупных внутренних ИТ-департаментов в очень больших территориально распределенных компаниях, имеющих высокую степень зависимости бизнес-процессов от ИТ. Большинство же компаний используют стандарт как ориентир для оценки своей системы управления ИТ-услугами и её совершенствования. Такой подход позволяет уделить должное внимание реальным достижениям и сложностям, не стремясь обеспечить полное соответствие всем требованиям стандарта. Именно эта идея приоритета практических умений и навыков над знаниями конкретных списков рекомендаций легла в основу разработанной EXIN совместно с TÜV SUD Akademie квалификационной схемы для ИТспециалистов и менеджеров на основе стандарта ISO/IEC 20000.

2.5. Сертификация специалистов Появление квалификационной схемы для ИТ-специалистов и менеджеров на основе стандарта ISO/IEC 20000 стало маленькой революцией в мире ITSM. Первая реальная альтернатива ITIL-сертификации, обладающая рядом серьезных достоинств, была представлена ИТ-сообществу компаниями EXIN (Нидерланды) и TÜV SÜD Akademie (Германия). В чем же особенности новой сертификационной схемы? Каковы её преимущества по сравнению с более известной ITIL-сертификацией?


12

Таблица 2. Сравнительная характеристика сертификационных систем. Характеристика (особенность)

Сертификационная система на основе ITILv3 (APMG)

Сертификационная система на основе стандарта ISO/IEC 20000 (EXIN и TÜV Akademie)

Инновационность

Система позволяет получить знания о последних достижениях авторов ITIL v3, прошедших оценку специалистов APMG.

В системе объединены разработки в области управления ИТ-услугами, реализованные в различных подходах и методологиях, получившие признание у мирового ИТсообщества, соотнесенные со стандартом ISO/IEC 20000

Независимость

Сертификационные экзамены ориентированы на проверку буквального знания книг ITIL v 3, без учета альтернативных подходов и мнения профессионального сообщества.

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

Практическая полезность

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

В рамках всех сертификационных курсов выше базового уровня обязательна постановка практических задач. Их успешное выполнение — условие получения сертификата наряду с успешной сдачей экзамена.

Простота и логика

Реально значимым является только верхний уровень сертификации. Его достижение требует прохождения как минимум 5 курсов и сдачи 6 экзаменов (если вы не обладаете верхним уровнем сертификации по ITIL v2). Уровень Intermediate состоит из девяти экзаменов, сгруппированных в два потока, между которыми сложно сделать выбор.

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


13

Характеристика (особенность)

Сертификационная система на основе ITILv3 (APMG)

Сертификационная система на основе стандарта ISO/IEC 20000 (EXIN и TÜV Akademie)

Международное признание

Долгое время сертификация по ITSM равнялась сертификации по ITIL. Появление и развитие альтернативных сертификационных схем – во многом следствие разочарованности международного ИТ-сообщества в связи с явным коммерческим уклоном новой схемы сертификации по ITIL v3

Данная сертификационная система разработана совместно EXIN и TÜV SÜD Akademie под контролем группы экспертов из разных стран и направлена на продвижение идей ITSM. Экзамены доступны по всему миру на многих языках. Сама квалификационная схема сертифицирована на соответствие стандарту ISO 17024

Качество экзаменационных материалов

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

Сертификационные экзамены составляются профессионалами EXIN, имеющими многолетний опыт подобной деятельности.

Рассмотрим более подробно сертификационную систему на основе стандарта ISO/IEC 20000. Три уровня сертификации:

• Базовый уровень — Foundation: основные элементы ITSM и управления качеством, основные положения стандарта ISO/IEC 20000;

• Уровень Professional — пять сертификаций: Support, Control, Process Management and Improvement, Business and IT Alignment, Delivery: управление соответствующими аспектами качества ИТ-услуг (теоретические знания и практические навыки);

• Верхний уровень — два направления: «менеджерское» и «аудиторское»: «менеджер» – планирование, реализация и совершенствование системы управления ИТ-услугами; «аудитор» – планирование и проведение аудита системы управления ИТ-услугами. На этом уровне 2 статуса по каждому из направлений. Статус Executive предполагает не менее 3 лет опыта работы по соответствующему направлению.


14

В России сертификационные экзамены по схеме на основе стандарта ISO/IEC 20000 доступны в любом аккредитованном экзаменационном центре EXIN; курсы Professional доступны в Cleverics с апреля 2010 года. Подробнее о профессиональной сертификации можно узнать на сайте Cleverics: www.cleverics.ru.


15

3. Экзамен «ITSM Foundation according to ISO/IEC 20000»


16

3.1. Что надо знать об экзамене Экзамен Foundation подтверждает как наличие знаний основ стандарта ISO/IEC 20000, так и понимание основных аспектов управления качеством и управления ИТ-услугами. Сдача данного экзамена позволяет ИТ-специалисту продемонстрировать свою способность к работе в области управления ИТ-услугами в соответствии с международным стандартом и лучшими практиками. Кроме того, наличие сертификации Foundation является ключом к прохождению дальнейшего обучения и сертификации. Экзамен представляет собой тест, содержащий 40 вопросов и несколько вариантов ответа на каждый вопрос; верным является только один из предложенных вариантов . Для получения сертификата необходимо дать верные ответы на 26 и более вопросов (65%). Продолжительность экзамена – 60 минут, экзамен сдается на английском языке. Если у Вас уже есть сертификат ITIL Foundation, то предусмотрен сокращенный формат сертификации – сдача экзамена Foundation Bridge (20 вопросов, 13 верных ответов – проходной балл).

3.2. Требования к экзамену Вопросы экзамена охватывают 4 темы:

• Понимание определений и принципов управления ИТ-услугами (ITSM) – 15% вопросов;

• Понимание роли и назначения стандарта ISO/IEC 20000 – 20% вопросов;

• Требования к системе управления услугами (в соответствии с Частью 1 ISO/IEC 20000) – 35% вопросов;

• Рекомендации и практики по управлению услугами (в соответствии с Частью 2 ISO/IEC 20000) – 30% вопросов. В официальных экзаменационных требованиях на сайте EXIN представлена детализация экзаменационных тем:

Foundation in IT Service Management according to ISO/IEC 20000 (IS20F.EN). 1.

Определения и принципы управления качеством услуг (Service Quality Management) 1.1. Услуги 1.2. Качество 1.3. ITSM (управление ИТ-услугами) 1.4. Процессы


17

1.5. Постоянное улучшение 2. Роль и назначение стандарта ISO/IEC 20000 2.1. Стандарты и подходы – обзор 2.2. Сертификация системы управления 2.3. Структура ISO/IEC 20000 3. Требования к системе управления услугами (в соответствии с Частью 1 ISO/IEC 20000) 3.1. Требования к управлению и совершенствованию процессов ITSM 3.2. Требования к процессам контроля 3.3. Требования к процессам управления взаимоотношениями ИТ и бизнеса 3.4. Требования к процессам предоставления услуг 3.5. Требования к процессам поддержки услуг 4. Рекомендации и практики по управлению услугами (в соответствии с Частью 2 ISO/IEC 20000) 4.1. Рекомендации и практики для управления и совершенствования процессов ITSM 4.2. Рекомендации и практики для процессов контроля 4.3. Рекомендации и практики для процессов управления взаимоотношениями ИТ и бизнеса 4.4. Рекомендации и практики для процессов предоставления услуг 4.5. Рекомендации и практики для процессов поддержки услуг

3.3. Ответы на вопросы Что же надо знать для прохождения экзамена? Ответим на этот вопрос в соответствии с заявленными экзаменационными требованиями. Вопросы экзамена по этой теме и ожидаемые экзаменаторами ответы подробно рассмотрены в книге «Введение в ISO/IEC 20000», рекомендованной EXIN для подготовки к экзамену; однако практика сдачи экзамена показывает, что буквальное знание текста книги не требуется, достаточно понимания общепринятого современного отношения к основным аспектам управления качеством и услугами. В частности, рекомендуется помнить следующее:

3.3.1.

Услуги Высокая и постоянная зависимость бизнеса от ИТ привела к изменению

подхода к предоставлению ценности заказчикам и позиционированию ИТпоставщиков в качестве поставщиков услуг, а не продуктов.


18

Основными характеристиками, отличающими услугу от продукта, являются:

• • • • •

Нематериальность большей части компонентов услуги; Услуга одновременно предоставляется и потребляется; Услуга вариативна; Потребитель участвует в формировании ценности; Качество услуги оценивается по факту предоставления, и эта оценка во многом субъективна.

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

• Информационную систему; • Поддержку; • Требования к качеству (спецификацию). Информационная система включает в себя три основных типа активов – PPT – People, Process, Technology, которые используются (возможно, при участии еще одного «P», Partners) для управления «I», Information. [Вместе получается PPTPI, см. рисунок]:

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


19

соответствии с потребностями заказчика. Эта деятельность организована как система процессов.

3.3.2.

Качество ISO определяет качество как «способность набора неотъемлемых харак-

теристик продукта, системы или процесса удовлетворять требованиям заказчиков и других заинтересованных сторон». На практике качество ИТ-услуг часто понимается как комплекс их характеристик, отвечающих ожиданиям заказчиков. Это понимание сужает понятие «качество» до измеримых характеристик услуги и может включать в себя как характеристики деятельности (время реакции службы поддержки), так и характеристики или объекты инфраструктуры. Итоговый перечень характеристик может быть согласован разными поставщиками и заказчиками по-своему, но в большинстве случаев среди этих характеристик будут:

• • • • • • •

Доступность Производительность Мощность Безопасность Масштабируемость Гибкость …

Заказчики, как правило, оценивают качество услуг с использованием трех параметров:

• Отвечает ли услуга ожиданиям? • Можно ли ожидать такого же качества в будущем? • Соответствует ли услуга своей цене? Оценка качества услуг во многом субъективна и основана на ожиданиях. Возможными источниками несоответствия предоставленных услуг ожиданиям могут служить информационные разрывы на разных этапах взаимоотношений поставщика и заказчика:

• То, чего ожидает заказчик и то, как представляет себе его ожидания поставщик;

• То, что поставщик думает об ожиданиях заказчика и документированные критерии качества;

• Утвержденные критерии качества и фактическое качество предоставленных услуг;

• Фактическое качество услуг и отчетность о качестве услуг, предоставленная заказчику;

• Отчетность о качестве предоставленных услуг и то, чего ожидал заказчик.


20

Для устранения перечисленных разрывов необходим постоянный диалог с заказчиком. Информация о восприятии предоставляемых услуг должна включать в себя различные формы обратной связи от заказчиков и от конечных пользователей. Среди важных атрибутов качества особую роль может играть приемлемая стоимость услуг. Для управления ценой предоставляемой услуги поставщику может потребоваться информация о её себестоимости и ценах на аналогичные услуги, предлагаемых другими поставщиками. Важнейшим условием удовлетворенности заказчиков является стабильность предоставляемых услуг, она же – один из самых труднодостижимых элементов качества. Для того чтобы предоставлять качественные услуги, поставщик должен быть уверен в качестве каждого элемента цепочки предоставления – не только по отдельности, но в комплексе, во взаимодействии. Качество услуг зависит от того, как организована деятельность по управлению ими. Цикл Деминга – простая модель управления качеством. Она предполагает, что для того, чтобы обеспечивать приемлемый уровень качества, нужно последовательно выполнять следующие шаги: 1.

Plan

2. Do 3. Check 4. Act Организованные таким образом виды деятельности должны быть объединены в процессы, для каждого из которых должны быть определены свои планы и возможности для измерения и оценки. Ответственность за управление деятельностью, а также изменение планов, должна быть четко определена для каждого вида деятельности и каждого процесса.


21

Управление качеством (Quality Management) – область ответственности каждого сотрудника, участвующего в предоставлении услуг. Оно предполагает не только осведомленность каждого о его вкладе в общую работу по обеспечению качественных услуг для заказчиков, но и постоянный поиск возможностей для улучшения. Контроль качества (Quality Assurance) – это набор мероприятий и процедур, обеспечивающих уверенность в том, что поставщик предоставляет услуги надлежащего качества, отвечающие соответствующим соглашениям, спецификациям и ожиданиям; Контроль качества (QA) также обеспечивает реализацию улучшений, инициированных в ходе управления качеством. СМК, система менеджмента качества, система управления качеством (Quality System) – организационная структура, включающая в себя ответственность, процедуры и ресурсы для внедрения и реализации управления качеством. Стандарты серии ISO 9000 часто используются для создания, управления, оценки и совершенствования СМК. Отвечающая требованиям стандарта СМК обеспечивает уверенность, что:

• Поставщик принимает меры к предоставлению согласованного уровня качества;

• Руководство регулярно оценивает работу СМК и использует результаты оценки для совершенствования СМК;

• Процедуры, в соответствии с которыми работает поставщик, документированы и доносятся до исполнителей;


22

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

• Поставщик контролирует процессы и способен их улучшать. 3.3.3.

ITSM (управление ИТ-услугами) ITSM, управление ИТ-услугами – это комплекс совместно действующих

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

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

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

• Улучшается управление качеством услуг; • Коммуникации через согласованные точки контакта более эффективны. Среди преимуществ ITSM с точки зрения поставщиков:

• Более ясную ориентацию на цели заказчиков, более рациональную структуру и организацию деятельности;

• Улучшение контроля над инфраструктурой; • Процессное управление позволяет эффективно использовать аутсорсинг отдельных элементов услуг;

• Следование передовым практикам улучшает имидж поставщика и способствует внедрению СМК, основанных на ISO 9000 или ISO 20000;

• Появляется единый язык для взаимодействия и координации с внутренними и внешними контрагентами. Риски и возможные ошибки при использовании подхода ITSM:

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


23

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

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

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

• Внедрение ITSM силами изолированной команды, без поддержки персонала на всех уровнях, может привести к созданию нежизнеспособной искусственной системы;

• Нехватка ресурсов на проведение преобразований, обучение и автоматизацию, может привести к снижению эффективности внедрения ITSM.

3.3.4.

Процессы Каждая организация стремится реализовать сформулированные мис-

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

• • • •

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

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

достижения

определенной

для

процесса

цели

с

учетом

его

взаимоотношений с другими процессами.


24

Процесс – это комплекс совместно выполняемых и управляемых видов деятельности, направленных на формирование определенных выходов (outputs), а в конечном итоге – результатов (outcomes) из определенных входов (inputs) – см. модель ITOCO (Input – Throughput – Output – Control – Outcome):

Входы (inputs) связаны с ресурсами, используемыми процессом; выходы (outputs) подразумевают непосредственные немедленные результаты работы

процесса;

результаты

(outcomes)

–

долгосрочный

эффект

от

деятельности процесса. Контроль (control) позволяет соотнести входы и выходы процесса с действующими политиками и стандартами. Контроль регулирует работу (throughput) и входы процесса, если работа или выходы отклоняются от плановых значений, определенных политиками и стандартами. В организации должны быть определены требования к результатам работы процессов. Если фактические результаты соответствуют этим требованиям, считается, что процесс результативен (effective). Более точная оценка результативности возможна при использовании для нее результатов (outcomes), а не выходов (outputs). Если деятельность в рамках процесса осуществляется с минимумом усилий и затрат, то процесс рационален (efficient). Задача управления процессами – обеспечить выполнение всех процессов максимально результативным и рациональным образом. Система управления может организовать контроль с использованием измерений результативности и рациональности процессов. Для этого должны быть согласованы индикаторы производительности (performance indicators). Оперативный контроль обычно делегирован менеджеру процесса; владелец процесса оценивает данные индикаторов и проверяет их на соответствие утвержденным стандартам и целям. В отсутствие согласованных индикаторов владельцу будет сложно оценить эффективность контроля хода процесса и деятельности по его совершенствованию.


25

Процессы часто описываются с использованием процедур и рабочих инструкций. Процедура – это определенный способ выполнения процесса или вида деятельности. Процедуры отвечают на вопрос «как» и иногда на вопрос «кто» в отношении той или иной деятельности. Рабочие инструкции содержат детальное описание того, как выполняются одна или несколько работ в составе процедуры. Процессы включают в себя два типа видов деятельности: виды деятельности, направленные на получение результата (throughput activities) и виды деятельности по управлению ими (control activities). В зависимости от выбранной в организации модели управления (иерархической, процессной, проектной…), в ней выделяются ресурсы (менеджеры) для контроля, управления и координации работы сотрудников в одном или нескольких контурах управления. При проектировании процессов в дополнение к существующей иерархии определяются роли. Роли – это наборы областей деятельности и ответственности, а также полномочий, предоставляемые сотруднику или группе. Один сотрудник может исполнять много ролей, а одна роль может исполняться группой сотрудников.

3.3.5.

Постоянное улучшение После того, как Software Engineering Institute университета Carnegie

Mellon опубликовал модели зрелости для процессов разработки ПО (Software Capability Maturity Model), аналогичные модели стали широко применяться в различных областях управления. CMM стала чем-то вроде стандарта в моделировании зрелости. Аналогичная модель использовалась различными подходами к управлению качеством, в том числе – в EFQM (European Foundation for Quality Management). EFQM принят в 1998 четырнадцатью крупными европейскими компаниями при поддержке Еврокомиссии. Цель EFQM – продвижение TQM (Total Quality Management) для повышения удовлетворенности потребителей, сотрудников, учета интересов общества и повышения производительности. Широко известная модель EFQM (Model of Business Excellence) может помочь в определении зрелости организации. Она определяет основные области внимания при управлении организацией:


26

В модель EFQM включен цикл Деминга, обеспечивающий постоянное улучшение на основании оценки работы и результатов. Модель EFQM определяет пять уровней/стадий внедрения TQM в организации: 1.

Product-focused, на котором исполнители ориентируются на получение непосредственных краткосрочных результатов деятельности;

2. Process-focused, или «мы знаем свою работу», когда деятельность в организации планируется и повторяется; 3. System-focused, “кооперация и сотрудничество между департаментами»; 4. Chain-focused, или «внешние партнерства», когда организация ориентируется на добавление ценности в цепочку, в которой она участвует; 5. Total quality-focused, он же «рай на земле», при котором постоянное сбалансированное улучшение становится естественной неотъемлемой частью организации. Перечисленные уровни внедрения TQM можно соотнести с моделью CMMI, описывающей 5 уровней зрелости организации: 1.

Начальный уровень (деятельность носит хаотичный реактивный характер);

2. Управляемый уровень (процессы планируются и исполняются в соответствии с планами); 3. Определенный уровень (процессы специфицированы, документированы и доносятся до исполнителей); 4. Измеримый уровень (для оценки производительности процессов определены и используются измеримые количественные показатели); 5. Оптимизируемый уровень (постоянное совершенствование и инновации).


27

Организация систем менеджмента качества в соответствии со стандартами серии ISO 9000, в частности – стандартом ISO 20000, может рассматриваться

как

способ

повышения

зрелости

организации

до

уровня

4

(«измеримый»).

3.3.6.

Про другие стандарты и подходы Про сертификацию и структуру стандарта рассказано выше (см. «Сер-

тификация компаний» и «Область применения и структура стандарта»). Обзор стандартов и подходов предполагает, что экзаменуемый понимает, что мир управления ИТ не ограничивается стандартом ISO/IEC 20000 и ITIL. Прямых вопросов на детальное знание какого-либо стандарта или подхода в экзаменах не встречается, необходимо общее представление направленности соответствующего стандарта или подхода. Кратко представим те подходы и стандарты, которые упоминаются в стандарте ISO/IEC 20000 и/или могут встретиться в вопросах экзамена Foundation. CMMI – развитие методологии CMM (см. Постоянное улучшение), которая разрабатывалась со второй половины 1980-х годов Software Engineering Institute (SEI) в университете Карнеги-Меллона (Carnegie Mellon University). COBIT – подход, разработанный IT Governance Institute и ISACA как руководство в области IT Governance (Руководства ИТ). Руководство, в отличие от управления (management), направлено на формирование границ и правил для системы управления и обеспечение на стратегическом уровне уверенности в эффективности этой системы. SixSigma® – структурированный подход к улучшению процессов, основанный на статистических данных ISO 15504, или SPICE (Software Process Improvement and Capability Determination) – стандарт, регламентирующий подход к оценке зрелости процессов. Основан на нескольких моделях зрелости, включая CMM, и стандарте ISO 12207, регламентирующем жизненный цикл программного обеспечения. ISO/IEC 27001, ISO/IEC 27002 – стандарты в области ИБ, пришедшие на смену ISO 17799. Содержат требования в области информационной безопасности для создания, развития и поддержания Системы менеджмента информационной безопасности. Корпоративные и отраслевые подходы и стандарты, такие как eTOM (enhanced Telecom Operations Map), содержат требования и/или рекомендации по созданию систем управления с учетом особенностей предприятия и/или отрасли. Так, eTOM является стандартом de facto для организации управления в телекоммуникационной отрасли. В частности, содержит раздел, посвященный организации управления услугами.


28

3.3.7.

Требования к системе управления ИТ-услугами (в соответствии с Частью 1 стандарта ISO/IEC 20000) Эта часть экзамена проверяет знания основных аспектов первой части

стандарта (требований). Для успешной сдачи экзамена не требуется дословное знание списков, необходимо общее понимание целей системы управления и процессов, а также направления требований к ним. Ниже приведен адаптированный перевод стандарта в соответствии с экзаменационными требованиями.

3.3.8.

Требования к управлению и совершенствованию процессов ITSM Эта часть стандарта включает в себя определение цели системы управ-

ления ИТ-услугами и содержит 4 группы требований (Требования к руководству,

Требования

к

документированию,

Требования

к

компетенции,

осведомленности и подготовке персонала, Требования к мониторингу, измерению, оценке и улучшению процессов), а также описание принципов формирования плана управления услугами и порядка применения методологии P-D-C-A к управлению ИТ-услугами.

Цель системы управления: Создать систему управления, включая политики и структурированный подход, реализующую эффективное предоставление и управление всеми ИТуслугами в организации.

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

• установить цели, определить политику, и сформировать планы по управлению услугами;

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

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

• назначить представителя руководства, ответственного за координацию и управление всеми услугами (ответственного руководителя);

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


29

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

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

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

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

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

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

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


30

• соответствуют плану управления ИТ-услугами и требованиям настоящего стандарта;

• эффективно выполняются и остаются актуальными. Должна быть запланирована программа аудита процессов управления ИТ-услугами с учетом состояния и важности этих процессов и областей, подлежащих аудиту, а также результатов предыдущих аудитов. В процедуре аудита должны быть определены критерии, область действия, частота и методы проведения аудита. Выбор аудиторов и проведение аудита должны гарантировать объективность и беспристрастность аудита. Аудиторы не должны проводить проверку своей собственной работы. Цель проведения анализа, оценки и аудита управления ИТ-услугами должна быть зафиксирована вместе с их результатами и описанием выявленных корректирующих действий. Любые существенные несоответствия или области, вызывающие беспокойство, выявленные в результате проведения аудита, должны быть доведены до сведения заинтересованных сторон.

Принципы формирования плана управления услугами План управления услугами должен определять:

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

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

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

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

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

• ресурсы, средства и бюджет, необходимые для достижения поставленных целей;

• соответствующий инструментарий для поддержки процессов управления услугами;

• порядок реализации управления качеством предоставляемых услуг, способы проверки (аудита) и улучшения качества этих услуг.


31

Применение методологии P-D-С-A для управления ИТ-услугами Методика, известная как цикл «Планирование – Выполнение – Проверка – Корректировка» (Plan-Do-Check-Act, PDCA), может быть применена ко всем процессам управления услугами. Цикл PDCA можно описать так:

• Планирование (Plan) – установите цели управления услугами и определите процессы, нужные для получения результатов, соответствующих требованиям заказчиков и политике поставщика услуг;

• Выполнение (Do) – внедрите процессы; • Проверка (Check) – контролируйте и измеряйте соответствие процессов и услуг политике, целям управления услугами, требованиям заказчиков и предоставляйте отчетность о полученных результатах;

• Корректировка (Act) – предпринимайте действия по постоянному повышению эффективности процессов.

3.3.9.

Требования к процессам контроля В этот экзаменационный раздел вошли определение цели планирова-

ния и внедрения новых/изменяемых услуг и требования к составу плана по внедрению. Кроме этого в этом разделе объединены процессы контроля (процесс управления конфигурациями, процесс управления изменениями) и процесс управления релизами. Необходимо знать цели этих процессов и требования к ним.

Цель планирования и внедрения новых / изменяемых услуг Гарантировать, что новые и измененные услуги будут предоставляться и управляться в соответствии с согласованными затратами и качеством услуг.


32

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

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

• изменения в существующей системе управления услугами и в самих услугах;

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

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

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

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

Процесс управления конфигурациями: цели и требования Цель: Определять и контролировать компоненты услуг и инфраструктуры, а также поддерживать точную, целостную и актуальную информацию о конфигурациях. Требования:

• Должна существовать политика, определяющая понятие конфигурационной единицы (КЕ) и её составных частей.

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

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


33

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

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

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

• До релиза в среду промышленной эксплуатации, должны быть созданы базовые состояния (baseline) необходимых конфигурационных единиц.

• Мастер копии цифровых конфигурационных единиц (например, программное обеспечение, средства тестирования, сопровождающая документация) должны находиться под контролем в защищенных физических или электронных библиотеках и иметь взаимосвязи с конфигурационными записями.

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

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

Процесс управления изменениями: цели и требования Цель: Гарантировать осуществление контролируемой оценки, утверждения, внедрения и обзора изменений. Требования:

• Изменения услуг и инфраструктуры должны иметь четко определённый и задокументированный охват.

• Все запросы на изменения должны быть записаны и классифицированы, например, срочные, значительные, несущественные. Для запросов на изменение должна производиться оценка рисков, влияния и выгод для бизнеса.

• Процесс управления изменениями должен включать в себя способ отмены или исправления изменения в случае неудачи.


34

• Изменения должны утверждаться, проверяться, внедряться контролируемым способом. Для всех изменений должен производиться обзор успешности внедрения, а также любых предпринятых после внедрения действий.

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

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

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

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

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

• Политика релиза, устанавливающая частоту и типы релизов, должна быть задокументирована и согласована.

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

• Процесс управления релизами должен включать в себя способ отмены или исправления релиза в случае неудачи.

• В планах должны быть записаны даты и результаты релизов, а также ссылки на связанные запросы на изменения, известные ошибки и проблемы.

• Процесс управления релизами должен передавать соответствующую информацию в процесс управления инцидентами.

• Должно оцениваться влияние запросов на изменение на планирование релизов.


35

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

• Управление срочными релизами должно осуществляться согласно определенному процессу, имеющему интерфейсы с процессом управления срочными изменениями.

• Для сборки и тестирования (до распространения) всех релизов, должна быть создана контролируемая среда приёмочного тестирования.

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

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

3.3.10.

Требования к процессам управления взаимоотношениями ИТ и бизнеса Эта часть состоит из процессов управления взаимоотношениями (про-

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

Процесс управления уровнем услуг: цели и требования Цель: Определять, согласовывать, регистрировать и управлять уровнями услуг. Требования:

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

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


36

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

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

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

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

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

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

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

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

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

− несоответствия и проблемы, например, нарушение параметров безопасности или условий соглашений об уровнях услуг;

− рабочую нагрузку, например, объем, привлечение ресурсов; − отчеты по производительности после значительных событий, например, значимых инцидентов или изменений;

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


37

Бюджетирование и учет затрат для ИТ-услуг: цель и требования Цель: Осуществлять бюджетирование и учёт затрат на предоставление услуг. Требования:

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

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

− эффективного финансового контроля и авторизации. • Затраты на предоставление услуг должны включаться в бюджет с детализацией, достаточной для эффективного финансового контроля и принятия решений.

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

• Затраты на изменения услуг должны оцениваться и утверждаться в рамках процесса управления изменениями.

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

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

• Поставщик услуг и заказчик не менее одного раза в год должны производить обзор услуг для обсуждения изменений в охвате, соглашениях об уровне услуг, контрактах (при их наличии) или потребностях бизнеса; а также проводить промежуточные встречи через согласованные интервалы времени для обсуждения производительности, достижений, проблем и планов действий. Эти встречи должны документироваться. Иные заинтересованные лица также могут приглашаться на встречи. Следствиями таких совещаний будут являться изменения в контракте (ах), в случае их наличия, и в соглашениях об уровне услуг. Эти изменения должны контролироваться в рамках процесса управления изменениями.


38

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

• Должен существовать процесс обработки жалоб. Определение формальной жалобы, связанной с услугой, должно быть согласовано с заказчиком. Все формальные жалобы должны быть записаны поставщиком услуг, исследованы, обработаны, формально закрыты и по ним должна быть предоставлена отчетность. Для случаев, когда удовлетворение жалобы утвержденным порядком невозможно, заказчику должна быть доступна возможность её эскалации.

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

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

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

Процесс управления поставщиками: цель и требования Цель: Управлять поставщиками для гарантии предоставления целостных, качественных услуг.

Примечания:

• Стандарт не охватывает процесс выбора поставщиков. • Поставщики могут использоваться для предоставления некоторой части услуги. Требования:


39

• Поставщик услуг (service provider) должен иметь задокументированный процесс управления поставщиками, а также для каждого поставщика персонально ответственного менеджера контракта.

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

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

• Интерфейсы между процессами, используемые каждой стороной, должны быть задокументированы и согласованы.

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

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

• Должен существовать процесс управления договорными разногласиями.

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

• Должен осуществляться мониторинг производительности и проводиться обзор её соответствия целевыми показателями уровня услуги.

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

3.3.11.

Требования к процессам предоставления услуг В эту часть необходимых знаний для подготовки к экзамену вошли 3

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


40

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

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

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

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

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

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

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

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

Процесс управления мощностями: цель и требования Цель: Гарантировать, что поставщик услуг всегда будет иметь запас мощностей, достаточный для выполнения текущих и будущих согласованных потребностей бизнес заказчика. Требования:


41

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

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

− текущие и прогнозируемые требования к мощностям и производительности;

− идентифицированные графики, пороговые значения и затраты на модернизацию услуг;

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

− прогнозируемое влияние внешних изменений, например, изменений законодательства;

− данные и процессы, необходимые для превентивного анализа производительности.

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

Процесс управления информационной безопасностью: цель и требования Цель: Эффективно управлять информационной безопасностью в рамках любой деятельности, связанной с услугами. Требования:

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

• Соответствующие контроли безопасности должны функционировать с целью:

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

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

• Влияние изменений на контроли должны оцениваться до внедрения этих изменений.

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


42

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

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

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

3.3.12.

Требования к процессам поддержки услуг В этот раздел вошли цели процессов разрешения (процесса управления

инцидентами и процесса управления проблемами) и требования к ним.

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

• Все инциденты должны быть записаны. • Должны быть приняты процедуры управления степенью влияния инцидентов.

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

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

• Весь персонал, вовлеченный в процесс управления инцидентами, должен иметь доступ к необходимой информации об известных ошибках, решениях проблем и к базе данных управления конфигурациями (CMDB).

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


43

Процесс управления проблемами: цель и требования Цель: Минимизировать потери для бизнеса путем проактивного определения и анализа причин инцидентов и управления проблемами вплоть до их закрытия. Требования:

• Все идентифицированные проблемы должны быть записаны. • Должны быть внедрены процедуры идентификации, минимизации или устранения отрицательного влияния инцидентов и проблем. Эти процедуры должны определять запись, классификацию, обновление/дополнение информации, эскалацию, разрешение и закрытие всех проблем.

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

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

• Должен проводиться мониторинг, обзор и предоставление отчетности по эффективности решения проблем.

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

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

3.3.13.

Рекомендации и практики по управлению услугами (в соответствии Частью 2 ISO/IEC 20000) Эта часть экзамена проверяет общее знание тех рекомендаций, которые

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

3.3.14.

Рекомендации и практики для управления и совершенствования процессов ITSM В этом разделе представлены рекомендации в области ответственности,

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


44

Рекомендации и практики в области ответственности руководства:

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

• В обязанности ответственного руководителя следует включить обеспечение ресурсов для постоянной или проектной деятельности по улучшению услуг

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

Рекомендации и практики в области документирования:

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

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

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

− − − − −

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

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

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


45

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

• определить необходимые требования к уровню компетентности для каждой роли в управлении услугами

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

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

• обеспечивать подготовку персонала или предпринимать другие действия для удовлетворения данных требований к уровню компетентности персонала

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

• подбору персонала: проверять достоверность сведений о кандидатах на должность (включая их профессиональную квалификацию), а также выявлять их сильные и слабые стороны, оценивать соответствие их потенциальных возможностей должностным инструкциям/профилю, целям управления услугами и общим целям обеспечения качества предоставляемых услуг

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

• подготовке и развитию: определять требования к подготовке и развитию персонала, формировать план подготовки и развития, а также обеспечивать своевременную и результативную реализацию этих требований. Персонал должен быть подготовлен по соответствующим вопросам управления услугами (например, посредством подготовительных курсов, самостоятельного обучения, наставничества и специализированной подготовки). Также у персонала должны быть развиты руководящие навыки и навыки работы в команде. Хроноло-


46

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

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

• краткосрочный или длительный характер действия новых или измененных требований к уровню компетентности персонала

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

• доступность персонала с соответствующей компетентностью • уровень текучести кадров • планы подготовки персонала Поставщику услуг следует не реже одного раза в год анализировать результаты труда каждого сотрудника и принимать соответствующие меры.

3.3.15.

Рекомендации и практики в области планирования и выполнения управления услугами

Подходы к планированию

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

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


47

• В план управления услугами следует включить: − реализацию (внедрение) управления услугами (или части управления услугами)

− − − −

обеспечение работы процессов управления услугами изменения в процессах управления услугами улучшение процессов управления услугами новые услуги (в части их влияния на процессы в рамках согласованной области применения управления услугами)

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

• • • • •

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

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

• область и границы применения управления услугами с точки зрения поставщика услуг

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

• ресурсы, средства и бюджет, необходимые для достижения поставленных целей

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

• взаимосвязи (интерфейсы) между процессами управления услугами и способ координации действий и/или процессов управления услугами

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

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


48

• подход к изменению плана управления услугами и изменению самих услуг

• подход поставщика услуг к демонстрации непрерывного контроля качества (например, периодический аудит)

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

Рекомендации по выполнению

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

• Необходимо производить измерение и анализ процессов и услуг: − фактически достигнутые показатели по предоставлению услуг по сравнению с определенными целевыми значениями

− − − −

удовлетворенность заказчиков услуг загруженность ресурсов тенденции значительные несоответствия

Результаты такого анализа следует использовать в качестве исходной информации для формирования плана улучшения услуг.

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

• Внутренний аудит − аудит первой стороны, проводится для внутренних целей самой организацией

• Внешние аудиты − аудит второй стороны, проводится сторонами, заинтересованными в деятельности организации, например, потребителями или другими лицами от их имени


49

− аудит третьей стороны, проводится внешними независимыми организациями, которые сертифицируют на соответствие требованиям стандартов

Принципы проведения внутренних аудитов и оценки обнаружений

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

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

• Выбор аудиторов и порядка проведения аудита должен гарантировать объективность и беспристрастность процесса аудита. Аудиторы не должны проверять свою собственную работу

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

• Все значительные несоответствия и риски должны быть донесены до ответственных за данные области сотрудников

3.3.16.

Рекомендации и практики для процессов контроля В эту часть вошли рекомендации по оценке при планировании новых /

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

Рекомендации по оценке при планировании новых/изменяемых услуг: При планировании новых или измененных услуг следует провести оценку:

• • • •

бюджетов ресурсов персонала существующих уровней услуг соглашений об уровне услуг и других целей или обязательств по предоставлению услуг

• существующих процессов, процедур и документации по управлению услугами

• охвата управления услугами, с учетом внедрения ранее не реализованных процессов управления услугами


50

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

• • • • • •

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

Рекомендации и практики в области процесса управления конфигурациями: Планирование и реализация управления конфигурациями

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

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

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

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


51

− охват, цели, политики, стандарты, роли и ответственности по управлению конфигурациями

− процедуры управления конфигурациями для идентификации конфигурационных единиц, входящих в состав услуги (услуг) и инфраструктуры, для контроля изменений в конфигурациях и формирования отчетности о статусах конфигурационных единиц, а также для проверки (верификации) полноты и корректности информации о конфигурационных единицах

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

− порядок контроля конфигураций (порядок контроля доступа к конфигурациям, контроля версий, сборок и релизов)

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

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

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

Идентификация конфигураций

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

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

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


52

− все информационные системы и их модификации, все программные средства и их версии (включая программные средства третьей стороны), связанную с ними техническую и эксплуатационную документацию

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

− документальные копии и электронные библиотеки, например, библиотеки эталонного программного обеспечения

− инструментарий, используемый для автоматизации управления конфигурациями

− лицензии − компоненты, предназначенные для обеспечения информационной безопасности, например, брандмауэры (сетевые экраны)

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

− документацию, связанную с управлением услугами, например, Соглашения об уровне услуг, описания процедур

− вспомогательные средства и системы для поддержки предоставления услуг, например, средства электроснабжения

− сведения о взаимосвязях и взаимозависимостях между конфигурационными единицами

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

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

Контроль конфигураций

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

• Ни одна конфигурационная единица не должна быть добавлена, модифицирована, изменена или удалена (снята с учета), без записи в соответствующей документации, например, без утвержденного запроса на изменение, обновленной информации о внедренном релизе


53

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

− защищает информацию о конфигурационной единице от несанкционированного доступа, изменения или от порчи, например, от компьютерных вирусов

− предоставляет средства для восстановления информации после сбоев

− позволяет провести контролируемое восстановление, например, с мастер-копии программного обеспечения

Учет статусов конфигураций и отчетность

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

• Учёт статусов конфигураций и составление отчетности должны обеспечивать предоставление информации о текущем состоянии каждой из конфигурационных единиц и информации о её состояниях в прошлом в течение всего жизненного цикла конфигурационной единицы. Это позволит отслеживать изменения конфигурационных единиц по мере изменений их состояний, например, «заказано», «получено», «на приёмочных испытаниях», «в работе», «изменено», «снято с учета», «удалено»

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

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

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

− сведения о последней версии конфигурационной единицы


54

− информацию о месторасположении конфигурационной единицы, а для программных средств, дополнительно, информацию о месторасположении мастер-копии

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

Верификация и аудит конфигураций

• Следует планировать проведение верификации (проверки) и аудита (физического и функционального) для гарантии того, что существуют процессы и ресурсы, которые позволяют:

− обеспечить сохранность физических конфигураций и интеллектуальной собственности организации

− гарантировать, что поставщик услуг контролирует применяемые конфигурации

− обеспечить уверенность в том, что информация о конфигурациях доступна, что она точна и контролируема

− гарантировать, что изменение, релиз, система или среда соответствуют договорным требованиям или другим специфицированным требованиям, и что записи о соответствии конфигурации требованиям точны.

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

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

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


55

соответствует начальным конфигурационным параметрам «на момент поставки», содержащимся в технических и эксплуатационных документах

Рекомендации и практики в области процесса управления изменениями Планирование и реализация изменений В процессах и процедурах управления изменениями следует обеспечить, что:

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

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

• проводится календарное планирование реализации изменений с учётом их приоритетов и рисков

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

• сроки реализации изменений контролируются и уточняются (при необходимости)

• есть возможность продемонстрировать, каким образом изменение: − инициировано, зарегистрировано и классифицировано (со ссылкой на соответствующий документ)

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

− отменено, с возвратом в исходное состояние, или исправлено в случае неудачи при его реализации

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

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

− осуществлено назначенным сотрудником из состава команды, ответственной за компоненты, над которыми производится изменение

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


56

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

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

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

Анализ и закрытие запроса на изменение

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

− в результате проведения изменения были достигнуты поставленные цели

− заказчики услуг удовлетворены результатами изменения − изменение не вызвало непредвиденных отклонений в предоставлении услуг

− все нарушения зарегистрированы для принятия необходимых мер

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

Срочные изменения

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

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

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

Отчетность, анализ изменений и последующие действия


57

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

• Выводы и результаты анализа следует регистрировать • В соответствии с результатами анализа следует планировать дальнейшие действия

Рекомендации и практики в области процесса управления релизами

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

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

• Все обновления документации, связанные с релизом, следует включить в этот релиз

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

• Поставщик услуг должен обеспечить учет всех аспектов внедрения релиза, а не только технических

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

Политика релизов Следует разработать политику релизов, включающую:

• частоту создания (выпусков новых) релизов и типы релизов • роли и ответственности в области управления релизами • правила передачи релиза в среду тестирования и в действующую среду

• правила уникальной идентификации (нумерации) релизов и правила описания релизов

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


58

• порядок проверки и приемки релиза Планирование релиза и планирование развертывания релиза

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

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

• Должен быть запланирован порядок утверждения, координации и отслеживания релиза

• В связи с тем, что при разработке релиза особенности его развёртывания могут быть изначально не известны, разрабатывать релиз и планировать его развертывание в действующую среду следует поэтапно.

• Планирование релиза и его развёртывания обычно включает следующие действия:

− определение сроков выпуска релиза и описание его назначения − ссылки на изменения, проблемы и известные ошибки, решаемые с помощью этого релиза, а также на известные ошибки, которые были обнаружены во время его тестирования

− процедуры внедрения релиза во всех территориальных и структурных подразделениях организации

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

− определение порядка проверки и приемки релиза − определение процедур взаимодействия персонала заказчика и поставщика услуг, порядка проведения обучения

− определение порядка закупки, хранения, доставки, подключения, принятия в эксплуатацию и вывода активов из эксплуатации

− определение ресурсов, необходимых для поддержания согласованного уровня услуг

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

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

Разработка и приемка программных средств


59

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

Проектирование, сборка и конфигурирование релиза Следует разработать и внедрить процедуры выпуска релиза и его распространения в действующую среду с целью:

• обеспечения соответствия релиза установленным нормам поставщика услуг по архитектуре инфраструктуры и систем и требованиям управления услугами

• обеспечения целостности услуг и инфраструктуры во время компоновки, сборки и распространении релиза

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

• чёткого определения рисков и порядка реагирования на них при необходимости

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

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

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


60

• удостовериться, что среда приёмочных испытаний соответствует требованиям, установленным для действующей среды

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

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

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

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

• удостовериться до начала установки, что действующая программнотехническая среда удовлетворяет определённым для нее требованиям

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

• документацию, обеспечивающую поддержку услуг, например, Соглашения об уровне услуг, общее описание системы, процедуры установки и поддержки, средства диагностики, инструкции по эксплуатации и администрированию системы

• описание процедур сборки, конфигурирования, установки и распространения релиза

• план действий в чрезвычайных ситуациях и план возврата в исходное состояние

• график подготовки персонала поставщика услуг и персонала заказчика услуг

• базовое состояние конфигурации релиза, включая информацию о связанных с ним конфигурационных единицах

• описание изменений, проблем и известных ошибок, связанных с релизом

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


61

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

Развертывание, распространение и инсталляция релиза Следует произвести анализ и уточнение плана развертывания для обеспечения исполнения всех мероприятий, необходимых для развёртывания релиза. Процедуры развёртывания, распространения и инсталяции релиза должны обеспечить, что:

• все места, выделенные для хранения аппаратных и программных средств, должным образом защищены

• существуют соответствующие регламенты доставки, хранения, приемки и вывода из эксплуатации

• проверено электроснабжение и вспомогательное оборудование, необходимое для внедрения релиза

• персонал заказчиков услуг и персонал поставщика услуг извещён о внедрении релиза

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

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

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


62

бизнес заказчиков и персонал поставщика услуг, вовлеченный в поддержку и эксплуатацию

• Процесс управления изменениями должен включать в себя анализ результатов внедрения релиза

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

3.3.17.

Рекомендации и практики для процессов управления взаимоотношениями ИТ и бизнеса В эту часть вошли рекомендации и практики в области управления

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

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

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

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

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

• Услугу следует формально документировать в Соглашении об уровне услуг

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


63

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

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

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

• краткое описание услуги • срок действия и/или механизм контроля изменений в Соглашении об уровне услуг

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

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

• дни и часы предоставления услуги, например, с 09:00 до 17:00, время, когда услуга недоступна (например, выходные, праздники и др.), периоды, критичные для бизнеса заказчика, а также дни и часы, не вошедшие в часы предоставления услуги

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

• • • • • • •

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


64

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

• финансовую информацию высокого уровня, например, коды для отнесения затрат

• действия, которые необходимо предпринять в случае прерывания предоставления услуги

• • • •

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

Примечание:

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

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

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

Процесс управления уровнем услуг

• Значительные изменения в бизнесе заказчиков услуг, например, вследствие развития, реорганизации бизнеса или слияния организаций, а также изменение требований заказчика, могут потребовать пересмотра и корректировки уровня предоставления услуг. Процесс управления уровнем услуг должен быть достаточно гибким для того, чтобы учитывать эти изменения

• Процесс управления уровнем услуг должен обеспечивать, что внимание поставщика услуг сосредоточено на бизнесе заказчика на протяжении всего жизненного цикла услуг (планирование, внедрение, предоставление и поддержка услуг)

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

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


65

− согласование требований к предоставлению услуг и к ожидаемым объемам услуг

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

− согласование порядка инициации корректирующих действий − согласование порядка предоставления информации для планирования улучшения услуг

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

• Удовлетворенность заказчиков является важной частью процесса управления уровнем услуг, но её следует рассматривать как субъективную составляющую, тогда как целевые показатели уровня услуг, включенные в Соглашения об уровне услуг, должны быть объективными параметрами

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

Соглашения о поддерживающих услугах Соглашения о поддерживающих услугах, от которых зависит услуга, предоставляемая заказчику, должны быть документированы и согласованы со всеми поставщиками. Это требование распространяется также и на внутренние группы сотрудников поставщика услуг, предоставляющих части услуг, от которых зависит конечная услуга, предоставляемая заказчику.

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

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

• Мониторинг услуг и формирование отчетности охватывает все измеряемые параметры услуги, обеспечивая анализ текущего состояния и исторических данных

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


66

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

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

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

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

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

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

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

Отчеты по услугам Поставщику услуг следует составлять отчеты для заказчиков и руководства поставщика услуг, включающие в себя:

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

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

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

• информацию о формирующихся тенденциях в предоставлении услуг за период (например, за день, за неделю, за месяц)

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


67

речень наименее надежных компонентов инфраструктуры, ресурсоемкие/дорогостоящие работы

• информацию, отражающую запланированную и прогнозируемую загрузку в предоставлении услуг

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

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

• степень детализации бизнеса заказчика, например, рассмотрение структурной единицы (бизнес-единицы) как единого целого или разделение её на департаменты или подразделения по местоположению

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

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

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


68

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

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

Рекомендации и практики в области управления взаимоотношениями ИТ и бизнеса Анализ услуг

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

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

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


69

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

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

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

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

Жалобы, связанные с предоставлением услуг

• Поставщику услуг и заказчику следует согласовать формальную процедуру подачи жалоб

• Поставщику услуг необходим действующий процесс для решения спорных вопросов

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

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

• Остающиеся неразрешёнными жалобы следует регулярно анализировать и докладывать руководству, если их не удалось решить в течение сроков, согласованных с заказчиком

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

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

Оценка удовлетворенности заказчиков

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


70

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

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

• Результаты и выводы опросов удовлетворенности следует обсудить с заказчиками услуг. Должен быть согласован план необходимых действий, который будет включен в план улучшения услуг. Заказчик должен быть информирован о результатах выполнения согласованных действий

• Положительные отзывы о результатах работы также следует документировать и доводить до сведения персонала поставщика услуг

Рекомендации и практики в области управления поставщиками Следует организовать процедуры управления поставщиками, обеспечивающие следующее:

• Каждый поставщик понимает свои обязательства перед поставщиком услуг

• требования законодательства, а также согласованные требования к уровню и охвату услуг выполняются

• изменения осуществляются управляемым образом • взаимодействие по обращениям бизнес-пользователей регистрируются всеми сторонами

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

Управление договорами

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

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


71

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

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

• Список контактов в соответствующих организациях (поставщиков и поставщика услуг) следует поддерживать в актуальном состоянии

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

Определение услуги Для каждой услуги и каждого поставщика поставщику услуги следует поддерживать в актуальном состоянии следующую информацию:

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

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

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

требованиями,

изложенными

в

первой

части

стандарта

ISO/IEC20000.

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


72

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

Закрытие (расторжение) контракта В процесс управления контрактами следует включить положение о закрытии контракта – запланированном или досрочном. Также процесс должен обеспечивать передачу поставщиком права на предоставление услуги от одного поставщика другому.

3.3.18.

Рекомендации и практики для процессов предоставления услуг В этот раздел вошли рекомендации и практики в области трех процес-

сов предоставления услуг: управления непрерывностью и доступностью услуг, управления мощностями и управления информационной безопасностью

Рекомендации и практики в области процесса управления непрерывностью и доступностью услуг

• Обязательства поставщика по обеспечению непрерывности и доступности услуг следует определять с учетом приоритетов бизнеса заказчика, Соглашений об уровне услуг и оценки рисков

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

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

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

• Для обеспечения предоставления согласованных уровней услуг управление доступностью и управление непрерывностью услуг должны планироваться и исполняться совместно


73

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

Мониторинг доступности и другие виды деятельности по обеспечению доступности услуг Следующие виды деятельности следует реализовать в рамках управления доступностью:

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

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

• документирование и анализ выявленных несоответствий фактической и плановой доступности услуг и компонентов

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

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

• максимально допустимую продолжительность незапланированного прекращения предоставления услуги

• максимально допустимую продолжительность предоставления услуги со сниженным качеством

• допустимый уровень понижения качества предоставления услуги во время её восстановления Стратегию непрерывности услуг следует пересматривать через согласованные интервалы времени, но не реже одного раза в год. Любые изменения в стратегии должны быть формально согласованы.

Планирование и тестирование непрерывности услуг Поставщику услуг следует обеспечить, что:


74

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

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

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

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

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

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

Рекомендации и практики в области управления мощностями

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

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


75

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

• Процесс управления мощностями должен содействовать созданию новых и внесению изменений в существующие услуги посредством предоставления сведений об объемах (производительности) услуг и моделирования услуг

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

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

• Организации следует иметь четкое понимание своей технической инфраструктуры, а также её текущих и прогнозируемых потенциальных возможностей

Рекомендации и практики в области управления информационной безопасностью Информационная безопасность – это результат реализации комплекса политик и процедур, созданных для идентификации, контроля и защиты информации, а также любого оборудования, используемого для хранения, передачи и обработки информации. Всему персоналу поставщика услуг и, в первую очередь, специалистам по обеспечению информационной безопасности, следует быть хорошо знакомыми с ISO/IEC 17799, Сводом практик для управления информационной безопасностью».

Идентификация и классификация информационных активов Поставщику услуг следует:

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


76

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

• ответственность за защиту информационного актива возложить на владельца этого актива

Меры по оценке рисков в области безопасности Оценка рисков в области безопасности должна:

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

• способствовать пониманию того, что может повлиять на услугу, находящуюся под управлением

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

Риски, связанные с информационными активами Риски, связанные с информационными активами, следует оценивать с учетом:

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

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

• возможности получения конфиденциальной информации сторонами, не имеющими на это прав

• неточности, неполноте или недостоверности информации • недоступности информации для использования (например, из-за нарушения энергоснабжения)

• физическому повреждению или уничтожению оборудования, необходимого для предоставления услуг Также необходимо учесть цели политики информационной безопасности, необходимость выполнения особых требований заказчика услуг в области информационной безопасности (например, к уровню доступности информации) и установленные законодательством или регулирующими органами требования по обеспечению информационной безопасности.


77

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

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

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

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

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

• весь персонал должен быть ознакомлен с политикой информационной безопасности

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

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

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

Документы и записи Записи в области информационной безопасности следует периодически анализировать для предоставления руководству сведений:

• об эффективности политики информационной безопасности • о выявленных тенденциях в части инцидентов в области информационной безопасности

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


78

3.3.19.

Рекомендации и практики для процессов поддержки услуг В этой части рассматриваются рекомендации и практики в области

управления инцидентами и проблемами.

Общие рекомендации для процессов разрешения Управление инцидентами и управление проблемами являются отдельными процессами, но они тесно взаимосвязаны. В рамках управления инцидентами принимаются меры по восстановлению услуги, а в рамках управления проблемами – по выявлению и устранению причин инцидентов.

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

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

• Приоритет следует определять на основе учёта степени влияния и срочности

• Степень влияния следует определять на основании размера фактического или потенциального ущерба от инцидента или проблемы для бизнеса

• Срочность следует определять на основании времени от момента обнаружения инцидента или проблемы до момента, начиная с которого инцидент или проблема начнет оказывать существенное отрицательное влияние на бизнес При определении порядка устранения инцидентов или решения проблем, необходимо обращать внимание на следующее:

• • • • •

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

Примечание: понятие «приоритет» используется практически во всех процессах управления услугами, но своё основное применение приоритет находит в процессах управления инцидентами и управления проблемами

Обходные решения

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


79

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

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

• Информацию об обходных решениях необходимо хранить в базе знаний

• Информацию о применимости и эффективности обходных решений следует сохранять и поддерживать в актуальном состоянии

Рекомендации и практики в области управления инцидентами Примечание 1: Процесс управления инцидентами может быть реализован с помощью Службы Сервис-деск, которая действует как точка ежедневного контакта с пользователями. Примечание 2: Процесс управления инцидентами следует организовать таким образом, чтобы он был как проактивным, так и реактивным процессом, реагирующим на инциденты, которые влияют или потенциально могут повлиять на услугу и её предоставление, и ориентированным на восстановление предоставления заказчику согласованной услуги, а не на выявление причин инцидентов.

• В охват процесса управления инцидентами следует включить: − прием обращений, регистрацию, назначение приоритета и классификацию

− устранение инцидента на первой линии или назначение на вторую линию для дальнейшей обработки

− рассмотрение возможных вопросов информационной безопасности

− отслеживание и управление инцидентом на всех этапах его жизненного цикла

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

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


80

гистрации инцидентов, или на основании сообщений от систем автоматического мониторинга

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

• Информацию о достигнутых результатах в ходе решения инцидента, следует доводить до сведения тех сотрудников, на деятельность которых он влияет, или которые могут потенциально оказаться под влиянием этого инцидента

• Все действия по работе с инцидентом должны быть зарегистрированы в записи об инциденте

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

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

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

• Окончательное закрытие инцидента следует производить только после того, как пользователь, сообщивший об инциденте, подтвердил, что инцидент устранен, и предоставление услуги восстановлено

Значительные инциденты

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

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

• Руководителю, отвечающему за устранение значительных инцидентов, следует предоставить персональные полномочия, позволяющие ему координировать управление всеми аспектами устранения значительных инцидентов


81

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

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

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

• В рамках процесса управления проблемами следует осуществлять предупреждение повторений инцидентов и известных ошибок. При этом необходимо руководствоваться требованиями бизнеса.

Инициация управления проблемами

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

Известные ошибки

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

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

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


82

• Известная ошибка не может быть закрыта раньше её успешного устранения Примечание: Заказчик или поставщик услуг могут прийти к выводу, что решение слишком дорого или не несет выгоды для бизнеса. В таком случае этот факт следует четко документировать. Запись об известной ошибке следует оставлять открытой, так как могут произойти последующие инциденты и/или могут

потребоваться

обходные

решения

и/или

потребуется

пересмотр

установленного способа решения проблемы.

Решение проблемы После того, как корневая причина инцидента определена и для её устранения определено решение, выполнение этого решения должно быть проведено через процесс управления изменениями.

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

Отслеживание и эскалация

• Ход решения всех проблем должен отслеживаться • Все спорные вопросы следует эскалировать соответствующим сторонам

• В процесс следует включить: − регистрацию передачи ответственности за обработку проблемы в течение её жизненного цикла

− выявление инцидентов, приводящих к нарушению целевых значений параметров услуг

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

− определение точек эскалации − регистрацию сведений об использованных ресурсах и принятых действиях


83

Закрытие инцидента и проблемы Процедура закрытия инцидента и проблемы должна включать в себя проверку, обеспечивающую что:

• точно зафиксированы сведения о способе разрешения • выполнена категоризация причины – для облегчения последующего анализа

• при необходимости, заказчик услуги и персонал, обеспечивающий её предоставление, осведомлены о разрешении проблемы

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

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

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

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

Задачи анализа проблем Анализ проблем должен включать:

• определение тенденций • выявление повторений проблем с конкретным компонентом услуги или инфраструктуры или компонентами с конкретным месторасположением

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

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

• выявление повторений ранее устранённых инцидентов и решённых проблем


84

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

Предупреждение проблем Проактивное управление проблемами должно вести к сокращению количества инцидентов и проблем. Проактивное управление проблемами должно опираться на информацию, способствующую проведению анализа, такую как:

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

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

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


85

1 of 40 The Relationship processes describe the relationships with the business and with the suppliers. What should the Relationship processes ensure? A. that all parties understand the business needs, responsibilities and obligations B. that the business and suppliers are directly informed of Major Incidents C. that the service levels for all services are consistent in the supply chain D. that there is a frequent contact between the suppliers and the business to resolve dissatisfaction issues

2 of 40 Why are processes required? A. to be able to define quality objectives in a structured manner B. to ensure that service issues never arise C. to provide consistency in the output from activities D. to satisfy the needs of major outsource providers

3 of 40 What is a benefit to an organization when the services are delivered according to ISO/IEC 20000? A. The environmental needs of the employees in the organization are well looked after. B. The organization becomes more process focused and thereby more efficient. C. The organization behaves in a socially responsible way. D. The organization has less suppliers to deal with.

4 of 40 The Plan-Do-Check-Act (PDCA) methodology can be applied to all ISO/IEC 20000 processes. What does the Act phase of this methodology cover? A. establishing the objectives and processes necessary to deliver results in accordance with Customer requirements and the organization's policies B. implementation of the processes C. monitoring and measuring processes and services and reporting the results D. taking the necessary actions to continually improve process performance


86

5 of 40 An approach to developing and implementing a Quality Management System consists of several steps. Which of the following is not a necessary step? A. agreeing to the quality policy and objectives with the Change Manager B. determining and providing the resources necessary to attain the quality objectives C. determining the needs and expectations of Customers and other interested parties D. establishing methods to measure the effectiveness and efficiency of each process

6 of 40 What is the primary purpose of analyzing Change records? A. to be able to open a new Problem record, so proactive identification of Incidents is possible B. to check if related Incident records are adequately closed C. to detect increasing levels of Changes and emerging trends D. to provide input to the Service Reporting process

7 of 40 Personnel should be competent on the basis of appropriate education and experience. Which of the following is a best practice relating to competence? A. Appropriate records of education, training, skills and experience need to be maintained. B. At least two employees should be suitably trained for each role. C. Employees should have at least a relevant bachelors degree. D. Personnel should all have a relevant Security training according to ISO/IEC 27002.

8 of 40 Which standard describes the fundamental aspects of Quality Management Systems? A. ISO 9000 B. ISO/IEC 15504 C. ISO/IEC 20000 D. ISO/IEC 27001


87

9 of 40 What is the objective of the Service Continuity and Availability Management processes? A. to ensure agreed effective communication towards Customers B. to ensure that agreed levels of service commitments to Customers can be met in all circumstances C. to ensure that agreed Service Continuity and Availability commitments to Customers can be met in all circumstances D. to ensure that agreed Service Continuity and Availability commitments to providers can be met in all circumstances

10 of 40 A group of activities within Release Management is roll-out, distribution and installation. What should be ensured as part of these activities? A. Changes are scheduled based upon priority and risk. B. Contingency and back-out plans are available. C. Redundant products, services and licenses are decommissioned. D. The Release is tested to the satisfaction of the Customers.

11 of 40 Top management has to provide evidence of its commitment to developing, implementing and improving its Service Management capability within the context of the organization's business and Customers' requirements. What is the best way that management can make this visible? A. by outsourcing Change Management B. by taking disciplinary action against underperforming employees C. by taking part in the planning of new IT services D. through leadership and actions

12 of 40 Which of the following is used as a set of guidance materials for IT governance? A. COBIT B. ISO 9000 C. ISO/IEC 20000 D. MOF


88

13 of 40 What is the objective of IT Service Management? A. to provide critical services to business customers B. to provide guaranteed service levels against business requirements C. to provide management of services to meet business requirements D. to provide services to the maximum level to the business

14 of 40 To which process shall Problem Management ensure that up-to-date information on Known Errors and corrected Problems is available? A. all ISO/IEC 20000 processes B. Availability Management C. Configuration Management D. Incident Management

15 of 40 Which type of event or activity can trigger a service Change, which would need to be catered for in the Service Management plan? A. Major Incident B. Service improvement activities C. System Lifecycle Management D. Urgent Change

16 of 40 Why is it important that reviews are conducted at regular intervals during the Check phase of the Plan-Do-Check-Act (PDCA) methodology? A. to be able to allocate roles and responsibilities B. to be able to define the objectives and requirements that are to be achieved by Service Management C. to be able to establish the Service Management policy, objectives and plans D. to determine whether the Service Management requirements are effectively implemented and maintained

17 of 40 What is the certification audit primarily based on?


89

A. personnel records B. process descriptions C. reports by certified financial auditors D. specifications

18 of 40 What is the correct way to make a change to a contract as a result of a major review of an authorized contract? A. through the Business Relationship Management process B. through the Change Management process C. through the Customer representative D. through the Supplier Management process

19 of 40 Targets for resolution should be based on priority. When scheduling Incident or Problem resolution, which of the following should not be taken into account? A. the available skills B. the competing requirements for resources C. the effort/cost to provide the method of resolution D. the number of previously reported Incidents for the particular Configuration Item (CI)

20 of 40 What is a responsibility of the Service Provider with regard to Supplier Management as defined in ISO/IEC 20000-1:2005? A. to ensure that a process exists for the procurement of suppliers B. to ensure that Service Level Agreements (SLAs) with suppliers are aligned with SLAs of the business C. to ensure that subcontracted suppliers meet contractual requirements in all circumstances D. to ensure that supplier processes and procedures are defined where outsourced


90

21 of 40 What details should be recorded as a baseline prior to implementing a plan for service improvement? A. backlog of changes for the service B. number of staff involved C. service quality and levels D. time taken to operate the process

22 of 40 What is SixSigma®? A. It is a quality instrument to measure defects in process outputs. B. It is a six step maturity model to improve the capability of business processes. C. It is a standard that is recently developed for improvement of IT processes. D. It is a structured, statistically based approach to process improvement.

23 of 40 How should the Deming cycle be used? A. as a model for continual improvement B. as a model for customer orientation C. as a model to be used during the design phase of the service D. as a model to calculate the costs of service improvement

24 of 40 What is the definition of Availability? A. a record containing details of which Configuration Items (CIs) are affected and how they are affected by an authorized Change B. a snapshot of the state of a service or individual Configuration Item (CI) at a point in time C. any event which is not part of the standard operation of a service and which causes or may cause an interruption to, or a reduction in, the quality of that service D. the ability of a component or service to perform its required function at a stated instant or over a stated period of time


91

25 of 40 New or changed services need to be accepted before being implemented into the live environment. What shall be done after a new or changed service has been implemented? A. A Post Implementation Review (PIR) is held comparing actual outcomes against those planned. B. An approach needs to be defined for interfacing to projects that are creating or modifying services. C. Nothing additional: the new or changed service goes into Business As Usual and will be managed as a normal service. D. The manner in which the Change shall be reversed or remedied if unsuccessful needs to be defined.

26 of 40 What is the recommendation with regard to the implementation of an emergency Change? A. Only the senior manager should authorize emergency Changes. B. The Change process should be completely bypassed. C. There is a separate process for emergency Changes. D. Where possible the Change process should be followed.

27 of 40 For which type of organizations is ISO/IEC 20000 appropriate for use? A. for organizations to confirm that all of the ITIL® guidelines have been implemented B. for organizations which need to demonstrate alignment to customer requirements C. for organizations wishing to certify their services D. for tool vendors to specify the Service Provider's processes

28 of 40 Any organization may be impacted by legislative or regulatory change in the future. Where should this be covered? A. in a Change request B. in the Business Relationship Management process C. in the Service Level Agreement (SLA)


92

D. in the Service Management plan

29 of 40 What level of Capacity is targeted by Capacity Management? A. sufficient Capacity to meet agreed current and future demands B. sufficient Capacity to meet all current and future demands C. sufficient Capacity to meet all development and operational requirements D. sufficient Capacity to meet current demands only

30 of 40 What does a quality policy aim to define? A. the formally expressed quality intentions and direction of an organization B. the legal obligations that the organization must fulfill C. the requirements of ISO/IEC 20000 D. the requirements of the customer as stated in the Service Level Agreement (SLA)

31 of 40 Which audit is conducted by, or on behalf of, the organization itself for internal purposes and can form the basis for an organization's self-declaration of conformity? A. First party audit B. Second party audit C. Third party audit D. Fourth party audit

32 of 40 In planning to implement Service Management, what does the plan need to say regarding tools according to ISO/IEC 20000-2:2005? A. The plan defines the tools as appropriate to support the processes. B. The plan details the effects of new technologies and techniques on capacity. C. The plan does not state any tools requirements. D. The plan lists how every individual process is supported by a tool.


93

33 of 40 Why is a scope statement for ISO/IEC 20000 important? A. It defines what the management system has been certified against B. It details all of the companies that have been certified C. It details all of the services that have been certified D. It identifies which processes have been excluded from the scope

34 of 40 Where would an IT service for the customer normally be defined? A. in the IT Framework B. in the Operational Level Agreement (OLA) C. in the Service Catalog or the Service Level Agreement (SLA) D. in the Service Report

35 of 40 What is required to be included in Release Management procedures according to ISO/IEC 20000? A. the authorization and implementation of emergency Changes B. the investigation and prevention of Security Incidents C. the recording of all reported Incidents D. the updating and changing o f configuration information and Change records

36 of 40 What should planning for new or changed services include? A. budgets and staff resources B. major non-conformities to all Underpinning Contracts (UCs) C. recent Problems and Known Errors in the desktop environment D. trends in Capacity growth of the current applications

37 of 40 What is required to be included in proposals for new or changed services according to ISO/IEC 20000? A. an updated Operational Level Agreement


94

B. cost, organizational, technical and commercial impact C. the policies, plans and procedures of each process or set of processes D. the Service Management plan

38 of 40 What purpose can the ISO/IEC 20000 standard serve? A. It defines specific Key Performance Indicators (KPIs) upon which service performance can be assessed. B. It defines the requirements to be satisfied in a certification audit. C. It helps to decide on the requirements that need to be verified within the scope of a supply agreement. D. It provides a yardstick for the design of a Total Quality Management System.

39 of 40 Why is it important for Service Providers to provide documents and records? A. It is part of the requirements (evidence) to become ISO/IEC 20000 compliant B. to be able to uniquely identify and record all Configuration Items (CIs) in the Configuration Management Database (CMDB) C. to ensure effective planning, operation and control of Service Management D. to ensure employees are aware of the relevance and importance of their work activities

40 of 40 Who should be recommended to support the Senior Responsible Owner in his/her responsibility for the delivery of the management system? A. a decision taking group B. the Change Advisory Board (CAB) C. the senior customer representative D. the service managers


95

3.5. Анализ пробного экзамена и комментарии к ответам Вопрос 1 Процессы управления взаимоотношениями описывают отношения с бизнесом и с поставщиками (suppliers). Что должны обеспечивать эти процессы? A. Что все стороны понимают бизнес-потребности, ответственность и обязательства B. Что бизнес и поставщики непосредственно информируются о значительных инцидентах C. Что уровни всех услуг постоянны на протяжении всей цепочки предоставления D. Что между поставщиками (suppliers) и бизнесом происходят достаточно частые контакты, чтобы устранить неудовлетворенность

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

Вопрос 2 Для чего нужны процессы? A. Чтобы можно было структурировано определять цели в области качества B. Чтобы не было нарушений качества услуг C. Чтобы обеспечить стабильность результатов работы


96

D. Чтобы удовлетворять потребности ведущих поставщиков

Комментарии: А. Нарушен порядок причинно-следственной связи. Сначала должны определяться цели в области управления качеством, затем на основании этих целей формироваться перечень необходимых процессов для реализации этих целей, их задачи, охват, и т.д. В. Эффективная работа процессов планирования, предоставления, взаимодействия, контроля, разрешения снижает как число нарушений качества услуг, так и уровень их влияния на бизнес, но не может гарантировать отсутствие таких нарушений. С. Верный ответ. Процессы направлены на достижение определенного результата наиболее рациональным способом. Для обеспечения стабильности

результатов

деятельности

в

процессах

предусмотрены

документирование процедур, промежуточные измерения, автоматизация и другие средства. D. Этот ответ справедлив только для некоторых процессов.

Вопрос 3 Какие преимущества получает организация, если предоставление услуг выполняется в соответствии с ISO/IEC 20000? A. Потребности сотрудников в области рабочей среды не остаются без внимания B. Организация становится более процесс-ориентированной, и как следствие – более рациональной C. Организация действует с более высоким уровнем социальной ответственности D. Организация может работать с меньшим числом поставщиков

Комментарии: A. Стандарт не определяет требований к рабочей среде сотрудников. Однако, как мера по рационализации деятельности (см. ответ В) может быть проведена оптимизация рабочей среды. В. Верный ответ. Наиболее полный ответ. Одно из основных преимуществ процессно-организованной деятельности – это достижение результата наиболее рациональным образом за счёт управления рациональностью деятельности. C. ISO 20000 не охватывает вопросы социальной ответственности. D. Способность работать с большим или меньшим числом поставщиков не определяется стандартом. В то же время следование стандарту может поз-


97

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

Вопрос 4 К процессам ISO/IEC 20000 можно применить методологию PDCA . Что подразумевает фаза A (Act)? A. Определение целей и процессов, необходимых для обеспечения соответствия требованиям заказчиков и политикам организации B. Внедрение процессов C. Мониторинг и измерение процессов и услуг и отчетность о результатах D. Выполнение действий, направленных на постоянное улучшение производительности процессов

Комментарии А. Ответ соответствует фазе Plan В. Ответ соответствует фазе Do С. Ответ соответствует фазе Check D. Ответ соответствует фазе Act. Верный ответ.

Вопрос 5 Подход к разработке и внедрений системы менеджмента качества состоит из нескольких шагов. Что из перечисленного не является необходимым шагом? A. Согласование политик и целей в области качества с Менеджером изменений B. Определение и предоставление ресурсов, необходимых для достижения целей в области качества C. определение потребностей и ожиданий заказчиков и других заинтересованных сторон D. Определение методов измерения результативности и рациональности каждого процесса

Комментарии В, С, D являются обязательными шагами при разработке и внедрении системы управления (см. Требования к системе управления); значит, верный ответ А.


98

Вопрос 6 Какова основная цель анализа записей об изменениях? A. Иметь возможность зарегистрировать проблему, что поможет проактивно обнаруживать инциденты B. Проверить, корректно ли закрыты связанные с изменениями инциденты C. Обнаруживать тенденции, связанные с числом изменений D. Обеспечить информацию для процесса формирования и предоставления отчетности

Комментарии Вариант A описывает маловероятную последовательность событий, которая точно не является основной целью анализа записей об изменениях. Для решения задачи, описанной в ответе B, лучше подойдет анализ записей об инцидентах. Верный ответ С. Основная цель регулярного анализа изменений – обнаружение роста количества изменений повторяющихся типов и намечающихся тенденций. См. Требования к процессу управления изменениями. Для выполнения D может использоваться анализ изменений, но это не является его основной целью.

Вопрос 7 Персонал должен обладать компетенцией на основе соответствующего обучения и опыта. Что из перечисленного отражает передовой опыт в области компетентности? A. Должны поддерживаться соответствующие записи об обучении, образовании, навыках и опыте B. Как минимум два сотрудника должны быть обучены выполнению каждой из определенных ролей C. Сотрудники должны иметь профильное образование на уровне не ниже бакалавра D. Все сотрудники должны пройти тренинг по стандарту ISO/IEC 27002

Комментарии А. Верный ответ. См. рекомендации в области компетенции, осведомленности и подготовки персонала. В. относится скорее к управлению доступностью и мощностями, чем к управлению компетентностью.


99

С. Для каждой роли должен быть проведен соответствующий тренинг, какая-либо степень в предметной области не оговаривается стандартом. D. Знание сотрудниками стандарта по информационной безопасности важно, но не обеспечивает всех необходимых аспектов компетенции.

Вопрос 8 Какой из стандартов описывает основные аспекты систем менеджмента качества? A. ISO 9000 B. ISO/IEC 15504 C. ISO/IEC 20000 D. ISO/IEC 27001?

Комментарии А. Верный ответ. Основной стандарт в области управления качеством. В. Стандарт, регламентирующий подход к оценке зрелости процессов. С. Стандарт в области управления ИТ-услугами. D. Стандарт в области информационной безопасности.

Вопрос 9 Что является целью процесса управления непрерывностью и доступностью услуг? A. Обеспечивать эффективные коммуникации с заказчиками на согласованном уровне B. Обеспечивать предоставление заказчикам согласованного уровня услуг в любых обстоятельствах C. Обеспечивать предоставление заказчикам согласованного уровня доступности и выполнение обязательств по непрерывности в любых обстоятельствах D. Обеспечивать предоставление поставщикам согласованного уровня доступности и выполнение обязательств по непрерывности в любых обстоятельствах

Комментарии А. Цель процесса управления взаимоотношениями ИТ и Бизнеса.


100

Различие ответов В и С в том, что в В идет речь об обеспечении всех согласованных характеристиках услуг, а в С – акцентировано доступности и непрерывности, следовательно, верный ответ С. D. Процесс управления доступностью и непрерывностью услуг ориентирован на бизнес-потребности и заказчиков услуг, а не на поставщиков.

Вопрос 10 В рамках процесса управления релизами выполняются развертывание, распространение и инсталляция. Что должно быть частью этих видов деятельности? A. График изменений должен учитывать приоритет и риски B. Должны быть доступны планы отката и обеспечения непрерывности C. Устаревшие продукты, услуги и лицензии должны быть выведены из эксплуатации D. Релизы должны быть протестированы на соответствие ожиданиям заказчика

Комментарии А. За график изменений отвечает процесс управления изменениями. В. Это обеспечивается на этапе планирования, проектирования и подготовки релиза к развертыванию (design. build and configure). С. Верный ответ. См. рекомендации и практики в области управления релизами. D. Тестирование выполняется на этапе верификации и приемки (verification and acceptance).

Вопрос 11 Руководство (топ-менеджмент) должно предоставить свидетельства поддержки разработки, внедрения и развития Сервис-менеджмента в организации с учетом особенностей организации и требований заказчиков. Что является наилучшим способом демонстрации такой поддержки? A. Отдать управление изменениями в аутсорсинг B. Подвергать дисциплинарному воздействию отстающих сотрудников C. Принимать участие в планировании новых ИТ-услуг D. Через лидерство и действия


101

Комментарии Ответ A не имеет отношения к заданному вопросу. B не является эффективным способом демонстрации поддержки и может вообще не иметь отношения к сервис-менеджменту. C может относиться к планированию и внедрению новых услуг, а не к руководству. Верный ответ D. См. Требования к руководству.

Вопрос 12 Что из перечисленного содержит рекомендации в области руководства ИТ? A. COBIT B. ISO 9000 C. ISO/IEC 20000 D. MOF

Комментарии А. Верный ответ. COBIT – сборник рекомендаций в области IT Governance (Руководства ИТ). В. Стандарт в области управления качеством. С. Стандарт в области управления ИТ-услугами. Д. Модель ITSM от компании Microsoft.

Вопрос 13 Какова цель управления ИТ-услугами? A. Предоставлять критичные услуги бизнес-заказчикам B. Предоставлять гарантии соответствия уровня услуг требованиям бизнеса C. Обеспечивать управление услугами для того, чтобы соответствовать требованиям бизнеса D. Предоставлять бизнесу услуги высшего уровня

Комментарии А. В охват управления ИТ-услугами входят все услуги, а не только критичные.


102

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

Вопрос 14 Какому процессу управление проблемами должно обеспечить доступность актуальной информации об известных ошибках и устраненных проблемах? A. Всем процессам ISO/IEC 20000 B. Управлению доступностью C. Управлению конфигурациями D. Управлению инцидентами

Комментарии Верный ответ D. Доступность актуальной информации об известных ошибках и устраненных проблемах наиболее критична для работы процесса управления инцидентами.

Вопрос 15 Какое событие или действие может инициировать такое изменение услуги, которое потребуется внести в план управления услугами? A. Значительный инцидент B. Действия по улучшению услуг C. Управление жизненным циклом систем D. Срочное изменение

Комментарии А, С, D чаще всего не требуют действий на уровне планирования всего управления услугами и решаются в рамках действующих процедур процесса управления изменениями. Область улучшения услуг рассматривается как неотъемлемая часть плана управления услугами (см. Рекомендации и практики в области планирования управления услугами). Следовательно, верный ответ В.

Вопрос 16 Почему важно, чтобы на стадии Check цикла PDCA регулярно выполнялась оценка?


103

A. Чтобы можно было распределять роли и ответственность B. Чтобы можно было определять требования и цели для управления услугами C. Чтобы можно было устанавливать политики, цели и планы D. чтобы можно было определить, насколько эффективно выполняются требования по управлению услугами

Комментарии Очевидно, что верный ответ D. А, В, С относятся к стадии Plan.

Вопрос 17 На чем в первую очередь основан сертификационный аудит? A. На записях о персонале B. На описаниях процессов C. На отчетах сертифицированных финансовых аудиторов D. На спецификациях

Комментарии Варианты A, C и D могут предоставлять полезную дополнительную информацию при проведении аудита, но основой для него является процессная документация, то есть в первую очередь – описания процессов. Верный ответ B.

Вопрос 18 Каков корректный способ внесения изменения в контракт по результатам его оценки и пересмотра? A. Через процесс управления отношениями с бизнесом B. Через процесс управления изменениями C. Через представителя Заказчика D. Через процесс управления поставщиками

Комментарии Верный ответ B. В соответствии с требованиями стандарта все контракты должны пересматриваться с использованием стандартных процедур процесса управления изменениями.


104

Кроме этого в каждом из ответов А, С, D говорится только об одной из областей (либо взаимоотношения с бизнесом, либо с поставщиками). В вопросе же нет указания на какую-либо из областей.

Вопрос 19 Требования к решению должны быть основаны на приоритете. Какая информация не влияет на определение сроков решения инцидента или проблемы? A. Навыки специалистов B. Параллельные задачи, требующие тех же ресурсов C. Затраты и усилия, необходимые для применения решения D. Число ранее зарегистрированных инцидентов с той же КЕ

Комментарии Варианты A, B и C описывают факторы, наряду с приоритетом влияющие на назначение срока решения инцидента или проблемы. Верный ответ D. Информация о ранее зарегистрированных инцидентах не влияет на назначение срока решения. Она может использоваться, например, для инициации работ по управлению проблемами.

Вопрос 20 Какова ответственность поставщика (провайдера) услуг в соответствии с требованиями стандарта ISO/IEC 20000 в части управления поставщиками? A. Обеспечить наличие процедур выбора поставщиков B. Обеспечить соответствие соглашений (SLA) с поставщиками соглашениям (SLA) с бизнесом C. Обеспечить исполнение субподрядчиками контрактных обязательств в любых обстоятельствах D. Обеспечить ясность процессов и процедур, отданных в аутсорсинг поставщикам

Комментарии A . Эта деятельность не входит в рамки стандарта. В. Верный ответ. См. Требования к управлению поставщиками. C. Контроль работы субподрядчиков – это область ответственности поставщиков (suppliers).


105

D. Поставщик услуг должен сохранять контроль над работой поставщиков (suppliers), но подробности используемых ими процедур – вне области его ответственности.

Вопрос 21 Что должно быть включено в baseline перед внедрением улучшений в услуге? A. Незавершенные изменения услуги B. Число участников внедрения C. Качество и уровни услуги D. Время, потраченное на управление процессом

Комментарии Из глоссария стандарта: базовое состояние (baseline) – зафиксированное состояние услуги в определенный момент времени. Соответственно перед внедрением улучшений в услуге необходимо сохранить информацию о текущем качестве услуги и предоставляемых уровнях. В случае признания изменений в услуге неуспешными, сохраненная информация определит точку восстановления услуги. Верный ответ С. Прочие варианты могут быть включены в базовое состояние в специфических случаях, когда именно эти параметры являются предметом улучшений.

Вопрос 22 Что такое SixSigma®? A. Инструмент управления качеством, позволяющий измерить дефекты в результатах работы процессов B. Шестиуровневая модель зрелости, помогающая улучшить возможности бизнес процессов C. Недавно разработанный стандарт для улучшения ИТ-процессов D. Структурированный подход к улучшению процессов, основанный на данных статистики

Комментарии Верный ответ D. См. подходы и стандарты.

Вопрос 23 Как следует использовать цикл Деминга?


106

A. как модель постоянного улучшения B. как модель ориентации на заказчика C. как модель проектирования услуг D. как модель расчета стоимости улучшений услуг

Комментарии Верный ответ А. Цикл P-D-C-A, цикл Деминга является моделью постоянного улучшения. См. Качество.

Вопрос 24 Что такое доступность? A. Записи, содержащие информацию о влиянии авторизованных изменений на КЕ B. Сохраненное состояние КЕ или услуги в определенный момент времени C. Любое событие, не являющееся нормальной частью работы услуги, приводящее или способное привести к прерыванию услуги или снижению её качества D. Способность компонента или услуги выполнять свои функции в определенный момент времени или на протяжении определенного периода

Комментарии Из глоссария стандарта: доступность (availability) – способность компонента или услуги выполнять требуемые функции в определенный момент или в течение определенного промежутка времени. Верный ответ D. Ответы A, B и C содержат соответственно определения записей об изменениях, базового состояния и инцидента.

Вопрос 25 Что должно быть сделано после внедрения новой или измененной услуги? A. Должна быть проведена оценка результатов внедрения (Post Implementation Review), направленная на сравнение фактических результатов с плановыми B. Должен быть согласован подход к взаимодействию с проектами, направленными на модификацию услуг C. Ничего; новая или измененная услуга передается в обычную эксплуатацию и будет управляться, как и другие услуги


107

D. Должен быть согласован подход к отмене изменения или корректировке на случай отклонения от плана внедрения

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

Вопрос 26 Каковы рекомендации по внедрению срочных изменений? A. Только высшее руководство может выполнять авторизацию таких изменений B. Они должны внедряться в обход процесса управления изменениями C. Для их обработки должны быть определен специальный процесс D. Где возможно, следует придерживаться процесса управления изменениями

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

Вопрос 27 Каким организациям подходит ISO/IEC 20000?


108

A. Организациям, стремящимся подтвердить следование всем рекомендациям ITIL® B. Организациям, стремящимся продемонстрировать соответствие требованиям заказчиков C. Организациям, желающим сертифицировать свои услуги D. Поставщикам ПО, желающим определить процессы предоставления услуг

Комментарии А. Соответствие стандарту ISO/IEC 20000 не равно соответствию всем рекомендациям ITIL (см. Связь с ITIL) С. ISO/IEC 20000 предполагает сертификацию системы управления ИТ-услугами, а не отдельных услуг D. Стандарт ISO/IEC 20000 может быть полезен поставщикам ПО для определения процессов в первую очередь – предоставления услуг, однако в области применения стандарта такого пункта нет. А вот ответ В – прямая цитата из стандарта (см. область применения стандарта), он и является верным.

Вопрос 28 Любая организация может попасть под действие законов или иных регулирующих документов. Где должны быть учтены такие ситуации? A. В запросе на изменение B. В процессе управления взаимоотношениями с бизнесом C. в SLA D. в плане управления услугами

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

• улучшение услуг


109

• • • •

изменения услуг стандартизация инфраструктуры изменения в законодательстве изменения в регулирующих актах, например, изменение размера местного налога

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

Вопрос 29 Какой уровень мощности обеспечивается процессом управления мощностями? A. Достаточный для того, чтобы удовлетворять согласованный текущий и будущий спрос B. Достаточный для того, чтобы удовлетворять весь текущий и будущий спрос C. Достаточный для того, чтобы удовлетворять весь спрос со стороны разработки и эксплуатации D. Достаточный для того, чтобы удовлетворять текущий спрос

Комментарии Цель процесса управления мощностями: Гарантировать, что поставщик услуг всегда будет иметь запас мощностей, достаточный для выполнения текущих и будущих согласованных потребностей бизнес заказчика. Соответственно, верный ответ А.

Вопрос 30 Что должна определять политика в области качества? A. Формализованные цели и направления работы организации в области качества B. Юридически закрепленные обязательства, которые организация должна выполнять C. Требования ISO/IEC 20000 D. требования заказчика, определенные в SLA


110

Комментарии Очевидно, что верный ответ А. B. Политика содержит цели и направления, поддерживающие выполнение обязательств, но не сами обязательства. C. Требования стандарта определяют содержание системы управления, но не политики. D. Требования заказчика могут влиять на политику, но не входят в нее.

Вопрос 31 Какой аудит выполняется организацией самостоятельно и может служить основанием для заявления организации о собственном соответствии требованиям? A. Аудит первой стороны B. Аудит второй стороны C. Аудит третьей стороны D. Аудит четвертой стороны

Комментарии Верный ответ А. См. Назначение внешнего и внутреннего аудита. Внутренний аудит:

• аудит первой стороны, проводится для внутренних целей самой организацией Внешние аудиты:

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

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

Вопрос 32 Какие положения в отношении инструментария должны быть включены в план при планировании внедрения управления услугами? A. Общие характеристики инструментария, отвечающего требованиям процессов B. Подробное описание влияния новых технологий на производительность C. Инструментарий не описывается в плане


111

D. Перечисление инструментов автоматизации для каждого процесса

Комментарии A. Верный ответ. Если процессы поддержаны инструментами, эти инструменты должны быть определены в плане. B. Это область ответственности процесса управления мощностями. C. Если процессы поддержаны инструментами, эти инструменты должны быть определены в плане. D. Автоматизация каждого процесса не является обязательной.

Вопрос 33 Почему важно определить охват для ISO/IEC 20000? A. Это помогает определить, на соответствие чему сертифицируется система управления B. Это предоставляет список всех сертифицированных компаний C. Это предоставляет список всех сертифицированных услуг D. Это определяет, какие процессы не вошли в границы системы

Комментарии A. Верный ответ. Определение границ (Scope statement) указывает, какие критерии использовались при сертификации. B. Только одно юридическое лицо (одна компания) может входить в охват сертификации. C. Сертификация ISO/IEC 20000 относится к системе управления, а не к услугам. D. Все процессы стандарта без исключений должны быть включены в охват аудита и сертификации.

Вопрос 34 Где обычно определяется ИТ-услуга, предоставляемая заказчику? A. В методологии ИТ B. В OLA C. В каталоге услуг или SLA D. В сервисной отчетности

Комментарии Очевидно, что верный ответ С.


112

A. Методология может определять подход к идентификации и описанию услуг, но не содержит определений самих услуг. B. OLA описывают поддерживающие услуги, не предоставляемые непосредственно заказчикам. D. Отчетность содержит информацию о качестве услуг за период, но не определяет услуги.

Вопрос 35 Что должно быть включено в процедуры управления релизами согласно ISO/IEC 20000? A. Авторизация и внедрение срочных изменений B. Расследование и предотвращение инцидентов безопасности C. Регистрация всех инцидентов D. Обновление и модификация записей об изменениях и конфигурациях

Комментарии А. входит в управления изменениями. В. входит в работу процессов управления инцидентами, управления проблемами и управления информационной безопасностью. С. Часть деятельности процесса управления инцидентами. D. Верный ответ.

Вопрос 36 Что должно быть включено в процедуры планирования новых и изменяемых услуг? A. Бюджет и требуемые ресурсы персонала B. Существенные отклонения от действующих поддерживающих контрактов (UC) C. Недавние проблемы и известные ошибки, связанные с рабочими местами D. тенденции изменения нагрузки на действующие приложения

Комментарии В рекомендациях по планированию новых/изменяемых услуг сказано: При планировании новых или измененных услуг следует провести оценку:

• бюджетов


113

• ресурсов персонала • существующих уровней услуг • соглашений об уровне услуг и других целей или обязательств по предоставлению услуг

• существующих процессов, процедур и документации по управлению услугами

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

Вопрос 37 Что в соответствии с ISO/IEC 20000 должно быть включено в предложения о внедрении новых услуг или изменении действующих? A. Обновленные OLA B. Описание затрат, а также организационного, технического и коммерческого влияния C. Политики, планы и процедуры каждого процесса и групп процессов D. План управления услугами

Комментарии Так как речь идет о предложении по внедрению новых услуг или изменении действующих, то, очевидно, что верный ответ В.

Вопрос 38 Для чего может служить стандарт ISO/IEC 20000? A. Он определяет KPI, которые могут использоваться для оценки качества услуг B. Он определяет требования, соответствие которым проверяет сертификационный аудит C. Он помогает уточнить критерии, которые должны быть включены в соглашение о поставке D. Он предоставляет средство измерения для оценки системы TQM

Комментарии Ключевое слово стандарт, соответственно верный ответ В.

Вопрос 39 Почему для поставщика услуг важно обеспечивать ведение документов и записей?


114

A. Это часть требований (свидетельств), необходимых для соответствия ISO/IEC 20000 B. Это помогает идентифицировать и регистрировать КЕ в составе CMDB C. Это помогает эффективно осуществлять планирование, управление и контроль в отношении системы управления услугами D. Это поддерживает осведомленность сотрудников о важности их работы

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

Вопрос 40 Кого следует рекомендовать для оказания поддержки Старшему Ответственному Владельцу (Senior Responsible Owner) в его/ее работе по координации системы управления? A. Группу принятия решений B. Комитет по изменениям (CAB) C. Представителя руководства со стороны Заказчика D. менеджеров услуг

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


115

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


116

Приложение 1. Список литературы


117

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

• BS ISO/IEC 20000-1:2005 IT Service Management - Part 1: Specification ISBN: 9780580475296

• BS ISO/IEC 20000-2:2005 IT Service Management - Part 2: Code of practice ISBN: 9780580475306

• E-Book: ISO/IEC 20000 An Introduction ISBN: 9789087531942

• E-Book: IT Service Management - An Introduction based on ISO 20000 and ITIL V3 ISBN: 9789087531805

• ISO/IEC 20000 Foundation Specification Sheet - EXIN, 2008 • Foundation Level Supplementary Course Development Guidance - EXIN, 2008

• ISO/IEC 20000 Foundation Sample exam - EXIN, edition December 2007


118

Приложение 2. Основные термины и определения стандарта ISO/IEC 20000


119

Доступность (availability) Способность компонента или услуги выполнять требуемые функции в определенный момент или в течение определенного промежутка времени. Примечание: доступность обычно выражается как отношение периода, на протяжении которого услуга была доступна для использования, к согласованному времени предоставления услуги.

Базовое состояние (baseline) зафиксированное состояние услуги или отдельных конфигурационных единиц в определенный момент времени.

Запись об изменении (change record) Запись, содержащая сведения о том, на какие конфигурационные единицы, и каким образом оказывает влияние авторизованное изменение.

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

База данных управления конфигурациями (configuration management database) База данных, которая содержит все существенные сведения о каждой конфигурационной единице и сведения о важных взаимосвязях между ними.

Документ (document) Информация и соответствующий носитель. Примечание: в данном стандарте понятие «запись» отличается от понятия «документ» тем, что «запись» является свидетельством деятельности, а «документ» – свидетельством намерений. Примерами документов являются положения политик, планы, процедуры, соглашения об уровнях услуг и контракты.

Инцидент (incident) Любое событие, которое не является частью стандартной эксплуатации и приводит или может привести к прерыванию предоставления этой услуги или к снижению её качества.


120

Проблема (problem) Неизвестная корневая причина одного или нескольких инцидентов.

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

Релиз (release) Совокупность новых и/или изменённых конфигурационных единиц, которые проходят совместное тестирование и внедрение в продуктивную среду.

Запрос на изменение (request for change) Документ на бумажном носителе или в электронном виде, содержащий сведения о запросе на изменение любого конфигурационного элемента, связанного с услугой или инфраструктурой.

Служба поддержки пользователей, Служба Service Desk (service desk) Группа сотрудников поставщика услуг, представляющая собой точку контакта для заказчиков и потребителей услуг и выполняющая значительный объем работ по поддержке предоставляемых услуг.

Соглашение об уровне услуг (service level agreement, SLA) Письменное соглашение между поставщиком и заказчиком, в котором определены услуги, предоставляемые заказчику, и согласованы уровни услуг.

Управление услугами (service management) Организация деятельности по управлению услугами в соответствии с требованиями бизнеса.

Поставщик услуг (service provider) Организация, поставившая перед собой цель соответствовать требованиям стандарта ISO/ IEC 20000.


121

Приложение 3. Информация о ключевых компаниях


122

EXIN EXIN, что значит Examination Institute for Information Science, это независимая некоммерческая организация, разрабатывающая и принимающая сертификационные экзамены в сфере информационных технологий. Независимая проверка и сертификация способствуют повышению качества подготовки менеджеров, специалистов и пользователей, работающих с ИТ. Экзамены EXIN каждый день принимаются в более чем 125 странах мира на 15 языках. С начала 1990-х EXIN сертифицировал более 1 миллиона человек. Управление ИТ-услугами занимает особое место в портфеле сертификации, предлагаемом EXIN. EXIN – крупнейший провайдер сертификации ITIL в мире. Помимо сертификации специалистов, EXIN также аккредитует учебные центры, работающие в области управления ИТ, и курсы, готовящие специалистов к сертификации. Дополнительная информация – www.exin-exams.com

Cleverics Компания Cleverics специализируется на предоставлении консультационных услуг и проведении курсов и тренингов в сфере управления ИТ, в первую очередь – на основе подхода ITSM. Статусы Accredited Training Provider и Accredited Courseware Provider дают компании право проводить курсы, направленные на подготовку слушателей к соответствующим экзаменам, а также предоставлять разработанные курсы для использования другими учебными центрами. Статус Accredited Examination Center позволяет принимать любые экзамены EXIN. Дополнительная информация – www.cleverics.ru


123

Методическое руководство для подготовки к экзаменам по ISO 20000

Методическое руководство для подготовки к профессиональным экзаменам ISO 20000 Foundation и ISO 20000 Foundation Bridge

ISO IEC 20000 Certification and Implementation Guide - Standard Introduction, Tips for Successful ISO IEC 20000 Certification, FAQs, Mapping Responsibilities, Terms, Definitions and ISO 20000 Acronyms

20000 für Francasal

20000 für Francasal

ISO IEC 20000 Foundation Complete Certification Kit - Study Guide Book and Online Course

20000 de leghe sub mari

ISO 9000 ISO 9001 100 Success Secrets; The Missing ISO 9000, ISO 9001, ISO 9001 2000, ISO 9000 2000 Checklist, Certification, Quality, Audit and Training Guide

20000 leguas de viaje submarino

Международный стандарт ISO

Iso-Stasis Experiment

ISO 20022 For Dummies

ISO-C 3D

BS ISO 30301:2011

ISO-C 3D

20000 λεύγες κάτω από τη θάλασσα

Русско-пушту-дари словарь: Около 20000 слов

Verne, Jules - 20000 Miles Under the Sea

Iso 9000 Quality Systems Handbook

ISO 9000 Quality Systems Handbook

ISO 14001 Environmental Systems Handbook

ISO - IEC 27001 v 2005

Iso C++ Professional Programmer's Handbook

ISO 9000 Quality Systems Handbook,

ISO Reference and Style Guide

ISO 14001 Environmental Systems Handbook

ISO,IEC1539-1.Fortran-2000 draft standard

Anforderungen an Netzwerke, ISO-OSI-Modell

ISO,IEC 10279-1991 standard.Full Basic

ISO 14001 Environmental Certification Step-by-Step

A Compact Review of ISO Major Achievements

Методическое руководство для подготовки к экзаменам по ISO 20000

Методическое руководство для подготовки к профессиональным экзаменам ISO 20000 Foundation и ISO 20000 Foundation Bridge

ISO IEC 20000 Certification and Implementation Guide - Standard Introduction, Tips for Successful ISO IEC 20000 Certification, FAQs, Mapping Responsibilities, Terms, Definitions and ISO 20000 Acronyms

20000 für Francasal

20000 für Francasal

ISO IEC 20000 Foundation Complete Certification Kit - Study Guide Book and Online Course

20000 de leghe sub mari

ISO 9000 ISO 9001 100 Success Secrets; The Missing ISO 9000, ISO 9001, ISO 9001 2000, ISO 9000 2000 Checklist, Certification, Quality, Audit and Training Guide

20000 leguas de viaje submarino

Международный стандарт ISO

Iso-Stasis Experiment

ISO 20022 For Dummies

ISO-C 3D

BS ISO 30301:2011

ISO-C 3D

20000 λεύγες κάτω από τη θάλασσα

Русско-пушту-дари словарь: Около 20000 слов

Verne, Jules - 20000 Miles Under the Sea

Iso 9000 Quality Systems Handbook

ISO 9000 Quality Systems Handbook

ISO 14001 Environmental Systems Handbook

ISO - IEC 27001 v 2005

Iso C++ Professional Programmer's Handbook

ISO 9000 Quality Systems Handbook,

ISO Reference and Style Guide

ISO 14001 Environmental Systems Handbook

ISO,IEC1539-1.Fortran-2000 draft standard

Anforderungen an Netzwerke, ISO-OSI-Modell

ISO,IEC 10279-1991 standard.Full Basic

ISO 14001 Environmental Certification Step-by-Step

A Compact Review of ISO Major Achievements

Recommend Documents