Звоните: +7 (495) 517-57-25

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

3.1. Что надо знать об экзамене

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

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

Экзамен представляет собой тест, содержащий 40 вопросов и несколько вариантов ответа на каждый вопрос; верным является только один из предложенных вариантов. Для получения сертификата необходимо дать верные ответы на 26 и более вопросов (65%). Продолжительность экзамена 60 минут, экзамен сдается на английском языке.

Если у Вас уже есть сертификат ITIL Foundation, то предусмотрен сокращенный формат сертификации сдача экзамена Foundation Bridge (20 вопросов, 13 верных ответов проходной балл).

3.2. Требования к экзамену

Вопросы экзамена охватывают 4 темы:

  • Понимание определений и принципов управления ИТ-услугами (ITSM) 15% вопросов;
  • Понимание роли и назначения стандарта ISO/IEC 20000 20% вопросов;
  • Требования к системе управления услугами (в соответствии с Частью 1 ISO/IEC 20000) 35% вопросов;
  • Рекомендации и практики по управлению услугами (в соответствии с Частью 2 ISO/IEC 20000) 30% вопросов.

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

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

1. Определения и принципы управления качеством услуг (Service Quality Management)

1.1. Услуги

1.2. Качество

1.3. ITSM (управление ИТ-услугами)

1.4. Процессы

1.5. Постоянное улучшение

2. Роль и назначение стандарта ISO/IEC 20000

2.1. Стандарты и подходы обзор

2.2. Сертификация системы управления

2.3. Структура ISO/IEC 20000

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

3.1. Требования к управлению и совершенствованию процессов ITSM

3.2. Требования к процессам контроля

3.3. Требования к процессам управления взаимоотношениями ИТ и бизнеса

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

3.5. Требования к процессам поддержки услуг

4. Рекомендации и практики по управлению услугами (в соответствии с Частью 2 ISO/IEC 20000)

4.1. Рекомендации и практики для управления и совершенствования процессов ITSM

4.2. Рекомендации и практики для процессов контроля

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

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

4.5. Рекомендации и практики для процессов поддержки услуг

3.3. Ответы на вопросы

Что же надо знать для прохождения экзамена?

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

3.3.1. Услуги

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

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

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

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

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

  • Информационную систему;
  • Поддержку;
  • Требования к качеству (спецификацию).

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

ИТ-система

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

3.3.2. Качество

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

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

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

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

  • Отвечает ли услуга ожиданиям?
  • Можно ли ожидать такого же качества в будущем?
  • Соответствует ли услуга своей цене?

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

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

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

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

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

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

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

  1. Plan
  2. Do
  3. Check
  4. Act

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

PDCA

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

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

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

Стандарты серии ISO 9000 часто используются для создания, управления, оценки и совершенствования СМК. Отвечающая требованиям стандарта СМК, обеспечивает уверенность, что:

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

3.3.3. ITSM (управление ИТ-услугами)

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

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

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

Среди преимуществ ITSM с точки зрения потребителей:

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

Среди преимуществ ITSM с точки зрения поставщиков:

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

Риски и возможные ошибки при использовании подхода ITSM:

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

3.3.4. Процессы

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

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

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

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

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

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

ITOCO

Входы (inputs) связаны с ресурсами, используемыми процессом; выходы (outputs) подразумевают непосредственные немедленные результаты работы процесса; результаты (outcomes) долгосрочный эффект от деятельности процесса. Контроль (control) позволяет соотнести входы и выходы процесса с действующими политиками и стандартами. Контроль регулирует работу (throughput) и входы процесса, если работа или выходы отклоняются от плановых значений, определенных политиками и стандартами.

В организации должны быть определены требования к результатам работы процессов. Если фактические результаты соответствуют этим требованиям, считается, что процесс результативен (effective). Более точная оценка результативности возможна при использовании для нее результатов (outcomes), а не выходов (outputs). Если деятельность в рамках процесса осуществляется с минимумом усилий и затрат, то процесс рационален (efficient). Задача управления процессами обеспечить выполнение всех процессов максимально результативным и рациональным образом.

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

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

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

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

Процессы включают в себя два типа видов деятельности: виды деятельности, направленные на получение результата (throughput activities) и виды деятельности по управлению ими (control activities).

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

При проектировании процессов в дополнение к существующей иерархии определяются роли.

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

3.3.5. Постоянное улучшение

После того, как Software Engineering Institute университета Carnegie Mellon опубликовал модели зрелости для процессов разработки ПО (Software Capability Maturity Model), аналогичные модели стали широко применяться в различных областях управления. CMM стала чем-то вроде стандарта в моделировании зрелости. Аналогичная модель использовалась различными подходами к управлению качеством, в том числе в EFQM (European Foundation for Quality Management).

EFQM принят в 1998 четырнадцатью крупными европейскими компаниями при поддержке Еврокомиссии. Цель EFQM продвижение TQM (Total Quality Management) для повышения удовлетворенности потребителей, сотрудников, учета интересов общества и повышения производительности.

Широко известная модель EFQM (Model of Business Excellence) может помочь в определении зрелости организации. Она определяет основные области внимания при управлении организацией:

EFQM

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

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

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

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

Организация систем менеджмента качества в соответствии со стандартами серии ISO 9000, в частности стандартом ISO 20000, может рассматриваться как способ повышения зрелости организации до уровня 4 («измеримый»).

3.3.6. Про другие стандарты и подходы

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

CMMI — развитие методологии CMM (см. Постоянное улучшение), которая разрабатывалась со второй половины 1980-х годов Software Engineering Institute (SEI) в университете Карнеги-Меллона (Carnegie Mellon University).

COBIT — подход, разработанный IT Governance Institute и ISACA как руководство в области IT Governance (Руководства ИТ). Руководство, в отличие от управления (management), направлено на формирование границ и правил для системы управления и обеспечение на стратегическом уровне уверенности в эффективности этой системы.

SixSigma — структурированный подход к улучшению процессов, основанный на статистических данных

ISO 15504, или SPICE (Software Process Improvement and Capability Determination) — стандарт, регламентирующий подход к оценке зрелости процессов. Основан на нескольких моделях зрелости, включая CMM, и стандарте ISO 12207, регламентирующем жизненный цикл программного обеспечения.

ISO/IEC 27001, ISO/IEC27002 — стандарты в области ИБ, пришедшие на смену ISO 17799. Содержат требования в области информационной безопасности для создания, развития и поддержания Системы менеджмента информационной безопасности.

Корпоративные и отраслевые подходы и стандарты, такие как eTOM (enhanced Telecom Operations Map), содержат требования и/или рекомендации по созданию систем управления с учетом особенностей предприятия и/или отрасли. Так, eTOM является стандартом de facto для организации управления в телекоммуникационной отрасли. В частности, содержит раздел, посвященный организации управления услугами.

3.3.7. Требования к системе управления ИТ-услугами (в соответствии с Частью 1 стандарта ISO/IEC 20000)

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

3.3.8. Требования к управлению и совершенствованию процессов ITSM

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

Цель системы управления:

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

Требования к руководству:

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

Руководство должно:

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

Требования к документированию

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

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

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

Требования к компетенции, осведомленности и подготовке персонала

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

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

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

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

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

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

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

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

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

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

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

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

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

Применение методологии P-D-С-A для управления ИТ-услугами

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

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

ISO 20000 PDCA

3.3.9. Требования к процессам контроля

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

Цель планирования и внедрения новых / изменяемых услуг

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

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

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

Планы должны включать:

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

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

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

Требования:

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

Процесс управления изменениями: цели и требования

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

Требования:

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

Процесс управления релизами: цели и требования

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

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

Требования:

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

3.3.10. Требования к процессам управления взаимоотношениями ИТ и бизнеса

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

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

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

Требования:

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

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

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

Требования:

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

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

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

Требования:

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

Процесс управления взаимоотношениями с бизнесом: цель и требования

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

Требования:

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

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

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

Управление поставщиками в ISO 20000

Примечания:

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

Требования:

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

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

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

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

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

Требования:

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

Процесс управления мощностями: цель и требования

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

Требования:

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

Процесс управления информационной безопасностью: цель и требования

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

Требования:

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

3.3.12. Требования к процессам поддержки услуг

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

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

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

Требования:

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

Процесс управления проблемами: цель и требования

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

Требования:

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

3.3.13. Рекомендации и практики по управлению услугами (в соответствии Частью 2 ISO/IEC 20000)

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

3.3.14. Рекомендации и практики для управления и совершенствования процессов ITSM

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

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

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

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

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

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

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

Поставщику услуг следует:

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

Профессиональное развитие

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

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

Возможные подходы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Назначение внутреннего и внешнего аудита

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

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

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

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

3.3.16. Рекомендации и практики для процессов контроля

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

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

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

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

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

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

В записях процесса управления изменениями стоит отразить планы по:

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

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

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

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

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

Примечание: существует два типа аудита конфигураций:

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

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

Планирование и реализация изменений

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

  • область и границы каждого изменения четко определены и задокументированы
  • утверждаются только те изменения, которые приносят ценность заказчику (например, коммерческую, правовую, регулирующую, контролирующую и др.)
  • проводится календарное планирование реализации изменений с учётом их приоритетов и рисков
  • изменения в конфигурациях могут быть отслежены на протяжении всего времени осуществления этих изменений
  • сроки реализации изменений контролируются и уточняются (при необходимости)
  • есть возможность продемонстрировать, каким образом изменение:
    • инициировано, зарегистрировано и классифицировано (со ссылкой на соответствующий документ)
    • оценено на предмет его влияния на заказчиков услуг, а так же оценены его срочность, преимущества, затраты на реализацию, риски для предоставления услуг, для самих услуг, для планов заказчика и для релизов, связанные с осуществлением этого изменения
    • отменено, с возвратом в исходное состояние, или исправлено в случае неудачи при его реализации
    • документировано, например, зарегистрированы сведения о том, как изменение связано с конфигурационными единицами, оказавшимися под его влиянием, как обновились планы внедрения релизов
    • утверждено или отклонено сотрудником, уполномоченным принимать подобные решения по изменениям в зависимости от их типа, размера и возможных рисков
    • осуществлено назначенным сотрудником из состава команды, ответственной за компоненты, над которыми производится изменение
    • протестировано, с проверкой результатов тестирования
    • закрыто и проанализировано
    • внесено в соответствующую отчетность о реализации
    • связано с инцидентом, проблемой, другим изменением и записями о конфигурационных единицах, если это целесообразно
  • Статус изменений и запланированные сроки их реализации должны использоваться в качестве основы для проведения календарного планирования внедрения изменений и релизов.
  • Информация о календарном планировании проведения изменений должна быть доступна для персонала, оказавшегося под влиянием изменения. В тех случаях, когда во время согласованных часов предоставления услуги изменение может вызвать простой в бизнесе, внедрение данного изменения следует согласовать с сотрудниками заказчиков, которые окажутся под его влиянием
Анализ и закрытие запроса на изменение
  • Все изменения, после их реализации, следует проанализировать на предмет их успешности или неудачи, при этом должны быть зарегистрированы все положительные результаты реализации изменения. После осуществления значительных изменений следует произвести формальный анализ результатов внедрения. Такой анализ необходим для проверки того, что:
    • в результате проведения изменения были достигнуты поставленные цели
    • заказчики услуг удовлетворены результатами изменения
    • изменение не вызвало непредвиденных отклонений в предоставлении услуг
    • все нарушения зарегистрированы для принятия необходимых мер
  • Отклонения и дефекты, выявленные в процессе управления изменениями, должны использоваться в качестве входной информации для формирования плана улучшения услуг
Срочные изменения
  • В случае необходимости осуществления срочных изменений следует использовать процесс управления изменениями с отложенным документированием хода и результатов изменения.
  • В случаях, когда срочное изменение выполняется без учета требований процесса управления изменениями, его следует привести в соответствие этим требованиям, как можно раньше
  • После внедрения срочного изменения должен быть проведен анализ обоснованности срочности теми сотрудниками, кто осуществлял изменение, срочность изменения должна быть подтверждена
Отчетность, анализ изменений и последующие действия
  • Записи об изменениях следует регулярно анализировать для выявления увеличения количества изменений, определения часто повторяющихся видов изменений, возможных тенденций в изменениях и другой значимой информации.
  • Выводы и результаты анализа следует регистрировать
  • В соответствии с результатами анализа следует планировать дальнейшие действия
Рекомендации и практики в области процесса управления релизами
  • Процесс управления релизами должен координировать действия поставщика услуг, подрядчиков, а также действия заказчиков услуг, для планирования и внедрения релиза в распределенную среду.
  • Качественное планирование и управление важно для компоновки релиза и его успешного распространения в действующей среде, а также для управления рисками для бизнеса и поставщика услуг. Планирование и развертывание релиза, затрагивающего информационные системы, инфраструктуру, услуги и документацию, должно осуществляться совместно персоналом поставщика и заказчика услуг.
  • Все обновления документации, связанные с релизом, следует включить в этот релиз
  • Следует произвести анализ влияния всех новых или измененных конфигурационных единиц, требуемых для авторизованного изменения.
  • Поставщик услуг должен обеспечить учет всех аспектов внедрения релиза, а не только технических
  • Следует обеспечить возможность отслеживания элементов релиза и их защиту от несанкционированных изменений. Только надлежащим образом протестированные и утверждённые релизы могут быть допущены к внедрению в действующую среду.
Политика релизов

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

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

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

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

Проектирование, сборка и конфигурирование релиза

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

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

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

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

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

Проверка и приемка релиза

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

При проведении проверки и приемки релиза следует:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • краткое описание услуги
  • срок действия и/или механизм контроля изменений в Соглашении об уровне услуг
  • подробности процедуры утверждения Соглашения об уровне услуг
  • краткое описание мероприятий по обмену информацией, включая отчетность
  • контактную информацию, включая сведения о сотрудниках, уполномоченных действовать в критических ситуациях, участвовать в устранении инцидентов, в восстановлении предоставления услуги, в решении проблем, в нахождении обходных решений для устранения инцидентов
  • дни и часы предоставления услуги, например, с 09:00 до 17:00, время, когда услуга недоступна (например, выходные, праздники и др.), периоды, критичные для бизнеса заказчика, а также дни и часы, не вошедшие в часы предоставления услуги
  • запланированные и согласованные перерывы в предоставлении услуги, включая установленные процедуры уведомления о перерывах, и их количество за согласованный период
  • ответственность заказчика, например, по обеспечению безопасности
  • обязательства и ответственность поставщика услуг
  • правила определения влияния и приоритета
  • процедуры эскалации и уведомления
  • процедуру подачи жалоб
  • целевые показатели уровня услуги
  • предельные значения (верхние и нижние) загрузки ресурсов поставщика при предоставлении услуги, например, возможность предоставления услуги согласованному количеству пользователей или возможность поддержки согласованного объема работ, производительность системы
  • финансовую информацию высокого уровня, например, коды для отнесения затрат
  • действия, которые необходимо предпринять в случае прерывания предоставления услуги
  • процедуры организации работ
  • глоссарий терминов
  • поддерживающие и связанные услуги
  • какие-либо исключения из условий, приведенных в Соглашении об уровне услуг

Примечание:

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

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

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

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

Политика:

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

Требования и контроль качества отчетности по услугам:

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

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

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

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

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

Рекомендации и практики в области бюджетирования и учета затрат для ИТ-услуг

Политика:

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

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

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

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

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

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

Бюджетирование

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

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

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

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

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

Учет затрат

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

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

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

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

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

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

Анализ услуг
  • Поставщику услуг и заказчику следует проводить анализ предоставляемых услуг не реже одного раза в год, а также до и после проведения значительных изменений
  • Анализ предполагает рассмотрение предоставления услуг за прошедший период времени, обсуждение текущих и планируемых потребностей бизнеса и инициацию предложений по необходимым изменениям в услугах и в Соглашениях об уровне услуг
  • На встречи по оценке услуг могут быть приглашены другие заинтересованные стороны, например, субподрядчики, группы пользователей и др.
  • Поставщику услуг и заказчику следует согласовать процедуры оперативного анализа предоставляемых услуг для обсуждения промежуточных результатов, достижений и спорных вопросов
  • Проведение встреч по оценке услуг должно носить плановый характер, а сведения об этих запланированных совещаниях должны быть доведены до всех заинтересованных сторон
  • Поставщику услуг следует протоколировать все встречи по оценке услуг, публиковать записи встреч и отслеживать ход выполнения решений.
  • Поставщику услуг следует установить с заказчиком взаимоотношения, обеспечивающие осведомленность поставщика об актуальных потребностях бизнеса и о возможных значительных бизнес-изменениях, а также предоставляющие поставщику возможность своевременного реагирования на эти события
Жалобы, связанные с предоставлением услуг
  • Поставщику услуг и заказчику следует согласовать формальную процедуру подачи жалоб
  • Поставщику услуг необходим действующий процесс для решения спорных вопросов
  • Для подачи жалоб в данном процессе следует определить точку контакта заказчиков с поставщиком услуг
  • Поставщику услуг следует регистрировать, исследовать, предпринимать необходимые действия, составлять отчетность и формально закрывать все жалобы
  • Остающиеся неразрешёнными жалобы следует регулярно анализировать и докладывать руководству, если их не удалось решить в течение сроков, согласованных с заказчиком
  • Поставщикам услуг следует периодически производить анализ записей о жалобах с целью определения тенденций в этой области и составления отчетов по результатам анализа для заказчиков услуг
  • Когда это целесообразно, результаты анализа жалоб следует использовать в качестве входной информации для формирования плана улучшения услуг
Оценка удовлетворенности заказчиков
  • В организации следует проводить измерение удовлетворенности заказчиков услуг для того, чтобы у поставщика услуг была возможность сравнить текущее значение удовлетворенности с его целевыми значениями и со значениями, полученными при проведении предыдущих опросов
  • Содержание опроса и сложность вопросов по определению удовлетворенности пользователей следует сделать такими, чтобы заказчики могли легко ответить на задаваемые им вопросы, и чтобы для выполнения и определения результатов опроса не требовалось чрезмерных затрат времени
  • Следует исследовать существенные отклонения текущего уровня удовлетворенности заказчиков по сравнению с целевыми значениями. Следует определить причины таких отклонений. Тенденции в изменении уровня удовлетворенности или другие сравнения в этой области следует производить только для сопоставимых вопросов и с применением сопоставимых методов проведения и определения результатов опроса
  • Результаты и выводы опросов удовлетворенности следует обсудить с заказчиками услуг. Должен быть согласован план необходимых действий, который будет включен в план улучшения услуг. Заказчик должен быть информирован о результатах выполнения согласованных действий
  • Положительные отзывы о результатах работы также следует документировать и доводить до сведения персонала поставщика услуг
Рекомендации и практики в области управления поставщиками

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

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

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

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

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

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

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

Управление контрактными разногласиями

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

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

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

Закрытие (расторжение) контракта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поставщику услуг следует:

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

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

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

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

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

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

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

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

Средства управления и контроля

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

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

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

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

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

3.3.19. Рекомендации и практики для процессов поддержки услуг

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

Общие рекомендации для процессов разрешения

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

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

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

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

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

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

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

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

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

Примечание 1:

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

Примечание 2:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание:

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

Решение проблемы

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

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

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

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

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

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

Закрытие инцидента и проблемы

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

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

Анализ проблем

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

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

Как правило, анализ проблем включает:

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

Задачи анализа проблем

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

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

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

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

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

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

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

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

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

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

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