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

Таблица 3.3. Сравнение некоторых стандартов аудита ИТ

Ассоциация ISACA, в отличие от других, занимается открытым аудитом информационных систем. Она основана в 1969 году и в настоящее время объединяет более 35 тыс. членов из более чем 100 стран, в том числе и России. Ассоциация IS АС А координирует деятельность более чем 38 тыс. сертифицированных аудиторов информационных систем (CISA - Certified Information System Auditor), имеет свою систему стандартов в этой области, ведет исследовательские работы, занимается подготовкой кадров, проводит конференции. Ассоциация ISACA под аудитом информационной безопасности в информационной системе понимает процесс сбора сведений, позволяющих установить, обеспечиваются ли безопасность ресурсов компании, необходимые параметры целостности и доступности данных, достигаются ли цели предприятии в части эффективности информационных технологий.

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

Концепция изложена в документе под названием CobiT 3rd Edition (Control Objectives for Information and Related Technology), который состоит из шести частей:

Часть 1: Резюме для руководителей (Executive Summary);

Часть 2: Определения и основные понятия (Framework). Помимо определений и основных понятий в этой части сформулированы требования к ним;

Часть 3: Цели контроля (Control Objectives);

Часть 4: Принципы аудита (Audit Guidelines);

Часть 5: Набор средств внедрения (Implementation Tool Set);

Часть 6: Принципы управления (Management Guidelines).

Третья часть этого документа в некотором смысле аналогична международному стандарту ISO 17799:2005 (BS 7799-1:2002). Примерно так же подробно приведены практические рекомендации по разработке политик безопасности и управлению информационной безопасностью в целом, но модели систем управления в сравниваемых стандартах сильно различаются. Стандарт CobiT (Control Objectives for Information and Related Technology) - пакет открытых документов, первое издание которого было опубликовано в 1996 году. Кратко основная идея стандарта CobiT выражается следующим образом: все ресурсы информационной системы должны управляться набором естественно сгруппированных процессов (рис. 3.10) для обеспечения компании необходимой и надежной информацией.

Рас. 3.10. Процессы управления ресурсами информационной системы

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

Рис. 3.11. Объекты контроля и управления информационными технологиями

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

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

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

Мы продолжаем цикл публикаций, знакомящих читателей с методологией COBIT® 5. Мы уже описывали принципы и процессную модель COBIT 5. Пришло время сказать еще об одной ключевой составляющей COBIT 5 – модели оценки процессов (COBIT Process Assessment Model, PAM).

В этой статье мы расскажем о том, что это за модель, как она устроена и зачем она нужна аудиторам, руководителям и сотрудникам ИТ.

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

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

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

Назначение совершенствования процессов – постоянное повышение результативности и рациональности организации.

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

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

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

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

Модель зрелости 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»: Оптимизируемый

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

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

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

К примеру, процесс управления изменениями (AI6) описывался в COBIT 4.1 такой моделью зрелости:

Уровень «0»: не существует определенного процесса управления изменениями, и изменения производятся практически бесконтрольно. Нет осведомленности о негативном влиянии изменений на ИТ и на бизнес, и нет осведомленности о выгодах правильного управления изменениями.

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

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

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

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

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

ISO/IEC 15504 и ISACA

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

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

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

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

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

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

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

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

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

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

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

COBIT 5 PAM:

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

Неполный процесс не достигает всех поставленных целей (Outcomes) полностью.

Уровень 1: Выполняемый (Performed) процесс – Процесс внедрен и соответствует своему назначению. В случае если результаты процесса не достигаются, то такой процесс будет оценен на 0 (ноль) по шкале ISO/IEC 15504.

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

Уровень 2: Управляемый (Managed) процесс – Выполняемый процесс предыдущего уровня теперь управляем (то есть планируется, отслеживается и корректируется). Создаются, контролируются и поддерживаются рабочие продукты (work products) процесса.

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

Уровень 3: Установленный (Established) процесс – Управляемый процесс теперь способен получать ожидаемые результаты (outcomes).

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

Уровень 4: Предсказуемый (Predictable) процесс – Установленный процесс теперь получает результаты в условиях заданных ограничений.

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

Уровень 5: Оптимизируемый (Optimizing) процесс – предсказуемый процесс теперь постоянно совершенствуется, чтобы достигать текущих и будущих целей предприятия.

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

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

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

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

Словарь PAM

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

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

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

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

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

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

Важно упомянуть о том, что референтная модель процессов COBIT 5 содержит два логических «скачка», унаследованных из стандарта ISO 15504. Во-первых, получение всех WPs означает достижение всех O"s процесса. Во-вторых, достижение O"s автоматически означает, что процесс соответствует своему назначению . И первое и второе более чем спорно не только для реальных 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 таких атрибута. Разделение предельно простое:

• Неполный процесс не содержит атрибутов, так как существуют не все BP, и не формируются O"s.
• Выполняемый процесс содержит один атрибут, «Осуществление процесса». Этот атрибут будет реализован, если выполняемые BPs приводят к достижению O"s.
• Управляемый процесс содержит два атрибута: «Управление осуществлением» (шесть GPs) и «Управление рабочими продуктами» (четыре GPs).
• Установленный процесс содержит два атрибута: «Определение процесса» (пять GPs) и «Развертывание процесса» (шесть GPs)
• Предсказуемый процесс содержит два атрибута: «Измерение процесса» (шесть GPs) и «Контроль процесса» (пять GPs).
• Оптимизируемый процесс содержит два атрибута: «Инновации процесса» (пять GPs) и «Оптимизация процесса» (три GPs).

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

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

• N (not achieved, не достигается) . В оцениваемом процессе не существует, или существует мало свидетельств того, что определенный атрибут достигается (от 0 до 15% реализованных практик).
• P (partially, частично достигается) . В оцениваемом процессе существуют свидетельства того, что существует подход к достижению, и происходит частичное достижение заданных целей. Некоторые аспекты того, как достигается цель (атрибут) непредсказуемы (от 15% до 50% реализованных практик).
• L (largely, в основном достигается) . В оцениваемом процессе существуют свидетельства системного подхода и системного достижения заданных целей. Существуют некоторые недостатки достигаемых результатов (от 50% до 85% реализованных практик).
• F (fully, полностью достигается) . В оцениваемом процессе существуют свидетельства полного системного подхода и фактического достижения заданных целей. Значительных недостатков связанных с полученным результатом не выявлено (от 85% до 100% реализованных практик).

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

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

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

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

• Назначения (Purpose statement)
• Результатов (Outcomes)
• Базовых практик (Base practices)
• Входов и выходов (Work products)

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

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

В качестве иллюстрации приведем несколько примеров универсальных управленческих практик (GPs), которые заявлены в стандарте ISO 15504 и продублированы в COBIT PAM:

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

О каждой GP, как уже было сказано выше, свидетельствуют универсальные рабочие продукты (GWPs). Их происхождение – это, пожалуй, единственное дополнение к стандарту ISO 15504, которое было изобретено авторами COBIT PAM. Список этих документов близок и менеджерам по качеству, и практикам процессов ITSM, их всего девять:

1. Процессная документация (диаграмма, охват, RACI-матрица и т.д.)
2. План процесса
3. План качества (содержание WP, критерии качества WP и т.д.)
4. Записи по качеству
5. Политики и стандарты
6. План совершенствования процесса
7. План измерения процесса
8. План контроля процесса
9. Записи о производительности процесса

Таким образом, книга COBIT PAM содержит:

• Общее описание подхода к оценке возможностей
• Референтную модель процессов COBIT 5 в формате ISO 15504
• Перечень и описание универсальных управленческих практик и распределение их по атрибутам возможностей
• Перечень и описание универсальных рабочих продуктов и распределение их по универсальным управленческим практикам

Кроме этого в состав программы COBIT по оценке процессов входят и дополнения:

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

Такой перечень дополнительных публикаций отражает двойное назначение COBIT PAM: проведение внешних и внутренних оценок.

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

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

ШАГ ПЕРВЫЙ Определение охвата

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

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

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

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

ШАГ ВТОРОЙ Планирование оценки

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

ШАГ ТРЕТИЙ Брифинг

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

ШАГ ЧЕТВЕРТЫЙ Сбор данных

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

ШАГ ПЯТЫЙ Проверка данных

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

ШАГ ШЕСТОЙ Подсчет атрибутов

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

ШАГ СЕДЬМОЙ Отчет о результатах

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

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

Итог

Самой яркой прикладной пользой COBIT 5 PAM, на взгляд автора, являются описания универсальных рабочих продуктов (GWPs). Это практически полный перечень и детальное оглавление всей процессной документации. Набор этих документов довольно точно воспроизводит иерархию документов в ITIL (политики, описание, процедуры и инструкции процесса) и поможет любому методологу или проектировщику процесса: начинающему или опытному, работающему на предприятии или в консалтинге.

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

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

Если говорить о перспективах применения COBIT 5 PAM в российских реалиях, то языковой барьер может стать существенным ограничителем. Язык стандарта середины 2000-х годов бюрократичен и поэтому трудно осмысливаем. Чего только стоят обороты при определении уровней возможностей:

Level 3 Established process (two attributes) - The previously described managed process is now implemented using a defined process that is capable of achieving its process outcomes. Увы, но ради универсальности всегда приходится жертвовать пониманием. Мы очень ждём от ISACA дополнительных публикаций, например, историй успеха, с помощью которых можно будет осознать уровни возможностей и причины именно такой их последовательности.

При этом COBIT PAM обладает рядом явных преимуществ, по сравнению с привычными моделями зрелости:

• Гибкий и удобный инструмент оценки, совместимый с международным стандартом ISO 15504
• Требования к конкретным процессам из процессной модели COBIT 5
• Возможность снабжать процессы атрибутами стандарта ISO 15504
• Требования к свидетельствам (в том числе для аудита)
• Требования к оценщику и его опыту

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

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

COBIT 5 PAM – замечательный, системный и весьма подробный инструмент для аудитора, руководителя, и практика процессного управления ИТ. Как и любой другой, его нужно применять одновременно разумно и творчески, не воспринимая эту модель в качестве строгой научной теории. Мы всё еще продолжаем говорить о «практических рекомендациях», и только здравый смысл и постоянная самопроверка («а зачем мне это нужно?») поможет извлечь реальную пользу из них.

Примечания

1. Занятно, что и модель зрелости CMM тоже с самого начала была заказана Министерством обороны США для того, чтобы объективно сравнивать между собой подрядчиков, которые выполняли разработку ПО.
2. Примеры применения стандарта в различных отраслях можно найти в Википедии: http://en.wikipedia.org/wiki/ISO/IEC_15504 .

3. Источники расходятся в том, что стоит за словами «назначение», «цель» и «задача». Мы не можем в рамках этой публикации вдаваться в этот семантический спор. Договоримся, что в COBIT 5 «Outcome – это утвердительное предложение, описывающее целевое состояние организации в абсолютных терминах». А Purpose – это утвердительное предложение, которое объясняет, зачем нужен этот процесс. К примеру, для процесса «BAI06 Управление изменениями» назначением (Purpose statement) является:

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

   А целями этого процесса являются:

   • Авторизованные изменения выполняются в срок и с минимальным количеством ошибок.
   • Проводимые оценки влияния описывают воздействие изменения на все затронутые компоненты
   • Все экстренные изменения оцениваются и авторизуются после изменения
   • Ключевые заинтересованные стороны информированы обо всех аспектах изменения
4. Отметим, что во избежание путаницы, авторы COBIT PAM убрали из этого термина стандарта ISO 15504 слово «management», так как эти практики применимы и к процессам домена руководства (Governance).
5. Такая модель наиболее ярко иллюстрируется любимой многими менеджерами по качеству цитатой из Л. Кэрролла: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!». Можно представить себе повышение уровня возможностей процессов как всё ускоряющийся «бег», позволяющий процессу не отставать от изменяющейся окружающей среды, и «попасть» в целевое состояние и результаты.

Ссылки и публикации

• COBIT® Process Assessment Model (PAM): Using COBIT® 4.1 ISBN 978-1-60420-188-8
• COBIT® Process Assessment Model (PAM): Using COBIT® 5 ISBN 978-1-60420-264-9
• COBIT® 5 A Business Framework for the Governance and Management of Enterprise IT ISBN 978-1-60420-256-4
• ГОСТ Р ИСО/МЭК 15504-1-2009 Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь
• ГОСТ Р ИСО/МЭК 15504-2-2009Информационная технология. Оценка процесса. Часть 2. Проведение оценки
• ГОСТ Р ИСО/МЭК 15504-3-2009 Информационная технология. Оценка процесса. Часть 3. Руководство по проведению оценки.
• http://www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-Assessment-Programme.aspx домашняя страница COBIT 5 PAM.
• http://www.isaca.org/Knowledge-Center/Research/Documents/Assessment-Programme-Introduction.pptx презентация программы оценки возможностей процессов, применительно для процессной модели COBIT 4.1 (английский, формат Microsoft PowerPoint presentation)

ITIL® - зарегистрированная торговая марка компании AXELOS Limited.
COBIT®, ISACA® - торговые марки ISACA.

В данной статье использовались материалы: ITIL(Information Technology Infrastructure Library); MOF (Microsoft Operations Framework); ITSM HP Reference Model; ITPM (IT Process Model); COBIT (Control Objectives for Information and related Technology).

Введение

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

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

Стандарты в области информационных технологий

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

ITIL (Information Technology Infrastructure Library)

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

Фактически библиотека ITIL предлагает построение процессной модели для управления ИТ- подразделением, результатом деятельности которого являются ИТ- услуги для бизнеса с прозрачной стоимостью, качество которых гарантируется путем организации непрерывного контроля. Библиотека ITIL содержит лучший мировой опыт по построению единой комплексной системы управления ИТ- подразделением, который возможно применять к конкретной ситуации. Поскольку библиотека является свободно распространяемой, то она является наиболее применяемым сегодня подходом к управлению ИТ- услугами, который применим ко всем секторам и организациями любого размера. ITIL может быть внедрен как полностью, так и частично, и фактически, это некоторая система взглядов на управление информационными технологиями в компании. Владельцем проекта ITIL в настоящее время является OGC/CCTA (Офис правительственной коммерции / Центральное агентство по компьютерам и телекоммуникациям). Обобщение опыта управления ИТ на протяжении 20 лет под эгидой правительства Великобритании сделало книги ITIL по всем основным областям управления ИТ стандартом «де-факто».

COBIT (Control Objectives for Information and related Technology)

– стандарт управления и аудита в области информационных технологий. Основой стандарта COBIT являются 34 высокоуровневые цели контроля, по одной на каждый ИТ- процесс, которые сгруппированы в 4 домена: Планирование и Организация, Проектирование и Внедрение, Эксплуатация и Сопровождение, Мониторинг. Особенностью стандарта COBIT по отношению к другим стандартам в области ИТ является присутствие в нем модели зрелости разработанной в конце 80-х годов Институтом проектирования и разработки программного обеспечения (Software Engineering Institute’s). Maturity Models (MM) – не технология, не стандарт, для нее нет формальных описаний, в ней нет жестких требований, и она не привязана к конкретным информационным технологиям. Однако данная модель зрелости вводит понятие нескольких уровней зрелости процессов:

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

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

MOF (Microsoft Operations Framework)

— Управление информационными технологиями эта тема, в которой компания Microsoft имеет свое видение. Система стандартов Microsoft Enterprise Services от компании Microsoft представляет собой три области:

• Первой областью является деятельность по подготовке к внедрению информационной системы где формализуются требования к ИТ и определяется объем проекта. Подготовка к внедрению информационной системы описана в стандарте Microsoft Readiness Framework (MRF);
• Второй областью является деятельность по внедрению информационной системы на предприятии, где определяются основные вопросы разработки и развертывания ИТ- решения. Построение и внедрение информационной системы описано в стандарте Microsoft Solutions Framework (MSF);
• Третьей областью является деятельность по поддержке информационной системы внедренной на предприятии. Вопросы эксплуатации информационной системы рассматриваются в стандарте Microsoft Operations Framework (MOF).

MOF состоит из набора статей (white papers), руководств (operations guides), обучающих курсов и включает в себя три основные модели:

• Модель процессов (MOF Process Model); o Модель команды (MOF Team Model);
• Модель управления рисками (MOF Risk Model).

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

ITSM HP Reference Model

– это корпоративная модель, которая была разработана компанией HP на основе и в полном соответствии с библиотекой ITIL. Фактически данная модель является переработкой ITIL с учетом зрения компании HP и перечень процессов в обеих моделях одинаковый.

ITPM (IT Process Model)

– это стандарт, который был предложен компанией IBM в конце 70-х годов прошлого века для решения задач управления компьютерными системами. Была создана архитектура ISMA (Information Systems Management Architecture) и концепция (IT Process Model), возникшая из ISMA и принятая к использованию компанией IBM. Данный подход отличается от ITIL не только по способу деления процессов, но и в ряде терминологических моментов. Фактически IT Process Model — это 41 процесс, собранный в восемь групп по числу основных факторов, влияющих на успех ИТ- проектов:

• Взаимодействие с клиентами;
• Обеспечение управленческих систем корпоративной информацией;
• Управление ИТ с точки зрения бизнеса;
• Подготовка решений;
• Развертывание решений;
• Предоставление услуг и управление изменениями;
• Поддержка ИТ-услуг и решений;
• Управление ИТ-ресурсами и инфраструктурой.

Однако, если говорить о практике использования данной модели в России, то она используется достаточно редко. ISO 20000 – один из новых стандартов в области менеджмента качества, который вобрал в себя с незначительными изменениями большинство основных принципов и процессов ITIL. В настоящий момент времени производится сертификация ИТ – подразделений на соответствие сервис -ориентированному и процессному подходу в области управления ИТ с использованием данного стандарта.

Библиотека ITIL

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

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

• Управление уровнем сервиса (Service Management) – достижение ясных соглашений с Заказчиком об ИТ-услугах и реализация этих соглашений;
• Управление затратами (Cost Management) – определение, отнесение расходов, их прогноз и отслеживание;
• Управление мощностями (Capacity Management) – оптимизация расходов, времени приобретения и размещения ИТ-ресурсов;
• Управление доступностью (Availability Management) – оптимизация обслуживания и минимизация числа инцидентов;
• Управление непрерывностью (Continuity Management) – подготовка и планирование способов устранения чрезвычайных ситуаций;
• Управление безопасностью (Security Management) – обеспечение режима информационной безопасности.

Другим основополагающим процессом ITIL является процесс поддержки сервисов (Service Support) в рамках которого определены следующие процессы:

• Взаимодействие с пользователями (Service Desk) – точка контакта пользователя с ИТ – организацией;
• Управление инцидентами (Help Desk/ Incedent Management) –устранение инцидента и быстрое возобновление предоставления услуг;
• Управление проблемами (Problem Management) – предупреждение и устранение корневых проблем инцидентов;
• Управление конфигурациями (Configuration Management) – контроль изменяющейся ИТ-инфраструктуры;
• Управления изменениями (Change Management) – контроль проведения изменений в ИТ-инфраструктуре;
• Управление релизами (Software Control & Distribution) – обеспечение успешного развертывания релизов, включая интеграцию, проведение тестирования и хранения.

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

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

Стандарт MOF

Если сравнивать объем библиотеки ITIL c моделью процессов MOF, то модель MOF является некоторым расширением процессов, описанных в книгах «Предоставление ИТ-услуг» и «Поддержка ИТ-услуг» библиотеки ITIL. Фактически модель MOF Process Model представляет процессы управления обслуживанием информационных систем, которые представлены в виде функций управления услугами (Service Management Functions, SMF).

Вся модель MOF содержит в себе 20 сервисных функций разбитых на четыре квадранта:

• Изменение (Changing) — Внедрение изменений процессов, новых решений и технологий;
• Обслуживание (Operating) – Обеспечение выполнения каждодневных рутинных операций;
• Поддержка (Supporting) – Обеспечение скорейшего решения инцидентов, проблем, запросов;
• Оптимизация (Optimizing) — Оптимизация стоимости, производительности, доступности ИТ- услуг.

В рамках данных четырех квадрантов распределяются все 20 сервисных функций.

В квадранте «Изменение» собраны три следующих сервисных функции:

• Управление изменениями (Change Management). Планирование и регистрация всех требуемых изменений в информационной системе, оценка влияния, оказываемого этими изменениями, на другие компоненты информационной системы;
• Управление релизами (Release Management). Контроль над релизами и процессом их развертывания должен гарантировать, что все релизы хорошо спланированы и протестированы;
• Управление конфигурациями (Configuration Management). Регистрация и контроль сведений о конфигурационных элементах ИТ-инфраструктуры включает в себя процесс сбора информации обо всех конфигурационных элементах системы в единую базу данных и процессы аудита соответствия информации текущей ситуации.

В квадранте «Поддержка» собраны три следующих сервисных функции:

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

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

• Управление уровнем обслуживания (Service Level Management). Управление качеством ИТ- услуг путем определения и контроля параметров соглашения об уровне услуг (Service Level Agreement, SLA) между поставщиком и заказчиками;
• Управление финансами (Financial Management). Определение, оптимизация и контроль стоимости ИТ- услуг, что включает планирование и составление бюджетов, анализ стоимости услуг, а также мероприятия по оптимизации затрат на ИТ и оценке необходимости инвестиций;
• Управление непрерывностью услуг (Service Continuity Management). Восстановление ИТ- инфраструктуры в случае непредвиденных ситуаций. Включает разработку плана быстрого восстановления критически важных для бизнеса систем;
• Управление мощностями (Capacity Management). Контроль и обеспечение необходимой производительности ИТ- ресурсов в соответствии с определенным уровнем обслуживания в SLA;
• Управление доступностью (Availability Management). Управление доступностью информации и услуг с точки зрения использования имеющихся мощностей;
• Управление персоналом (Workforce Management). Выработка рекомендаций по набору, сохранению и мотивированию ИТ- персонала.

В квадранте «Обслуживание» собраны 8 следующих функций:

• Планирование работ (Job Scheduling). Организация процесса выполнения работ наиболее эффективным образом для выполнения требований соглашения об уровне услуг;
• Системное администрирование (System Administration). Выполнение ежедневных операций по администрированию информационной системы;
• Сетевое администрирование (Network Administration). Обеспечение бесперебойной работы сетевой инфраструктуры;
• Администрирование системы безопасности (Security Administration). Обеспечение безопасности информационной системы, определение и контроль параметров защиты корпоративной информации и ИТ- услуг;
• Администрирование служб каталога (Directory Services Administration). Обслуживание и поддержка корпоративной службы каталога;
• Управление хранением данных (Storage Management). Разработка плана архивации/восстановления данных, контроль над системами хранения;
• Мониторинг услуг (Service Monitoring and Control). Получение обслуживающим персоналом актуальной информации о состоянии ИТ- услуг. Наиболее типичными объектами мониторинга являются: состояние процессов, статусы запланированных заданий, параметры очередей, загрузка серверов, время отклика приложений;
• Управление результатами (Print and Output Management). Контроль над процессом печати данных и данными, предоставляемыми в отчетах.

Если сравнивать объем стандарта MOF с процессами ITIL по предоставлению и поддержке услуг, то видно, что MOF несколько шире, однако расширение связано с некоторой детализацией квадранта «Обслуживание», что с одной стороны дает определенную информацию, но с другой стороны данная деятельность присутствует в большинстве ИТ- служб и расширение модели в данном направлении не вносит большой новизны. Добавление сервисной функции Управление персоналом не несет специфических знаний для организации ИТ в компании и является вспомогательным процессом, который присутствует в любой компании и логика выполнения которого предельно понятна. В остальном, процессы ITIL и MOF полностью идентичны, включая одинаковые наименования и описания.

Однако, стандарт MOF помимо процессной модели содержит ролевую структуру для распределения полномочий и ответственности между сотрудниками ИТ — модель команды (MOF Team Model). Причем модель команды не предназначена для описания трудовых обязанностей и не является организационной схемой.
В модели команды MOF описаны шесть ролей, сгруппированных по жизненному циклу ИТ- услуги. Фактически данные роли являются некоторыми направлениями деятельности:

• Релиз (Release) — Планирование и выполнение изменений;
• Поддержка (Supporting) — Поддержка пользователей;
• Безопасность (Security) — Контроль над корпоративной политикой безопасности;
• Инфраструктура (Infrastructure) — Управление средствами работы с инфраструктурой;
• Обслуживание (Operations) — Выполнение ежедневных операций по обслуживанию ИС;
• Партнерство (Partner) — Установление взаимоотношений с бизнесом.

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

Помимо модели команды стандарт MOF содержит в себе модель управления рисками (MOF Risk Model), которая определяет основные этапы управления рисками:

• Идентификация рисков (Identify). Определение причин риска, условий его возникновения, последствий;
• Анализ рисков (Analyze). Оценка вероятности возникновения риска и ущерба для информационной системы и бизнеса;
• Планирование мероприятий (Plan). Определение мероприятий, позволяющих полностью избежать риска или уменьшить его влияние. Также на тут разрабатывается план действий в случае возникновения риска
• Отслеживание риска (Track). Сбор информации об изменениях с течением времени различных элементов риска. В случае, если риск считается с некоторого времени незначимым, его необходимо исключить из списка рисков. Если влияние риска изменилось, следует перейти к этапу анализа для переоценки этого влияния
• Контроль (Control). Выполнение запланированных действий в качестве реакции на возникновение рискового события. Фактически данные этапы управления рисками связываются в жизненный цикл управления рисками от идентификации до непрерывного контроля.

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

Вывод

В результате сравнения ITIL и MOF мы увидели, что MOF обладает рядом существенных особенностей по сравнению со стандартом ITIL, однако если рассмотреть данные особенности, то они не носят ключевого характера: o Процессы, не включенные в ITIL, являются интуитивно понятными и принятыми в оперативной деятельности; o Модель процессов дополнена моделями команды и управления рисками, но применение данных моделей осложнено из-за слабой их детализации; o В противовес документам чисто описательного характера, свойственным ITIL, в MOF предоставлены прикладные материалы, такие как документы серий Windows Operations Guide, Exchange Operations Guide и т.д. Однако данные документы имеют привязку к определенной операционной системе и в принципе не относятся к организации процессов. Если делать вывод о применимости рассмотренных стандартов в области ИТ для оптимизации деятельности, то можно с уверенностью сказать что все они содержат «зерно истины», поэтому применение их в совокупности наиболее предпочтительно, поскольку в определенных областях они имеют новшества относительно друг друга.

В данной статье использовались материалы: MOF (Microsoft Operations Framework); ITSM HP Reference Model; ITPM (IT Process Model); COBIT (Control Objectives for Information and related Technology).

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

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

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

Зоопарк методологий: очень краткий обзор

ITIL и ITSM

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

На самом деле, эта библиотека породила целую парадигму управления ИТ-инфраструктурой компании, основанную на SLA (соответствие обещаний поставщика услуги ожиданиям клиента) и ITSM (IT Service Management, управление ИТ-услугами). ITSM - это концепция организации работы ИТ-подразделения и его взаимодействия с внешним или внутренним заказчиком, а также внешними контрагентами.

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

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

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

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

CobiT

CobiT (Control Objectives for Information and Related Technologies , задачи управления для информационных и смежных технологий) - сбор стандартов и руководств в области управления ИТ-аудита и безопасности; руководство и сборник практик по управлению ИТ-процессами. Связанный с ITIL инструмент, который непрерывно обновляется и предназначен для того, чтобы между руководством компании, ИТ-специалистами и аудиторами (внешними и внутренними) царили мир и взаимопонимание. Проще говоря, управляющий менеджер должен понимать все ИТ-риски, в том числе связанные с бездействием в ситуациях, требующих коррекции, а также потенциальные риски, связанные с использованием того или иного элемента ИТ-инфраструктуры компании.

Рассмотрим две распространённые ситуации.

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

Ситуация вторая , свойственная компаниям любого уровня: от микробизнеса до транснациональных корпораций, - неадекватная оценка рисков. Почти каждый из нас хоть раз встречался с рисками завышенного масштаба: например, страх перед DDoS в небольшой компании или всем известная и так и не ставшая реальностью «проблема 2000». Это риски, которым придают огромное значение и которые не несут объективной угрозы. С другой стороны, существуют недооценённые риски, на которые никто не обращает внимание, но именно они способны положить весь рабочий процесс или принести коммерческий ущерб: неограниченный срок действия учётных записей и паролей пользователей от рабочих ПК и корпоративных информационных систем, клиент-банков; передача коммерчески значимых данных по незащищённым каналам; отсутствие антивирусов и проч. Чтобы классифицировать риски и грамотно их оценить, необходимо проводить внутренний и/или внешний ИТ-аудит. Он, в свою очередь, должен быть не проверкой соответствия правилам и не толчком к соблюдению правил, а именно соблюдением правил. Поэтому аудит должен быть регулярным и сопряжённым с мониторингом системным процессом получения и оценки объективных данных о текущем состоянии информационной системы, действиях и событиях, происходящих внутри неё.

В свете этих ситуаций вернёмся к CobiT. В нём описаны цели, задачи и принципы управления, объекты управления, ИТ-процессы, инструменты работы с ИТ-инфраструктурой, а также вопросы ИТ-безопасности. Актуальную версию CobiT и статьи по нему можно почитать на сайте ISACA (есть платные и бесплатные материалы). CobiT можно определить как методологию корпоративного управления ИТ, которая:

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

Кроме того, CobiT соответствует стандартам ISO 9000 и ISO/IEC 17799, стандарту информационной безопасности и менеджмента ИБ. С помощью принципов CobiT можно минимизировать риски и контролировать отдачу инвестиций в ИТ. Что нам нравится в CobiT, так это то, что он хорошо структурирован и поле зрения этого свода правил попадают планирование, организация, приобретение, внедрение, эксплуатация и сопровождение, а также мониторинг и оценка пяти важнейших элементов каждой компании (согласно определения CobiT, ресурсов ИТ).

1. Данные - информация внутри компании в любом виде, медиафайлы, внешняя информация.
2. Приложения - множество автоматизированных и ручных процедур.
3. Технология - программное обеспечение, аппаратное обеспечение, СУБД, СУ сетями, ОС.
4. Оборудование - ресурсы, поддерживающие технологию.
5. Люди - персонал с навыками и умениями, в том числе контроля и мониторинга.

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

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

Так как же соотносятся CobiT и ITIL? ITIL - библиотека лучших практик предоставления услуг в сфере ИТ, а CobiT - больше по части управления и аудита ИТ. Соответственно, все процессы, описанные в ITIL, могут управляться и подвергаться аудиту стандартом CobiT.

DevOps

Связан с ITIL (в некоторых источниках считается прямым следствием), покрывается CobiT, но имеет совершенно другую парадигму подход к системному администрированию DevOps . Впрочем, сама расшифровка названия указывает на то, что это гибрид на стыке администрирования и разработки (development и operations). Методология DevOps соединяет в себе труд разработчиков и ИТ-инженеров (это могут быть сформированные команды, отдельные люди или даже один человек), тем самым обеспечивая быстрые темпы развёртывания, надёжность и безопасность production-среды (включая тестирование). Говоря проще, эта методология исключила распространённую фразу, ставшую мемом: «Проблема на стороне железа/софта».

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

Как методология DevOps даёт множество преимуществ, среди которых:

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

Как видите, DevOps не является подходом чисто к системному администрированию, соответственно, о его применении идёт речь, в основном, в компаниях-девелоперах.

Предупреждение о Visible Ops

Вы можете услышать термин Visible Ops. Он не имеет прямого отношения к DevOps, однако имеет отношение к ITIL, а именно - это книга (с развитием технологий превратившаяся в серию книг) Visible Ops Handbook, которая является отличным пошаговым руководством по использованию ITIL в компании. В книгах есть интересные практические примеры крупных корпораций. Первая, ставшая классикой книга, простым английским языком раскрывает проблемы ИТ в компании и цели изменений. В любом случае, хотя бы пролистать PDF-ку стоит.

Ок, моя компания не входит в топ-100 мира, что мне делать с этой информацией?

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

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

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

• Управление лицензиями ПО, проверка наличия свободных лицензий - одна из ощутимых статей экономии на ИТ-инфраструктуре. Установление профиля использования лицензий помогает скорректировать объём закупаемых или арендуемых продуктов, перераспределить ПО по реальным потребностям. Классический пример: отдел продаж из 7 человек, трое из которых постоянно «в полях», а ещё один - выгружает данные раз в месяц для анализа. В отделе семь лицензий CRM, а можно было бы обойтись пятью. Такая же история повторяется и в отделах логистики и дизайна, где установлено и нередко простаивает дорогостоящее ПО.
• Регламентированный порядок работы внутри ИТ-службы уменьшает количество сорванных сроков и нереализованных проектов.
• Понимание текущего среза аппаратного и программного обеспечения в компании позволяет обоснованно составлять бюджет на приобретение ИТ-активов, быстро и точно оценивать потребности компании в модернизации ИТ-инфраструктуры.
• Точное понимание особенностей организации ИТ-инфраструктуры помогает оптимизировать соотношение капитальных и операционных расходов. Например, делая выбор в пользу аренды ПО по модели SaaS или использования виртуальных вычислительных мощностей в облаке.

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

Описание COBIT 5 и его применение

Недостаточный обмен информацией

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

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

• взаимодействие с бизнесом;
• оценка рентабельности ИТ;
• эффективное управление ИТ бюджетом.

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

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

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

История COBIT началась в 1996 году, в это время ISACA, образованная в 1969 году выпустила первую версию методологии оценки ИТ. Дальнейшее развитие было в 1998 году - версия 2, в 2000-м - версия 3, в 2005-м году вышла версия 4. В 2007 году версия 4 была доработана и в 2007 году стала нести индекс 4.1. На сегодняшний момент аудиторы параллельно используют две версии 4.1 и 5, которая вышла в 2012 году, и только набирает обороты в профессиональной среде.

Сейчас COBIT имеет связь со множеством других стандартов и лучших практик, таких как ISO 20000, ISO 27000, ISO 38500, ISO 31000, ISO 9000, ITIL, PRINCE2, PMBOK, CMMI, TOGAF, Basel II и другие. При этом в большинстве случаев в тексте указаны ссылки на конкретные главы в источниках.

Многих интересует вопрос, в чем отличие COBIT 5 от предыдущей версии?

В первую очередь, это применение интеграционного подхода, который объединил в себе управление ИТ, которое было в версии 4.1, управление инвестициями в ИТ, которое было описано в Val IT 2.0, а также управление рисками ИТ.

Введена новая система оценки, основанная на ISO 15504 и не совместимая с CMM.

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

Основные изменения содержащиеся в COBIT 5:

1. Новые принципы руководства ИТ-предприятием (GEIT). COBIT 5 основан на пяти ключевых принципах руководства и управления корпоративными службами ИТ, которые в совокупности позволяют предприятиям выстроить эффективную систему руководства и управления, которая оптимизирует инвестиции в информацию и технологии и их использование в интересах заинтересованных сторон.
2. Повышенное внимание на системы обеспечения (enablers). В предыдущей версии не было прямого указания на обеспечение, хотя косвенно они присутствовали.
3. Появился новый домен и несколько новых и измененных моделей процессов.

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

1. COBIT 5 вводит пять новых процессов руководства (governance).
2. Практика и деятельность. COBIT 5 объединяет и обновляет все предыдущие методики, а именно COBIT 5, Val IT и Risk IT в одной новой модели, что делает её более удобной для пользователей при реализации улучшений
3. Пересмотрены и расширены цели и метрики. В COBIT 5 приводится пересмотренный каскад целей, основанный на целях бизнеса задающий ИТ-цели, связанные с поддержкой критически важных процессов.
4. Входы и выходы, предлагаемые в каждой практике управления процессом, в отличие от версии 4.1 где были только предложения на уровне процесса.
5. Расширенные RACI-чарты на уровне руководства практикой. В COBIT 4.1 RACI-чарты были только на уровне процесса. В COBIT 5 это на уровне руководства практикой.
6. Новый процесс оценки модели зрелости. COBIT 5 будет поддерживать новые возможности процесса оценки, основанные на ISO / IEC 15504, в качестве альтернативы подходу CMM. COBIT 4.1, Val IT и Risk брали за основу CMM-оценку которая считается не совместимой с ISO/IEC 15504 подходом, так как эти методики используют различные атрибуты и шкалы для измерений.

Итак, COBIT 5 состоит из следующих доменов:

Стоит обратить внимание, на то, как COBIT определяет понятия РУКОВОДСТВО и УПРАВЛЕНИЕ.

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

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

Сертификационная схема в COBIT5

Основные цели COBIT 5 в области ИТ:

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

COBIT позволит Вам:

1. Связать бизнес-цели с процессами реализованными в ИТ;
2. Произвести оценку текущих процессов управления ИТ;
3. Достаточно быстро получить целостную картину об ИТ процессах в компании и их взаимосвязях;
4. Использовать методику как источник лучших практик по организации ИТ процессов;
5. Установить необходимые метрики для оценки эффективности ИТ процессов;
6. На основе проведенных измерений определить вектор дальнейшего развития;
7. Организовать эффективные коммуникации с бизнесом.

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

Сейчас существует переведенная на русский язык книга COBIT 4.1, но уже идет работа по переводу и новой, пятой версии.