Портал №1 по управлению цифровыми
и информационными технологиями

Управление проблемами в COBIT 5

Опубликовано 10 мая 2018
Рубрики: COBIT, Управление проблемами
Комментарии

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

На страницах портала («Определяем сроки обработки проблем», «Измеряем Problem Management» и др.) и на вебинарах («Управление проблемами – где взять проблемы», «Этапы и сроки обработки проблем») мои коллеги разбирали нюансы Problem Management.

Дополню раскрытие темы «Управление проблемами» через призму COBIT 5, ответив на ряд вопросов: «Что делать?», «Зачем?», «Как?», «Кто?», «Когда?», «Что измерять?».

ЧТО ДЕЛАТЬ?

В Cobit 5 Enabler Processes (процессная модель) процесс управления проблемами входит в домен DSS («Deliver, Service and Support») — Предоставление обслуживание и поддержка (см. Место процесса управления проблемами в эталонной модели процессов COBIT 5), — и отвечает за «выявление и классификацию проблем, причин их возникновения и обеспечение своевременного разрешения в целях предотвращения их повторного возникновения, а также предоставление рекомендаций по возможным улучшениям». Цель процесса – «ИТ-проблемы разрешаются способом, исключающим их повторное возникновение».

ЗАЧЕМ?

«Философия» COBIT 5, описанная во Framework (бизнес-модель можно скачать бесплатно здесь; требуется предварительная регистрация; официальный перевод на русский язык), предполагает, что любые активности направлены так или иначе на повышение ценности ИТ для бизнеса через получение выгод, оптимизацию рисков и оптимизацию ресурсов. Создание ценности формируется через каскадирование целей (см. Обзор каскада целей). Достижение ИТ-целей обеспечивается семью факторами влияния, один из которых — Enabler Processes. Каждый процесс из пула 37 процессов процессной модели позволяет вносить свой вклад в достижении целей руководства.

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

  • №04. Управляемые бизнес-риски, связанные с использованием ИТ
  • №07. Предоставление ИТ-услуг в соответствии с требованиями бизнеса
  • №11. Оптимизация ИТ-активов, ресурсов и возможностей
  • №14. Доступность надежной и полезной информации для принятия решений

КАК?

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

  • DSS 03.01. Выявление и классификация проблем
    Определение и введение критериев и процедур предоставления отчетности по выявленным проблемам, включая классификацию проблемы, отнесение ее к определенной категории и присвоенный приоритет
  • DSS 03.02. Расследование и диагностика проблем
    Проведение расследования и диагностики проблем с привлечением соответствующих специализированных экспертов для оценки и анализа причин
  • DSS 03.03. Привлечение внимания к известным ошибкам
    Как только будут определены причины проблем, производится создание учетных данных по известным ошибкам и готовится соответствующее временное решение, а также выработка потенциальных постоянных решений
  • DSS 03.04. Разрешение и закрытие проблем
    Выявление и инициирование создания устойчивых решений, позволяющих устранить причины проблем на основе создания запросов на изменения через установленный процесс управления изменениями, если это необходимо, для устранения ошибок. Обеспечение того, чтобы персонал, затрагиваемый проблемами, был осведомлен о принимаемых мерах и разработанных планах с целью предотвращения возникновения инцидентов в будущем
  • DSS 03.05. Проведение упредительного управления проблемами
    Сбор и анализ операционных данных (особенно учетных данных по инциденту и изменениям) с целью выявления появляющихся тенденций, которые могут указывать на наличие проблем. Включение учетных данных по проблемам в журнал, обеспечивающее возможность проводить оценку

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

КТО?

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

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

КОГДА?

Cobit 5 Enabler Processes в явном виде не дает ответа на вопрос — в какие сроки выполнять те или иные активности. Во многом это зависит от контекста деятельности предприятия, уровня риск-аппетита и других факторов. Важно, чтобы сроки разрешения проблем были определены и соблюдались.

Опыт Cleverics (см. вебинар Романа Журавлева) предлагает устанавливать сроки в зависимости от этапа жизненного цикла проблемы (см. Назначение сроков обработки проблем).

На сроки разрешения проблем можно посмотреть с позиции управления рисками. По мнению ИТ-скептика, «… проблемы – это риски, которые не были предотвращены и реализовались». При управлении проблемами через механизмы управления рисками сроки «зашиваются» в конкретные корректирующие и предупреждающие мероприятия по риску (группу рисков). Более подробно по управлению рисками в COBIT 5 – «COBIT 5 for Risk: основные области ИТ рисков»

ЧТО ИЗМЕРЯТЬ?

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

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

Предлагаемые авторами COBIT 5 метрики – не догма, а информация к размышлению – что и как можно измерять. С примерами метрик по управлению проблемами от Роба Ингланда можно ознакомиться в заметке Метрики управления проблемами от ИТ-скептика. Опыт Cleverics по измерению, в частности, — метрики по управлению проблемами, можно почерпнуть из книги Д. Исайченко, Р. Журавлева «Руководство по измерению».

 

Таким образом, COBIT 5 на верхнем уровне дает представление о том, зачем и как управлять проблемами, почему это важно с точки зрения предоставления ценности заинтересованным лицам и повышения удовлетворенности клиентов. Детали выстраивания процесса управления проблемами, авторы предлагают искать в ISO/IEC 20000. 8.3. Problem Management и ITIL V3 2011. 22. Problem Management.

А как вы управляете проблемами: какие лучшие практики используете, какие трудности испытываете и как их преодолеваете?!

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT