COBIT®. Эволюция методов оценки системы управления
Поступательность в единстве с преемственностью составляет суть
диалектического развития.
Конспект лекций по философии
Если вы решили первым стать в рядах своих сограждан —
Никогда не догоняйте устремившихся вперёд.
Через пять минут, ругаясь, побегут они обратно,
И тогда, толпу возглавив, вы помчитесь впереди!
Григорий Остер
Зачем вообще нужна оценка системы управления ИТ?
Информационные технологии уверенно и незаметно покоряют мир. Информация нужна всем, новые возможности работы с информацией в любой форме дают потрясающие преимущества любому бизнесу. Но есть моменты, омрачающие его счастье. Например, информационные технологии весьма сложны и требуют квалифицированных специалистов. Много разных ИТ-специалистов. И ещё бизнес мучает страх того, что ИТ плохо управляется, а ИТ-специалисты идут не в ту сторону и при этом тратят деньги бизнеса. К тому же бизнес обычно не вникает ни в тонкости самих технологий, ни в тонкости управления этими технологиями. Тому могут быть разные причины, но они выходят за рамки данной статьи. Поэтому бизнес был бы очень рад, если бы был способ подтверждать в нём уверенность (assurance), что ИТ идёт верной дорогой, указанной бизнесом, и делает это оптимально и результативно. То есть нужна уверенность, что управление ИТ оптимально и система управления ИТ адекватна. Нужна оценка системы управления. Как это можно сделать? И вот здесь есть хорошая новость – у нас есть COBIT.
COBIT. История развития
COBIT (ранее аббревиатура от Control Objectives for Information and related Technology) создан Ассоциацией контроля и аудита информационных систем (Information Systems Audit and Control Association, ISACA) в 1996 году.
Начинал свой путь как инструмент аудита и контроля, но вырос в универсальную модель (см. рис. 1), способную помочь не только в оценке подразделений ИТ, но и в построении системы руководства информацией и информационными технологиями, адекватной поставленным руководством организации целям.
В данной статье мы не претендуем на полное описание всех блестящих моделей и идей COBIT, а коснёмся только вопроса оценки системы управления ИТ, а если идти на поводу COBIT 2019, то системы руководства и управления I&T (информацией и информационными технологиями). Но для простоты и совместимости далее я буду использовать термин «система управления ИТ».
Рис. 1. Эволюция COBIT
Согласно COBIT последних версий цель любой организации – создание ценности для заинтересованных сторон. Заинтересованными сторонами являются все люди, заинтересованные в работе организации, от владельцев до рядовых сотрудников самой организации и ряда внешних персонажей, значимых для работы организации. Создание ценности подразумевает получение выгод как в материальном, так и в нематериальном выражении при оптимальной стоимости ресурсов с одновременной оптимизацией рисков. Потребности заинтересованных сторон, в первую очередь руководства организации, на которые влияют внешние и внутренние причины (движущие силы), приводят к пониманию целей организации, которые необходимо достичь.
COBIT. Оценка на основе каскада целей
Если система управления ИТ позволяет достичь целей организации – она адекватна ситуации, если нет – её надо совершенствовать. Модели COBIT определяют конечное количество целей как всей организации, так и ИТ, и предлагают каскад целей. В частности, для COBIT 5 количество целей организации – 17, целей, связанных с ИТ – тоже 17. При этом все цели определяются на основе сбалансированной системы показателей (balanced scorecard) по четырём перспективам: финансовой, клиентской, внутренней организации, обучения и роста.
Каскад целей в COBIT 5 выглядит следующим образом (см. рис. 2).
Рис. 2. Каскад целей в COBIT 5
Итак, стратегические цели бизнеса выполняются, если достигаются связанные с ними ИТ-цели и связанные с этими ИТ-целями цели процессов и других факторов влияния.
COBIT. Оценка на основе процессов
В более ранних версиях COBIT оценка системы управления проводилась исключительно как оценка некоторой совокупности взаимосвязанных процессов, необходимых для достижения целей ИТ и, следовательно, целей организации. Был только один оцениваемый фактор – процесс. COBIT 5 в этом смысле являлся возмутителем спокойствия и попытался идти дальше, но не все обратили на это внимание.
Вся деятельность, связанная с ИТ, описана в COBIT в виде взаимосвязанных между собой процессов. Все процессы сгруппированы по доменам, количество доменов и процессов для разных версий COBIT различно. Домены отражают разные области управления, включая задание направления, планирование, построение, внедрение, эксплуатацию, мониторинг, анализ и совершенствование. Например, процессная модель (process reference model) COBIT 5 описывает 37 процессов в 5 доменах (см. рис. 3).
Рис. 3. COBIT 5 Process Reference Model
В ходе предварительной оценки, опираясь на каскад целей, выделяется некий набор процессов, каждый из которых подлежит дальнейшей более детальной оценке по какой-либо методике.
Оценка процесса управления
Каковы же основные подходы к оценке процесса?
Сначала обратимся к определению процесса, чтобы понять, что он из себя представляет. Существует много определений процесса, я приведу наиболее подходящий для нашего случая.
Процесс (process) – это набор координированных действий (с определением исполнителей), объединяющих и применяющих ресурсы и способности с целью достижения результата, который прямо или косвенно помогает достичь целей заинтересованным лицам. Входные данные процесса в ходе действий преобразуются в выходные данные.
Сам по себе процесс – чертовски сложная вещь, и одна из задач при его оценке – разложить его на значимые составные части. Конечно, эти части будут тесно связаны друг с другом, и, оценивая одну из частей, мы невольно затронем и другую составную часть. Итак, давайте попытаемся это сделать.
Справка. Методики оценки процесса, которые применял и применяет COBIT
В истории COBIT для детальной оценки каждого отдельно взятого процесса применялись две методики, не совместимые друг с другом:
- на основе моделей CMMI (версий 1.3 и 2);
- на основе стандарта ISO/IEC 15504 (сейчас стандарт ISO/IEC 33000).
В COBIT 4.1 для оценки использовалась адаптированная COBIT модель CMMI версии 1.3 (Capability Maturity Model Integration), предложенная SEI (Software Engineering Institute), в COBIT 5 был сделан крутой поворот к опять же адаптированной COBIT модели ISO/IEC 15504, в COBIT 2019 объявлена вольница – каждый может использовать ту модель, которую считает для себя наиболее подходящей. Хотите – используйте модель оценки на базе ISO/IEC 33000, хотите модель на базе CMMI версии 2.0.
Начнём с целей. Чем сложнее достичь целей, тем бОльшие требования предъявляются к процессу. Это как в сказке о рыбаке и рыбке. Золотой рыбке. Сначала мы требуем, чтобы цели хоть бы как-то достигались. Здесь полезно ещё добавить: и чтобы не нарушались регламенты и Уголовный кодекс 😀 Добившись этого, мы хотим, чтобы цели достигались стабильно. Добившись этого, мы хотим, чтобы цели достигались стабильно и рациональным образом. Добившись этого, мы хотим всего, что было раньше, но ещё и при изменяющихся условиях, то есть чтобы всё совершенствовалось и оптимизировалось согласно этим изменениям, чтобы всё равно с гарантией достичь цели. Данная логика приводит нас к мысли, что в ходе оценки процесс может оказаться на разных уровнях наших требований по целям, то есть иметь разные уровни зрелости (или уровни возможностей).
В качестве примера рассмотрим уровни возможностей, используемые в модели оценки COBIT 5:
| 0. Неполный | Процесс ещё не внедрён или не способен соответствовать своему назначению. На этом уровне отсутствуют свидетельства систематического достижения процессом своих целей или таких свидетельств мало. |
| 1. Осуществлённый |
Процесс внедрён и соответствует своему назначению. В прошлом процесс достигал поставленных целей, но нет гарантий, что он сможет достичь их полностью и рационально в будущем. |
| 2. Управляемый | Осуществлённый процесс предыдущего уровня теперь управляем (то есть планируется, отслеживается и корректируется). Создаются, контролируются и поддерживаются рабочие продукты процесса. |
| 3. Установленный | Управляемый процесс теперь способен получать ожидаемые результаты. Процесс выполняется одинаково по всей организации в соответствии с общими правилами. |
| 4. Предсказуемый | Установленный процесс теперь получает результаты в условиях заданных ограничений. Существует возможность предсказать объём достижения целей процесса в заданных ограничениях. |
| 5. Оптимизируемый | Предсказуемый процесс теперь постоянно совершенствуется, чтобы достигать текущих и будущих целей организации. |
Теперь о заинтересованных лицах. Одни из заинтересованных лиц определяют цели, владеют ресурсами (заказчики, владельцы бюджета), другие – устанавливают ограничения, в рамках которых будет работать процесс (по рискам, требованиям регуляторов или по собственной прихоти 😀, но ни те, ни другие не участвуют в работе процесса, третьи же – непосредственно участвуют в самом процессе (исполнители), пытаясь достичь требуемых первыми результатов и отвечая за это. Возможны и другие варианты вовлечённости заинтересованных лиц.
Очевидно, что для верной оценки нам нужно определить значимых заинтересованных лиц, их цели, ответственность и полномочия в рамках процесса. Здесь очень помогает формирование матрицы распределения ролей и ответственности, например, диаграммы RACI, в которой определяются следующие роли:
- Responsible (ответственный) – исполнитель работы.
- Accountable (подотчётный) – единственный подотчётный/ответственный за итог работы.
- Consulted (консультирующий) – предоставляющий консультацию.
- Informed (информированный) – информируемый о ходе работы.
Действия (практики), выполняемые в процессе, часто тесно связаны с исполнителями. Начнём с анализа оценки действий или практик. Лучшие практики в COBIT определяются на основе практик организаций, которые успешно достигают своих целей. Тут есть некоторые нюансы, на которых нужно остановиться поподробнее.
Тупо копировать практики без анализа их применимости к вашим конкретным условиям неправильно, поэтому в COBIT последних версий явно указано, что процессные модели являются «reference» – рекомендуемыми. То есть при конкретной оценке процесса нужность тех или иных практик в процессе может зависеть от уровня требований к возможностям процесса и должна быть подвергнута анализу.
Важно также отметить, что практики, как, впрочем, и другие рассматриваемые нами части процесса, могут быть универсальными, то есть быть применимыми ко всем процессам, а могут быть и уникальными. Это важно для создания более целостной и структурированной системы оценки процессов. Например, практика регистрации инцидента уникальна для процесса управления инцидентами, а практика назначения владельца процесса универсальна для всех процессов.
Кроме того, все практики процесса могут также разделяться на практики планирования (организации), практики текущей деятельности и практики контроля и совершенствования. Эти практики отражают жизненный цикл процесса, и такая классификация позволяет провести оценку всесторонне, выявить отклонения на самом раннем этапе. Здесь также нужно отметить, что чем выше уровень требований (уровень ожидаемых возможностей) к процессу, тем более обязательны для процесса практики планирования, контроля и совершенствования.
Исполнители нам интересны и как ресурсы, и как способности. С точки зрения ресурсов оценивается оптимальность количества исполнителей, с точки зрения способности оцениваются их знания, умения и навыки. Также необходимо оценивать коммуникации и слаженность работы исполнителей.
Ресурсы также часто включают в себя управляющие системы, средства мониторинга и контроля, которые нужно оценить на предмет адекватности их функционала, настройки и дружественного интерфейса, а также оценить другие качества, необходимые для работы исполнителей.
Информация, используемая в процессе, также относится к ресурсам, необходимым для выполнения практик. Здесь нужно разделить информацию, входящую в процесс (входные данные), информацию, формируемую и/или используемую внутри процесса, и выходную информацию (выходные данные). Информация в процессе также может разделяться на разные виды, например, ISO 15504 выделяет 3 вида информации (называя их термином «рабочие продукты»):
- политики (правила игры);
- планы (документированные намерения);
- записи (свидетельства о выполнении намерений).
Эта информация может быть выходом одного процесса и одновременно входом для других процессов. Количество и содержание входов и выходов каждого процесса уникальны и тесно связаны с практиками.
Справка. Краткая характеристика оценки процесса в разных версиях COBIT
1. COBIT 4.1
В СOBIT 4.1 на основе модели CMMI оценивается уровень зрелости каждого процесса. Модель зрелости – способ измерения того, насколько хорошо развиты процессы управления, т. е. какими возможностями они фактически обладают.
Модель оценки определяет несколько уровней зрелости:
Уровень 0: Несуществующий – полное отсутствие каких-либо заметных процессов.
Уровень 1: Начальный/повторяющийся эпизодически – нет никаких стандартизированных процессов, однако существуют подходы, применяемые в отдельных случаях.
Уровень 2: Повторяющийся, но интуитивный – процессы достигли уровня, при котором разные сотрудники, выполняющие одну и ту же задачу, используют сходные процедуры, ответственность за используемые процедуры целиком лежит на сотрудниках.
Уровень 3: Определённый – процедуры стандартизированы, документально оформлены, и существуют требования следовать формально описанному процессу, однако маловероятно, что отклонения будут обнаружены.
Уровень 4: Управляемый и измеряемый – существует возможность контроля и оценки степени соответствия принятым процедурам, а также возможность принятия мер в случае, если процессы неэффективны.
Уровень 5: Оптимизированный – процессы оптимизированы до уровня лучших практик, базируются на результатах непрерывного совершенствования и сравнений с другими организациями.
По каждому уровню зрелости каждого процесса COBIT есть определённый набор требований. Оценка зрелости процесса является результатом определения профиля процесса, где в той или иной степени присутствуют требования всех уровней.
2. COBIT 5
В COBIT 5 на основе модели стандарта ISO/IEC 15504 (ISO/IEC 33000) проводится оценка возможностей процесса. В модели также есть несколько уровней возможностей от 0 до 5. Описание этих уровней мы рассмотрели выше в этой статье. Возможность процесса определяется как способность процесса соответствовать текущим и будущим целям организации. Оценка процесса измеряет степень, в которой соответствующий процесс соответствует специфичным атрибутам. Каждому уровню соответствуют определённые атрибуты процесса (кроме 0). COBIT 5 определяет 9 атрибутов процесса:
PA 1.1 – осуществление процесса;
PA 2.1 – управление производительностью;
PA 2.2 – управление рабочими продуктами;
PA 3.1 – определение процесса;
PA 3.2 – внедрение процесса;
PA 4.1 – измерение процесса;
PA 4.2 – контроль процесса;
PA 5.1 – инновации процесса;
PA 5.2 – оптимизация процесса.
Как видно из цифрового кода атрибутов, уровню 1 соответствует один атрибут, остальным уровням – по два атрибута каждому. И для достижения каждого атрибута определён ряд конкретных требований, которых много, и они детально описаны. В общем, всё непросто.
3. COBIT 2019
COBIT 2019 поддерживает схему возможностей процесса на основе CMMI 2.0. Упор делается на оценку производительности процесса. В модели также определяется несколько уровней возможностей. Уровень возможностей – это показатель того, насколько хорошо процесс реализован и работает. Уровень зрелости определяется на уровне выше, чем уровень отдельного процесса. COBIT 2019 определяет уровни зрелости как показатель эффективности на уровне области фокуса, который определяется как определённые предмет, домен или проблема. Определённый уровень зрелости области фокуса достигается, если все процессы и связанные с ними компоненты области фокуса достигают конкретного уровня возможностей.
Многофакторная оценка системы управления в COBIT
Как уже упоминалось ранее, в COBIT 5 для достижения целей организации необходимо достижение целей набора взаимосвязанных факторов влияния (enablers). В свою очередь, COBIT 2019 говорит о том, что для достижения целей руководства и управления каждой организации необходимо создать, адаптировать и поддерживать систему руководства, состоящую из компонентов (components), а компоненты – это факторы, которые индивидуально и коллективно способствуют эффективному функционированию системы управления. Следовательно, оценка системы управления должна включать в себя оценку всех значимых факторов, а не только процессы.
Факторы (влияния согласно COBIT 5, и они же компоненты согласно COBIT 2019), включают в себя:
- Уже разобранные ранее процессы.
- Принципы, политики и подходы – обеспечивают трансляцию желаемого поведения в практические рекомендации по оперативному управлению организацией.
- Организационная структура – важнейшая сущность для принятия решений в организации.
- Культура, этика и поведение.
- Персонал, его навыки и компетенции.
- Информация – включает в себя всю информацию, производимую и используемую в организации.
- Услуги, инфраструктура и приложения – инструменты, необходимые для управления.
Каковы же возможные преимущества оценки этих компонентов?
- Факторы дают возможность более целостной и разносторонней оценки всей системы управления.
- Оценка через взаимосвязанные факторы повышает рациональность самой оценки.
- Факторы можно оценивать целостно и глубоко в рамках их жизненного цикла.
- С моей точки зрения, в факторах COBIT совершенно справедливо упор делается на оценку людей в процессах, а не только процессных практик – как минимум пять из семи факторов помогают провести более глубокую оценку персонала.
- Новым словом является возможность детальной оценки информации, ведь часто не только её отсутствие, но и, например, неверная форма или уровень изложения приводят к неадекватному управлению и повышают риски не достижения цели.
Оценка системы управления на основе многофакторной модели COBIT 5
Модель оценки процессов описана в книге COBIT Process Assessment Model (PAM): Using COBIT 5. Оценка на основе факторов влияния изложена в книге COBIT 5 for Assurance и опирается на универсальную модель фактора влияния.
Согласно универсальной модели фактора влияния COBIT 5, существует четыре общих атрибута для каждого фактора влияния:
- заинтересованные стороны;
- цели;
- жизненный цикл;
- общепринятые (хорошие) практики.
Заинтересованные стороны. У каждого фактора влияния есть заинтересованные стороны (те, кто играет активную роль в работе фактора, либо заинтересован в нём).
Цели. У каждого фактора влияния есть набор целей. Достигая этих целей, факторы влияния создают ценность. Цели детализируются по категориям:
- Присущее (прямое) качество – степень точности, объективности и надёжности результатов работы фактора влияния.
- Контекстуальное (опосредованное) качество – степень соответствия факторов влияния и результатов их работы назначению, учитывающая контекст их работы.
- Доступность и безопасность – степень доступности и безопасности факторов влияния и результатов их работы.
Жизненный цикл. Включает в себя все этапы жизненного цикла.
Хорошие (общепринятые) практики. Для каждого фактора влияния можно определить хорошие практики. Они поддерживают достижение целей факторов влияния. Хорошие практики предлагают примеры или предложения того, как наилучшим образом реализовать фактор влияния и какие результаты, а также какие рабочие продукты фактора (входы и выходы) необходимы.
Общая схема фактора влияния приведена на рис. 4.
Рис. 4. Общая схема фактора влияния
В книге COBIT 5 for Assurance даются примеры оценки на основе факторов, в ходе анализа которых можно отметить следующие моменты:
- Оценка получается весьма сложной и масштабной, нужно верно выбирать охват и уровень детализации оценки по каждому фактору. В COBIT 5 это вопрос хорошей компетентности оценщиков. Какой-либо методики, облегчающей жизнь оценщику, не приводится.
- Также объём и детализация областей оценки может изменяться в ходе самой оценки, решение о правомочности этих изменений необходимо принимать на основе рисков и в ходе всестороннего обсуждения со всеми заинтересованными в оценке лицами.
- Не все атрибуты факторов влияния имеют смысл в конкретных ситуациях.
- В ходе оценки одного фактора может выясниться, что данная область уже была оценена в ходе более ранней оценки другого фактора – в таких ситуациях необходимо будет принимать решение, нужна ли ещё одна проверка.
Тем не менее, несмотря на все эти трудности, подобная оценка получается глубокой и всесторонней, дающей более детальное представление об оцениваемом предмете.
Развитие многофакторной модели оценки в COBIT 2019
В COBIT 2019 есть ряд волшебных изменений, важных для проведения оценки системы управления.
Каскад целей в COBIT 2019 приводит к необходимости решения некоторого количества задач (objectives) руководства и управления. Не достижение целей разных факторов влияния, как в COBIT 5, а решение задач, для которого, в свою очередь, нужны процессы и другие компоненты. Вот так. Просто и логично. Компоненты системы управления, в том числе процессы, консолидированы через задачи, процессная модель выглядит как базовая модель задач, и все компоненты включены в эту базовую модель.
В COBIT 2019 определены факторы дизайна системы руководства и управления, позволяющие:
- Более чётко выявить приоритеты решения задач и установить более высокие целевые уровни возможностей для этих задач. Причём в COBIT 2019 даётся конкретный перечень этих факторов и даются детальные и оцифрованные методики зависимости приоритетов решений от факторов.
- Влиять на вариативность компонентов: факторы проектирования могут обусловливать конкретные вариации компонентов или влиять на их важность.
- Делать акцент на конкретной области фокуса, изменяя базовую модель COBIT 2019 для конкретных областей: провести адаптацию процессов для DevOps или адаптацию всей системы управления для малых и средних предприятий.
Хотелось бы также отметить, что COBIT 2019 не совсем привержен универсальной модели фактора влияния COBIT 5 и вообще даёт вольную на выбор системы оценок каждого компонента, хотя и отмечает заслуги COBIT 5 в оценке информации.
Что касается оценки процессов, то, как уже отмечалось ранее, в COBIT 5 была сделана попытка крутого поворота к оценке процессов по модели стандарта ISO/IEC 15504, что должно было привести к общему процветанию через формализацию и уменьшение волюнтаризма оценщиков, но COBIT 2019, вероятно, по многочисленным просьбам трудящихся, отягощённых слишком высокими требованиями к такой оценке, вновь (ура!) вернулся к модели оценки на базе CMMI – правда, уже по версии 2.0. Хотя и не возражает против оценки по предыдущему стандарту. В общем, победила дружба.
Оценка системы управления в COBIT – что же дальше?
К сожалению, при знакомстве с COBIT 2019 в области оценки явно складывается впечатление недосказанности, что подтверждается ссылками в книгах самого COBIT 2019 на ещё не написанные книги по оценке. И хотя авторы предупредили, что отдельных книг по оценке в COBIT 2019 не планируется, хотелось бы подробностей. Так пожелаем же авторам COBIT написать эти книги и облегчить нам трудную задачу проведения оценки системы управления ИТ.
Владимир Аношин,
ITIL Expert
ITIL 4 Managing Professional
Ведущий тренер
