13. Цель работы

Изучение стандарта ISO 20000: 2005.

14. Порядок выполнения работы

    1. История возникновения стандарта ISO 20000.

    2. Разделы стандарта ГОСТ P ICO/МЭК 20000 и их назначение.

    3. Процессы и ответственности IT- менеджеров.

    4. Проектирование и доработка IT- услуг.

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

    6. Управление взаимоотношениями.

    7. Управления инцидентами и процессы разрешения.

    8. Процессы контроля.

    9. В чем отличие стандарта ГОСТ P ICO/МЭК 20000 от других международных стандартов

15. Ход выполнения работы

    1. История возникновения стандарта ISO 20000.

ISO 20000 – первый международный стандарт по управлению качеством ИТ-услуг, он состоит из двух частей: «Information technology – Service management. Part 1: Specification» и «Information technology – Service management. Part 2: Code of Practice».

ISO 20000-1:2005 «Information technology – Service management. Part 1: Specification» содержит полное и подробное описание требований к системе управления ИТ-сервисами, а также ответственность за их в организациях. Первая часть состоит из 10 разделов, которые содержат 13 процессов в пяти ключевых группах:

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

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

3. Процессы разрешения (Resolution processes). Разработчики стандарта фокусируются на инцидентах, которые удалось предотвратить или успешно разрешить, – управление проблемами, управление инцидентами.

4. Процессы контроля (Control processes). В данном разделе рассматриваются процессы управления изменениями и конфигурациями.

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

ISO 20000-2:2005 «Information technology – Service management. Part 2: Code of Practice» – это практическая часть, в которой содержатся рекомендации по процессам и требованиям, описанным в первой части. Состоит из 10 разделов и предназначена для аудиторов и компаний, намеренных пройти сертификацию.

Оценка ИТ-сервисов согласно требованиям, ISO 20000-1:2005 дает возможность увидеть объем нереализованности управления, что позволяет запланировать его выполнение по рекомендациям ISO 20000-2:2005, библиотеки ITIL® или любой другой методологии. Использование данных методологий не является обязательным, но в значительной мере упрощает процесс перехода к сервисной модели и делает его более понятным.

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

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

В 2011 году стандарт ISO 20000 получил обновление – вышла новая редакция ISO/IEC 20000:2011, авторы отметили следующие изменения в этой версии:

1. более тесное «выравнивание» (alignment) со стандартом ISO 9001;

2. более тесное «выравнивание» со стандартом ISO 27001;

3. изменения в терминологии для отражения специфики интернационального применения;

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

5. объединение разделов 3 и 4 версии ISO/IEC 20000–1:2005, чтобы собрать все общие требования к системе управления ИТ-услугами в одном разделе стандарта;

6. разъяснения к требованиям надзора (governance) за процессами, которые выполняются третьими сторонами, вовлеченными в предоставление или потребление ИТ-услуг;

7. разъяснения по определению границ сертификации (области охвата сертифицируемой системы управления ИТ-услугами);

8. разъяснения по применению методологии (methodology) PDCA к системе управления ИТ-услугами и, в частности, к процессам и к ИТ-услугам;

9. появление новых требований к проектированию и внедрению (design and transition) новых и измененных ИТ-услуг.

Стандарт стал значительно больше по объему материала: из 16 страниц в версии 2005 года он вырос до 26 в версии 2011. Расширились требования к проектированию и внедрению ИТ-услуг, также расширился глоссарий, что сделало подачу информации более понятной и легкоусвояемой. Язык стандарта стал более точным в формулировках, устранены варианты вольной трактовки некоторых понятий, это облегчает общение между аудиторами, проверяющими организациями и руководством компании.

2. Разделы стандарта ГОСТ P ICO/МЭК 20000 и их назначение

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

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

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

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

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

3. Процессы и ответственности IT- менеджеров.

Согласно ISO 20000-1, основная цель системы менеджмента IT сервисов – наладить работу компании так, чтобы протекающие процессы приносили результат, который удовлетворяет пожелания покупателей услуг. Достичь этой цели можно, если учтены требования к системе менеджмента:

1. Ответственность руководителей (топ-менеджмент ИТ-корпорации должен представить доказательства того, что им ведется работа по внедрению, реализации и улучшению системы менеджмента);

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

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

Среди требований стоит отметить такой пункт в ISO/IEC 20000, как ответственность руководства. Глава предприятия и его заместители должны видеть свои краткосрочные и долгосрочные цели, политику компании, заниматься планировочной работой, выделять средства и время на совершенствование системы управления. Руководители обязаны обеспечить компанию ресурсами и уметь управлять рисками.

4. Проектирование и доработка IT- услуг.

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

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

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

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

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

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

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

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

1) Формирование и предоставление отчетности по услугам.

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

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

1. соответствие деятельности целям предоставления услуг;

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

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

4. обнаруженные несоответствия требованиям настоящего стандарта, требованиям СУУ или требованиям к услугам с определением причин;

5. информацию о тенденциях;

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

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

2) Управление непрерывностью и доступностью услуг.

2.1) Требования к непрерывности и доступности услуг.

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

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

1. права доступа к услугам;

2. время отклика услуг;

3. конечную доступность услуг.

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

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

План непрерывности должен, по крайней мере, включать:

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

2. цели доступности в случае применения плана;

3. требования к восстановлению;

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

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

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

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

2.3) Мониторинг и тестирование непрерывности и доступности услуг.

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

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

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

3) Бюджетирование и учет затрат на ИТ-услуги.

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

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

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

3. общие ресурсы,

4. накладные расходы,

5. капитальные и операционные расходы,

6. услуги, предоставляемые подрядчиком,

7. персонал,

8. инженерное обеспечение;

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

10. по эффективному финансовому контролю и деятельности по утверждению.

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

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

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

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

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

1. текущий спрос и прогноз спроса на услуги;

2. ожидаемый эффект согласованных требований к доступности, к непрерывности и уровню услуг;

3. временные рамки, пороговые значения и затраты на модернизацию мощностей;

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

5. потенциальное воздействие новых технологий и новых подходов;

6. процедуры для осуществления упреждающего анализа или ссылки на них.

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

5) Управление информационной безопасностью.

5.1) Политика информационной безопасности.

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

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

2. обеспечить наличие и формализацию целей информационной безопасности;

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

4. обеспечить проведение оценки рисков информационной безопасности с запланированной периодичностью;

5. обеспечить проведение внутреннего аудита информационной безопасности;

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

5.2) Средства контроля информационной безопасности.

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

1. сохранения конфиденциальности, целостности и доступности информационных ресурсов;

2. выполнения требований политики информационной безопасности;

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

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

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

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

5.3) Изменения и инциденты информационной безопасности.

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

1. новые или измененные риски информационной безопасности;

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

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

6. Управление взаимоотношениями.

Управление взаимоотношениями с бизнесом

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

Поставщик услуг устанавливает механизм коммуникации с заказчиком.

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

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

Управление подрядчиками

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

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

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

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

7. Управления инцидентами и процессы разрешения

1) Управление инцидентами и запросами на обслуживание.

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

1. регистрация;

2. приоритезация;

3. классификация;

4. обновление записей;

5. эскалация;

6. решение;

7. закрытие.

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

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

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

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

значительных инцидентов для выявления возможностей для совершенствования.

2) Управление проблемами.

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

1. идентификацию;

2. регистрацию;

3. приоритезацию;

4. классификацию;

5. обновление записей;

6. эскалацию;

7. решение;

8. закрытие.

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

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

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

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

8. Отличия стандарта ГОСТ P ICO/МЭК 20000 от других международных стандартов.

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

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

16. Выводы

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