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

Что такое оценка процессов

Сначала скажем несколько слов об оценке процессов вообще.

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

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

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

Cobit 2021

COBIT 2021 был опубликован в ноябре 2021 года.

Cobit 4.1

Публикации COBIT 4.1 состоят из Основного содержания , Руководства по обеспечению ИТ, Руководства по внедрению и Практики контроля .

В COBIT 4.1 Основное содержание определяет для каждого из процессов 34 COBIT:

Кроме того, основное содержание COBIT 4.1 описывает :

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

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

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

Методологический подход к общему внедрению управления ИТ описан в Руководстве по внедрению управления ИТ .

Процессы из COBIT 4.1 можно сравнить с процессами из ITIL v3 с помощью соответствующего сопоставления.

Cobit 5

COBIT 5 объединяет и интегрирует COBIT 4.1, Val IT 2.0, а также платформу управления рисками и BMIS (бизнес-модель информационной безопасности).

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

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

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

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

Пять основных принципов руководства и управления корпоративными ИТ:

1. Выполнение требований заинтересованных сторон
2. Покрытие всей компании
3. Использование единой интегрированной структуры
4. Обеспечение целостного подхода
5. Различие между руководством и менеджментом

В COBIT 5 определены и рассмотрены семь категорий факторов влияния, те факторы или ресурсы компании, которые должны способствовать достижению целей компании:

1. Принципы, руководства и рамки
2. Процессы
3. Организационные структуры
4. Культура, этика и поведение
5. Информация
6. Услуги, инфраструктура и приложения
7. Люди, навыки и компетенции

Эталонная модель процессов COBIT 5 определяет 37 процессов, которые сгруппированы в пять доменов, включая домен управления (EDM) и четыре домена управления (APO, BAI, DSS и MEA), а также PBRM (Plan, Build, Run, Monitor). назначен. Эти процессы можно сравнить с 26 процессами из ITIL v3 / Edition 2021, которые разделены на пять модулей Стратегия обслуживания (SS), Дизайн услуг (SD), Переход службы (ST), Работа службы (SO) и Постоянное улучшение обслуживания. (CSI) сгруппированы.

• EDM – оценка, определение и мониторинг (англ .: «Evaluate, Direct and Monitor»)
  • EDM01 Обеспечить создание и поддержание структуры управления
  • EDM02 Обеспечение внесения ценного вклада
  • EDM03 Обеспечение оптимизации рисков
  • EDM04 Обеспечение оптимизации ресурсов
  • EDM05 Обеспечение прозрачности по отношению к заинтересованным сторонам

• APO – Adjust, Plan and Organize (английский: «Согласовать, спланировать и организовать»)
  • APO01 Управление структурой управления ИТ
  • APO02 Управление стратегией
  • APO03 Управление архитектурой предприятия
  • APO04 Управление инновациями
  • APO05 Управление портфелем
  • APO06 Управление бюджетом и расходами
  • APO07 Управление персоналом
  • APO08 Управление взаимоотношениями
  • APO09 Управление соглашениями об обслуживании
  • APO10 Управление поставщиками
  • APO11 управление качеством
  • APO12 Управление рисками
  • APO13 Управление безопасностью

• BAI – сборка, приобретение и внедрение
  • BAI01 Управление программами и проектами
  • BAI02 Управление определением требований
  • BAI03 Управление идентификацией решения и построением решения
  • BAI04 Управление доступностью и мощностью
  • BAI05 Управление содействием организационным изменениям
  • BAI06 Управление изменениями
  • BAI07 Управление принятием и передачей изменений
  • BAI08 Управление знаниями
  • BAI09 Управление ресурсами
  • BAI10 Управление конфигурацией

• DSS – обеспечение, эксплуатация и поддержка (англ .: Deliver, Service and Support)
  • DSS01 Управление операциями
  • DSS02 Управление запросами на обслуживание и неисправностями
  • DSS03 Управление проблемами
  • DSS04 Управление непрерывностью
  • DSS05 Управление службами безопасности
  • DSS06 Управление средствами контроля бизнес-процессов

• MEA – мониторинг, оценка и оценка (англ .: «Monitor, Evaluate and Assess»)
  • MEA01 Мониторинг, оценка и оценка производительности и соответствия
  • MEA02 Мониторинг, оценка и оценка системы внутреннего контроля
  • MEA03 Мониторинг, оценка и оценка соответствия внешним требованиям

Модель возможностей процесса для оценки и постоянного улучшения процессов основана в COBIT 5 на международном стандарте ISO / IEC 15504 .

Iso / iec 38500

Еще один стандарт управления ИТ – ISO / IEC 38500 , опубликованный в 2008 году . С точки зрения ISACA, ISO 38500 не заменяет COBIT, но предназначен для представления вышестоящего взгляда сверху вниз, в то время как ITIL и PRINCE2 образуют основу в области управления ИТ-услугами, управления проектами и COBIT. соединительный слой между ними. Стандарт был обновлен в феврале 2021 года.

Iso/iec 15504 и isaca

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

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

Ассоциация ISACA в 2021 году решила в качестве такой методологии использовать международный стандарт ISO/IEC 15504 «Информационные технологии – оценка процесса». Идея стандартизации того, как оцениваются процессы, зародилась в 1990-х годах у разработчиков программного обеспечения1.

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

В том числе и процессов управления и руководства ИТ на предприятии. ISACA утвердила наметившийся вектор соответствия собственных разработок в области контроля и аудита и продукции международной организации по стандартизации ISO, выпустив книгу «COBIT Process Assessment Model:

В COBIT 5 процессная модель изложена в книге «COBIT 5: Enabling Processes» изначально совместимым со стандартом образом, так, чтобы максимально упростить оценку.

Так как же оцениваются возможности процессов?

Модель зрелости cobit 4.1

Методология COBIT 4.1 предлагала подобную систему оценки процессов, называя ее «Моделью зрелости» (COBIT 4.1 Maturity Model). В основе системы лежала шкала оценки и модель зрелости способностей (Capability Maturity Model, CMM) Института разработки программного обеспечения (the Software Engineering Institute, SEI), широко известная как «Интегрированная модель зрелости» (Capability Maturity Model Integration, CMMI).

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

• «0»: Не существующий процесс
• «1»: Начальный процесс
• «2»: Интуитивно повторяющийся
• «3»: Определенный (документированный) процесс
• «4»: Измеряемый и управляемый
• «5»: Оптимизируемый

Авторы COBIT 4.1 создали два простых инструмента, с помощью которых можно было определить, какую из этих оценок нужно поставить рассматриваемому процессу:

• Шесть атрибутов зрелости:
  1. Осведомленность и коммуникации
  2. Политики, планы и процедуры
  3. Инструменты и автоматизация
  4. Навыки и квалификация
  5. Ответственность и подотчетность
  6. Цели и измерение

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

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

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

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

• COBIT 4.1 не предлагает объективных характеристик уровней зрелости;
• COBIT 4.1 не предлагает категоричного разделения между уровнями зрелости.

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

Оценка возможностей процессов по pam

Формально модель оценки процессов выглядит так:

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

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

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

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

• Процесс, который не создает всех ожидаемых заинтересованными сторонами результатов, автоматически получает оценку «0». Это означает, что применять такую методику можно для достаточно «зрелых» процессов, во всяком случае, выше уровня 2.
• Процесс, который здесь и сейчас (то есть в заданных условиях) создает все ожидаемые результаты в полном объеме, получает оценку «1».
• Процесс может получить любую оценку выше «1», только если выполнены все требования нижележащих уровней возможностей.

Так что же требуется от уже работающего (а иногда в ITSM – и очень дорогостоящего) процесса, чтобы не получить «незачет» или «кол»? Ответ стандарта ISO 15504: выполнять и создавать свидетельства выполнения универсальных управленческих практик.

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

ISACA предлагает сертификаты COBIT с июля 2005 года. В настоящее время доступны следующие сертификаты:

• COBIT 5
  • Фонд COBIT 5
  • Внедрение COBIT 5
  • Эксперт COBIT 5
  • Реализация инфраструктуры кибербезопасности NIST с использованием COBIT 5
• COBIT 2021
  • Фонд COBIT 2021
  • COBIT 2021 Дизайн и реализация
  • Реализация инфраструктуры кибербезопасности NIST с использованием COBIT 2021

Ежегодно ISACA организует региональные (европейские) и международные конференции, а также несколько съездов пользователей COBIT . На этих платформах предлагаются лекции и семинары по всем аспектам COBIT и управления ИТ.

Подход к контролю

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

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

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

Процесс оценки и требования к оценщику

COBIT PAM в более удобном, чем стандарт ISO 15504, виде описывает проведение оценки процессов.

Публикации, относящиеся к cobit

К другим публикациям ISACA, имеющим отношение к COBIT, относятся:

• Брифинг для Совета по управлению ИТ – повышение осведомленности о необходимости управления ИТ в масштабах компании
• COBIT Mapping – серия документов, сравнивающих COBIT и другие ИТ-стандарты (например, ITIL , ISO 17799 , IT-Grundschutz Catalogs , NIST , FIPS , ISO 13335 , TOGAF и т. Д.). В рамках сопоставления COBIT совместно с издателем ITIL была создана публикация об оптимальном сочетании COBIT, ITIL и ISO 27001 .
• Цели контроля для Сарбейнса Оксли – Руководство по определению основных контрольныхдействий, которые обычно определяются в контекстереализаций SOX .
• Цели контроля для Базеля II – Инструкции по внедрению требований Базеля II с помощью структуры COBIT (в настоящее время готовится)

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

Словарь pam

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

Итак:

Процесс состоит из базовых практик (Base practices, BPs). Привычный эквивалент – «виды деятельности» или «шаги». BPs процессов COBIT 5 могут быть хронологически связаны, а могут и повторяться относительно друг друга, что отличает их от производственных процессов.

BPs формируют артефакты или рабочие продукты процесса (Work products, WPs). Стандарт ISO 15504 выделяет три вида WP: это политики (правила игры), планы (документированные намерения) и записи (свидетельства о выполнении намерений).

Пример. WP APO01.03 «Связанные с ИТ политики» формируется в процессе APO01, и является входом для всех остальных процессов домена APO.

Вместе BPs и WPs называются «индикаторами производительности процесса».

Выполняя BPs и формируя WPs, процесс приводит к ожидаемым результатам (Outcomes, O’s). По смыслу O’s идентичны «целям и задачам» процесса.

Важно упомянуть о том, что референтная модель процессов COBIT 5 содержит два логических «скачка», унаследованных из стандарта ISO 15504. Во-первых, получение всех WPs означает достижение всех O’s процесса. Во-вторых, достижение O’s автоматически означает, что процесс соответствует своему назначению3.

И первое и второе более чем спорно не только для реальных ITSM-процессов, но для некоторых процессов COBIT 5. Тем не менее, это обязательные условия модели оценки возможностей, а также свидетельство по-настоящему качественной работы проектировщиков и методологов процесса. В референтной модели COBIT 5 связь «O-BP-WP» (результат – вид деятельности – выход) отражена в явном виде.

Чтобы процесс соответствовал своему назначению независимо от своего масштаба, организация должна управлять процессом, а значит, кто-то должен выполнять еще и управленческие практики, применительно к каждому процессу (generic management practices, GPs) . Читатели ITIL® уже знают, что «кто-то» – это владелец и менеджер процесса.

При выполнении GP формируются универсальные рабочие продукты (Generic work products, GWPs). Универсальные GWP применимы к любому оцениваемому процессу.

Вместе GP и GWP называются «индикаторами возможностей процесса».

Следуя приведенной выше терминологии, перефразируем принцип начисления «баллов» для выставления «оценки»: аудитор-оценщик ищет свидетельства выполнения BPs и GPs процесса. Свидетельства могут быть выражены в форме WPs и GWPs, а могут быть и мнением заинтересованных сторон о достижении процессом своих O’s.

Что же произойдет, если оценщик эти свидетельства обнаружит? Он распределит их по атрибутам возможностей процессов.

Строгая модель оценки на основе стандарта ISO 15504 разделяет все BPs и GPs на девять групп (атрибутов процесса). Каждому уровню возможностей процесса соответствует 1 или 2 таких атрибута. Разделение предельно простое:

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

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

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

Шаг второй планирование оценки

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

Шаг первый определение охвата

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

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

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

1. Выявить стимулы для проведения оценки процессов. Иначе говоря, зачем нужна оценка?
2. Ранжировать процессы по степени поддержки движущих сил бизнеса (см. статью про каскад целей или про принципы COBIT 5 Романа Журавлева).
3. В соответствии с приоритетами, выбрать процессы, которые будут в оценке.
4. Согласовать предварительный охват оценки со спонсором проекта и ключевыми заинтересованными сторонами.
5. Утвердить список оцениваемых процессов.
6. Задокументировать методологию в записях проекта оценки.

Шаг пятый проверка данных

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

Шаг седьмой отчет о результатах

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

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

Шаг третий брифинг

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

Шаг четвертый сбор данных

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

Шаг шестой подсчет атрибутов

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