Информационная технология

МЕНЕДЖМЕНТ УСЛУГ

Часть 2

КОДЕКС ПРАКТИЧЕСКОЙ ДЕЯТЕЛЬНОСТИ

ISO/IEC 20000-2:2005
Information technology - Service management - Part 2: Code of practice
(IDT)

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1. ПОДГОТОВЛЕН Закрытым акционерным обществом «Ай-Теко» (ЗАО «Ай-Теко») с участием Федерального государственного унитарного предприятия «Научно-исследовательский институт «Восход» (ФГУП НИИ «Восход») на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2. ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 12 ноября 2010 г. № 381-ст

4. Настоящий стандарт идентичен международному стандарту ИСО/МЭК 20000-2:2005 «Информационная технология. Менеджмент услуг. Часть 2. Кодекс практической деятельности» (ISO/IEC 20000-2:2005 «Information technology - Service management - Part 2: Code of practice)

5. ВВЕДЕН ВПЕРВЫЕ

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

СОДЕРЖАНИЕ

Введение

Настоящая часть ГОСТ Р ИСО/МЭК 20000, содержащая свод положений, вытекающих из достижений практики, представлена в виде руководства и рекомендаций. На нее не следует делать ссылок как на документ, включающий спецификацию требований. Особое внимание следует уделять гарантии того, что заявления о согласии с настоящей частью стандарта не ведут к неправильному толкованию.

Настоящую часть ГОСТ Р ИСО/МЭК 20000 следует использовать совместно с его первой частью - ГОСТ Р ИСО/МЭК 20000-1 «Спецификация», связанной с данным кодексом практической деятельности.

Предполагается, что выполнение условий настоящей части стандарта ГОСТ Р ИСО/МЭК 20000 поручено сотрудникам, имеющим соответствующую квалификацию и компетенцию. Стандарт не предусматривает включение всех необходимых условий контракта. Пользователи настоящего стандарта несут ответственность за его правильное применение.

Соответствие настоящему национальному стандарту не освобождает от правовой ответственности.

В Части 2 стандарта ГОСТ Р ИСО/МЭК 20000 излагаются лучшие достижения практики для процессов менеджмента услуг, принадлежащих области применения ГОСТ Р ИСО/МЭК 20000-1.

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

Часть 1 стандарта ГОСТ Р ИСО/МЭК 20000 является спецификацией для менеджмента услуг и ее следует читать совместно с настоящей частью.

Обе части ГОСТ Р ИСО/МЭК 20000 дают возможность провайдерам услуг понять, каким образом можно повысить качество предоставления своих услуг заказчикам, как внешним, так и внутренним.

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

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

Серия стандартов ГОСТ Р ИСО/МЭК 20000 проводит различие между лучшими практическими реализациями процессов, которые не зависят от форм и размеров организаций, от их наименований и структуры. ГОСТ Р ИСО/МЭК 20000 применим как для очень больших, так и для малых провайдеров услуг, а требования к процессам менеджмента услуг, основанные на самых лучших практических достижениях, не изменяются в зависимости от формы организации, обусловливающей структуру ее руководства, в рамках которого реализуются эти процессы

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Дата введения - 2011-07-01

1. Область применения

Часть 2 ГОСТ Р ИСО/МЭК 20000 представляет собой промышленное соглашение по стандартам качества для процессов менеджмента услуг ИТ. Процессы менеджмента таких услуг нацелены на предоставление наилучших из возможных услуг для удовлетворения деловых потребностей заказчиков при согласованных уровнях ресурсов, то есть услуги предоставляются профессионально, эффективно по стоимости, с осознанными и управляемыми рисками.

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

Как стандарт, основанный на процессном подходе, ГОСТ Р ИСО/МЭК 20000 не предназначен для оценки продуктов. Однако организации, которые занимаются разработкой инструментария, продуктов и систем, могут использовать обе части стандарта в качестве помощи при разработке инструментария, продуктов и систем, поддерживающих лучшие практики менеджмента услуг.

Часть 2 ГОСТ Р ИСО/МЭК 20000 предоставляет руководство аудиторам и помощь провайдерам услуг, планирующим улучшение услуг или проведение аудита на соответствие требованиям ГОСТ Р ИСО/МЭК 20000-1.

ГОСТ Р ИСО/МЭК 20000-1 определяет ряд взаимосвязанных процессов менеджмента услуг, показанных на рисунке 1.

Рисунок 1 - Процессы менеджмента услуг

2. Термины и определения

В настоящей части ГОСТ Р ИСО/МЭК 20000 применяются термины и определения, изложенные в ГОСТ Р ИСО/МЭК 20000-1.

3. Система руководства

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

3.1. Ответственность руководства

Роль руководства в вопросах обеспечения гарантии того, что процессы, основанные на лучших практических достижениях, приняты и поддержаны, является фундаментальной для любого провайдера услуг, ориентированного на выполнение требований ГОСТ Р ИСО/МЭК 20000-1.

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

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

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

3.2. Требования к документации

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

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

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

a) политики и планы;

b) документация об услугах;

c) процедуры;

d) процессы;

e) записи об управлении процессами.

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

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

3.3. Компетентность, осведомленность и подготовка персонала

3.3.1. Общие положения

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

Провайдеру услуг следует:

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

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

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

d) обеспечивать необходимую подготовку или предпринимать другие действия для удовлетворения этих потребностей;

e) оценивать результативность предпринятых действий.

3.3.2. Профессиональный рост

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

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

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

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

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

3.3.3. Подходы, подлежащие рассмотрению

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

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

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

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

b) темпы изменения требований к навыкам и компетентности персонала;

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

d) доступность персонала соответствующей квалификации;

e) темпы обновления кадров;

f) планы подготовки кадров.

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

4. Планирование и реализация менеджмента услуг

4.1. Планируйте менеджмент услуг (Планируй)

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

4.1.1. Область применения менеджмента услуг

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

Например, область применения может быть определена:

a) организацией;

b) местоположением;

c) услугой.

Руководству следует определять область применения менеджмента услуг как часть своей ответственности (и как часть плана менеджмента услуг). Содержательную часть этой области следует проверять на соответствие требованиям ГОСТ Р ИСО/МЭК 20000-1.

Примечание - Планирование операционных изменений описано в подразделе 9.2.

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

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

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

В плане менеджмента услуг необходимо указать:

a) реализацию менеджмента услуг (или части менеджмента услуг);

b) формальную передачу процессов менеджмента услуг;

c) изменения в процессах менеджмента услуг;

d) улучшения процессов менеджмента услуг;

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

4.1.3. События, подлежащие рассмотрению

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

a) улучшение услуг;

b) изменения услуг;

c) стандартизация инфраструктуры;

d) изменения в законодательстве;

e) изменения в регулирующих актах, например, изменение размера местного налога;

f) разрегулирование или регулирование в промышленной сфере;

g) слияние и поглощение.

4.1.4. Область применения и содержание плана

В плане менеджмента услуг следует определять:

a) область применения менеджмента услуг, предоставляемых провайдером услуг;

b) цели и требования, которые достигаются менеджментом услуг;

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

d) состав ролей и обязанностей руководства, включая старшего ответственного владельца, владельцев процессов и руководство поставщиков;

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

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

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

h) подход к изменению плана и услуг, определенных планом;

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

j) процессы, которые будут выполняться;

k) инструментарий, применяемый для поддержки реализации процессов.

4.2. Реализация менеджмента услуг и предоставление услуги (Выполняй)

Цель: Осуществить цели менеджмента услуг и выполнить план.

Процессы менеджмента услуг, основанные на лучших достижениях практики, не смогут соответствовать требованиям ГОСТ Р ИСО/МЭК 20000, если сами услуги не соответствуют требованиям, установленным в ГОСТ Р ИСО/МЭК 20000-1.

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

Следует проводить ревизии услуг и процессов их менеджмента в соответствии с положениями подраздела 4.3.

Примечание - Лица, привлеченные к процессу разработки и начальному этапу реализации планов, не могут заниматься их текущим исполнением.

4.3. Мониторинг, измерения и ревизии (Контролируй)

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

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

a) фактически достигнутые результаты по сравнению с определенными заданиями по услугам;

b) удовлетворенность заказчиков;

c) использование ресурсов;

d) тенденции;

e) значительные несоответствия.

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

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

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

4.4. Проводите непрерывное совершенствование (Действуй)

Цель: Повышать результативность и эффективность менеджмента и предоставления услуг.

4.4.1. Политика

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

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

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

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

4.4.2. Планирование совершенствования услуг

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

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

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

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

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

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

5. Планирование и реализация новых или измененных услуг

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

5.1. Вопросы для рассмотрения

При планировании новых или измененных услуг следует учитывать необходимость пересмотра:

a) бюджетов;

b) обеспеченности персоналом;

c) существующих уровней услуг;

d) соглашений об уровнях услуг и других заданий или обязательств по услугам;

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

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

5.2. Записи об изменениях

Все изменения в услугах следует отражать в записях менеджмента изменений.

Они включают планы по:

a) найму (переподготовке) персонала;

b) изменению месторасположения;

c) подготовке пользователей;

d) обеспечению обмена информацией об изменениях;

e) изменению параметров поддерживаемых технологий;

f) официальному прекращению предоставления услуг.

6. Процессы предоставления услуг

6.1. Менеджмент уровня услуг

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

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

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

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

Примечание - Каталог услуг может содержать общую информацию, такую как:

a) наименование услуги;

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

c) контактная информация;

d) интервалы времени предоставления и перерывы в предоставлении услуги;

e) договоренности по обеспечению безопасности.

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

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

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

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

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

Примечание 1 - Слишком большое количество заданных значений параметров услуг может вызвать путаницу и привести к чрезмерным накладным расходам.

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

a) краткое описание услуги;

b) срок действия и (или) механизм управления изменениями в соглашении об уровне услуг;

c) подробности установления полномочий;

d) краткое описание связей, включая необходимую отчетность;

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

f) часы предоставления услуги (например, с 09:00 до 17:00), дни, когда услуга недоступна (например, выходные, праздники), критические периоды для деловой деятельности и находящиеся вне времени предоставления услуги;

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

h) обязанности заказчика, например по вопросам обеспечения безопасности;

i) ответственность и обязательства провайдера услуг, например по обеспечению безопасности;

j) руководящие указания по воздействиям и приоритетам;

k) процесс привлечения дополнительных сил и средств¹ и процесс оповещения;

___________

¹ В оригинале - escalation (прим. переводчика)

l) процедура выставления претензий;

m) целевые значения параметров услуг;

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

o) подробности финансового менеджмента высокого уровня, например правила оплаты счетов;

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

q) вспомогательные процедуры;

r) глоссарий терминов;

s) поддерживающие и связанные с ними услуги;

t) любые исключения в условиях (сроках), указанных в соглашении об уровне услуг.

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

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

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

6.1.3. Процесс менеджмента уровня услуг

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

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

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

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

b) соглашение по целевым значениям параметров услуг;

c) измерения и отчетность о фактически достигнутых уровнях услуг и рабочих нагрузках, а также предоставление объяснений, если согласованные задания по параметрам услуг оказались не выполненными (см. 6.2);

d) инициацию корректирующих действий;

e) исходные данные для плана совершенствования услуг.

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

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

6.1.4. Соглашения о поддерживающих услугах

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

6.2. Отчетность об услугах

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

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

6.2.1. Политика

Требования к отчетности об услугах следует согласовать и документировать для заказчиков и внутреннего руководства.

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

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

6.2.2. Назначение и контроль качества по отчетности об услугах

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

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

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

Следует создавать несколько типов отчетов:

a) отчеты, содержащие реакцию на какие-либо уже случившиеся события;

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

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

6.2.3. Отчеты об услугах

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

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

b) информацию о несоответствиях стандартам;

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

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

e) информацию о тенденциях за определенный период времени (например, за день, неделю, месяц);

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

g) отчеты, отражающие прогнозируемую и запланированную рабочую нагрузку.

6.3. Менеджмент доступности и непрерывности услуг

Цель: Гарантировать выполнение согласованных обязательств по доступности и непрерывности услуг при любых обстоятельствах.

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

6.3.1. Общие положения

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

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

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

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

6.3.2. Мониторинг доступности и деятельность по ее обеспечению

В рамках менеджмента доступности следует:

a) осуществлять мониторинг и регистрацию доступности услуг;

b) поддерживать в актуальном состоянии ретроспективные данные;

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

d) осуществлять документирование и анализ несоответствий;

е) прогнозировать нарушения доступности;

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

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

6.3.3. Стратегия непрерывности услуг

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

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

b) максимально допустимую продолжительность снижения качества предоставляемой услуги;

c) приемлемые уровни снижения качества предоставляемой услуги во время ее восстановления.

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

Любые изменения в стратегии необходимо согласовывать официально.

6.3.4. Планирование и тестирование непрерывности услуг

Провайдеру услуг следует гарантировать, что:

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

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

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

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

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

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

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

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

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

6.4. Формирование бюджета и учет затрат на услуги ИТ

Цель: Формировать бюджет и вести учет затрат на обеспечение услуг.

6.4.1. Общие положения

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

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

6.4.2. Политика

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

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

a) типы затрат, подлежащих учету;

b) постатейное распределение накладных расходов, например единая тарифная ставка, фиксированный процент или процент, зависящий от величины переменных расходов и др.;

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

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

e) связи с менеджментом уровня услуг.

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

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

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

6.4.3. Формирование бюджета

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

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

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

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

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

6.4.4. Учет затрат

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

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

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

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

6.5. Менеджмент возможностей

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

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

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

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

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

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

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

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

6.6. Менеджмент защиты информации

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

6.6.1. Общие положения

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

Персоналу провайдера услуг и в первую очередь специалистам по защите информации следует знать основные положения ГОСТ Р ИСО/МЭК 17799 «Информационная технология. Практические правила управления информационной безопасностью».

6.6.2. Идентификация и классификация информационных активов

Провайдеру услуг следует:

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

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

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

6.6.3. Практическая деятельность по оценке рисков, связанных с защитой

Необходимо, чтобы оценка рисков, связанных с возможными нарушениями защиты:

a) проводилась на согласованных интервалах времени;

b) регистрировалась;

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

d) способствовала пониманию того, что конкретно может повлиять на управляемую услугу;

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

6.6.4. Риски, связанные с информационными активами

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

a) их природы (например, сбой программных средств, ошибки функционирования, отказ средств связи);

b) правдоподобия;

c) потенциального влияния на деловую сферу заказчика;

d) накопленного опыта.

6.6.5. Защищенность и доступность информации

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

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

b) неточности, неполноте или недостоверности (например, фальсификации) информации;

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

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

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

6.6.6. Средства управления

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

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

b) роли и ответственность в процессе менеджмента защиты информации следует определять и назначать соответствующим должностным лицам;

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

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

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

f) для оценки рисков и реализации управления следует предусмотреть возможность привлечения экспертов;

g) эффективная работа средств управления не должна ставиться под угрозу при проведении каких-либо изменений;

h) информацию об инцидентах по защите необходимо сообщать согласно процедурам менеджмента инцидентов и инициировать ответ на нее.

6.6.7. Документы и записи

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

a) о результативности политики по защите информации;

b) о выявлении тенденций в инцидентах по защите информации;

c) об исходной информации для плана совершенствования услуг;

d) об управлении через доступ к информации, активам и системам.

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

7. Процессы отношений

7.1. Общие положения

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

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

На рисунке 2 приведена упрощенная схема описанных выше отношений

Рисунок 2 - Процессы отношений

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

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

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

Процессы отношений должны гарантировать, что все стороны:

a) понимают и удовлетворяют потребности деловой сферы;

b) понимают существующие возможности и ограничения;

c) понимают свои обязательства и ответственность.

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

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

7.2. Менеджмент отношений в деловой сфере

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

7.2.1. Ревизии услуг

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

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

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

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

7.2.2. Претензии к услугам

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

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

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

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

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

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

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

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

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

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

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

7.3. Менеджмент поставщиков

Цель: Осуществлять менеджмент поставщиков для гарантии обеспечения беспрепятственности и качества услуг.

7.3.1. Введение

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

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

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

c) изменения осуществлялись управляемым способом;

d) взаимодействие по деловым вопросам со всеми сторонами регистрировалось;

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

7.3.2. Менеджмент контрактов

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

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

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

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

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

7.3.3. Определение услуг

Для каждой услуги и каждого поставщика провайдеру услуг следует поддерживать:

a) определение услуг, ролей и ответственности;

b) область применения услуги;

c) процесс менеджмента контракта, уровни утверждения контракта и план завершения контракта;

d) сроки оплаты, при необходимости;

e) согласованные параметры отчетности и записей о достигнутых эксплуатационных характеристиках.

7.3.4. Менеджмент многих поставщиков

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

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

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

7.3.5. Менеджмент разногласий в контрактах

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

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

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

7.3.6. Закрытие контракта

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

8. Процессы решений

8.1. Исходная информация

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

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

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

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

a) приоритеты;

b) доступность персонала соответствующей квалификации;

c) конкурирующие требования к использованию ресурсов;

d) усилия (затраты) на обеспечение метода решения;

e) время, затраченное на обеспечение метода решения.

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

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

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

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

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

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

8.2. Менеджмент инцидентов

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

8.2.1. Общие положения

Примечания

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

2. Процесс менеджмента инцидентов следует:

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

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

В процесс менеджмента инцидентов следует включать:

a) прием обращений, регистрацию, назначение приоритетов, классификацию;

b) решения, принимаемые на первой линии обработки инцидента, или направление на дальнейшую обработку;

c) рассмотрение вопросов защищенности (безопасности);

d) отслеживание инцидентов и менеджмент жизненного цикла;

e) проверку результатов и закрытие инцидентов;

f) взаимодействие с заказчиком на первой линии поддержки;

g) последующее наращивание усилий, направленное на закрытие инцидентов (эскалацию).

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

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

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

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

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

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

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

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

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

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

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

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

8.3. Менеджмент проблем

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

8.3.1. Область применения менеджмента проблем

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

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

8.3.2. Инициация менеджмента проблем

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

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

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

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

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

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

Известная ошибка не может быть закрыта раньше ее успешного устранения.

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

8.3.4. Решение проблем

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

8.3.5. Обмен информацией

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

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

Прогресс в решении всех проблем должен отслеживаться.

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

a) регистрацию изменений для определения ответственности этих сторон за решение проблем в течение жизненного цикла каждой из них;

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

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

d) определение точек привлечения дополнительных сил и средств;

e) регистрацию сведений об использованных ресурсах и принятых мерах.

8.3.7. Закрытие записей об инцидентах и проблемах

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

a) подробные сведения о принятии решений аккуратно зафиксированы;

b) причины распределены по категориям для облегчения последующего анализа;

c) при необходимости, и заказчик, и обеспечивающий персонал ознакомлены с принятыми решениями;

d) заказчик согласен, что принятые решения реализованы;

e) если решение не реализовано или его невозможно реализовать, то заказчик информирован об этом.

8.3.8. Ревизии проблем

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

Как правило, ревизии проблем - это:

a) ревизии уровней отдельных инцидентов и статуса проблем относительно уровней услуг;

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

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

8.3.9. Содержание ревизий

В ревизии следует включать определение:

a) тенденций, например повторений проблем и инцидентов, известных ошибок;

b) повторяющихся проблем, связанных с конкретным компонентом или месторасположением;

c) дефицита, обусловленного недостатками в обеспечении ресурсами, в подготовке или документации;

d) несоответствий, например по отношению к стандартам, политикам и законодательным актам;

e) известных ошибок в запланированных релизах;

f) ограничений в штатных ресурсах, необходимых для устранения инцидентов и решения проблем;

g) повторений ранее устраненных инцидентов или проблем.

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

Эту информацию следует добавлять в базу знаний менеджмента проблем.

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

8.3.10. Предупреждение проблем

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

a) об активах и конфигурациях;

b) о менеджменте изменений;

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

d) об аналогичных проблемах, существовавших в прошлом.

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

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

9. Процессы управления

9.1. Менеджмент конфигурации

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

9.1.1. Планирование и реализация менеджмента конфигурации

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

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

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

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

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

a) область применения, цели, политики, роли стандартов и ответственности;

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

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

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

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

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

g) менеджмент поставщиков и подрядчиков, принимающих непосредственное участие в процессе менеджмента конфигурации.

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

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

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

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

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

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

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

c) оригиналы твердых копий и электронных библиотек, например, наиболее полной библиотеки программных средств;

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

е) лицензии;

f) компоненты защиты, например, брандмауэры;

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

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

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

j) отношения и зависимости между элементами конфигурации.

Примечание - Другие объекты, которые могут рассматриваться как элементы конфигурации, включают:

a) другую документацию;

b) другие активы;

c) другие средства, например сайт;

d) подразделения деловой сферы;

e) персонал.

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

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

9.1.3. Управление конфигурацией

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

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

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

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

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

c) позволяет проводить управляемый поиск копии контролируемого оригинала, например программного средства.

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

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

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

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

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

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

Отчеты должны содержать сведения:

a) о самых последних версиях элементов конфигурации;

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

c) о взаимозависимостях элементов конфигурации;

d) о ретроспективе версий;

e) о состояниях элементов конфигурации, которые вместе составляют:

1) конфигурацию услуги или системы;

2) изменение, базовую линию, сборку или релиз;

3) версию или вариант.

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

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

a) защитить физические конфигурации и интеллектуальный капитал организации;

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

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

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

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

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

Примечание - Обычно проводят аудиты конфигураций двух видов:

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

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

9.2. Менеджмент изменений

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

9.2.1. Планирование и реализация

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

a) изменения имеют четко определенную и документированную область распространения;

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

c) изменения проводятся в соответствии с календарными планами на основе приоритетов и рисков;

d) изменения в конфигурациях могут быть верифицированы в процессе реализации изменений;

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

f) можно продемонстрировать, каким образом каждое изменение:

1) инициируется, регистрируется и классифицируется (со ссылками на исходные документы);

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

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

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

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

6) выполняется назначенным сотрудником из состава группы, ответственной за изменяемые компоненты;

7) тестируется, проверяется и завершается;

8) закрывается и пересматривается;

9) проводится через календарные планы, контролируется и отражается в отчетах;

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

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

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

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

9.2.2. Закрытие и ревизии заявок на изменение

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

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

b) заказчики удовлетворены результатами;

c) отсутствуют какие-либо непредвиденные эффекты.

Любые несоответствия следует регистрировать и принимать по ним надлежащие меры.

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

9.2.3. Экстренные изменения

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

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

9.2.4. Отчетность о менеджменте изменений, анализ и действия

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

10. Процесс релизов

10.1. Процесс менеджмента релизов

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

10.1.1. Общие положения

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

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

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

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

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

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

10.1.2. Политика релизов

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

a) частоту и типы релизов;

b) роли и ответственность менеджмента релизов;

c) уполномоченный орган для релиза в среде приемочного тестирования и в производственной среде;

d) однозначную идентификацию и описания всех релизов;

e) подход к компоновке изменений в релизе;

f) подход к автоматизации создания, инсталляции и процесса распространения релиза с целью обеспечения повторяемости и эффективности;

g) порядок проведения верификации и приемки релиза.

10.1.3. Планирование и развертывание релизов

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

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

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

Планирование релиза и его развертывания обычно включает:

a) дату создания релиза и описание его поставки;

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

c) связанные процессы для реализации релиза во всех деловых и территориальных подразделениях;

d) способ возвращения релиза в исходное состояние или его исправления в случае неудачной реализации;

e) процесс верификации и приемки;

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

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

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

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

j) порядок завершения релиза;

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

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

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

Этот процесс следует документировать в плане менеджмента конфигурации.

10.1.5. Проектирование, компоновка и конфигурирование релиза

Релиз и его распространение следует проектировать и осуществлять для:

a) приведения в соответствие с архитектурой систем провайдеров услуг, менеджментом услуг и стандартами инфраструктуры;

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

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

d) четкого определения рисков и реагирования на них при необходимости;

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

f) предоставления возможности проверки полной укомплектованности релиза, когда он достигнет места назначения.

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

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

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

10.1.6. Верификация и приемка релиза

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

В процессе верификации и приемки следует:

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

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

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

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

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

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

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

10.1.7. Документация

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

a) основную документацию, такую как соглашения об уровне услуг;

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

c) процессы компоновки, выпуска, инсталляции и распространения релиза;

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

е) календарный план подготовки менеджмента услуг, персонала поддержки и заказчика;

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

g) связанные с релизом изменения, проблемы и известные ошибки;

h) свидетельство о санкционировании релиза и соответствующие свидетельства его верификации и приемки.

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

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

Если релиз отклоняется, задерживается или отменяется, об этом факте следует информировать менеджмент изменений.

10.1.8. Развертывание, распространение и инсталляция

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

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

a) все места, выделенные для хранения программных и технических средств, должным образом защищены;

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

c) проверки, относящиеся к инсталляции, окружающей среде, электроснабжению и вспомогательному оборудованию, планируются и осуществляются;

d) персонал деловой сферы и провайдера услуг оповещается о новых релизах;

е) лишние изделия, услуги и лицензии выводятся из применения.

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

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

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

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

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

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

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

Библиография