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

Этапы и сроки обработки проблем

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

  • Тщательное и правильное планирование
  • Проектирование на основе планов
  • Разработка и приобретение компонентов
  • Внедрение компонентов в эксплуатационную среду
  • Правильная эксплуатация, потребление и поддержка услуг

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

 

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

Управление проблемами направлено на выявление, анализ и контроль ошибок, чтобы минимизировать их влияние на услуги. Основные этапы управления проблемами, для которых важно установление сроков, будут подробно рассмотрены на нашем вебинаре “Этапы и сроки обработки проблем” на YouTube и Rutube канале.

Планируйте свое обучение

Этот вебинар станет полезным дополнением к нашему курсу “ITSM. Основы управления услугами” и “VAP: Управление поддержкой ИТ-услуг”. На вебинаре рассматривается системный подход к управлению проблемами, подчеркивая важность установления четких сроков на каждом этапе для обеспечения стабильности и надежности IT-услуг.

Планируйте свое обучение для карьеры в IT, а мы в Cleverics поможем вам стать профессионалом в ITSM.

 

Комментариев: 2

  • Андрей

    Все хорошо, но!
    Самый первый шаг – “индентификация проблемы” на мой субъективный взгляд требует более детального пояснения. С “проактивным” управлением все более или менее хорошо – за вас уже кто-то идентифицировал проблему, вам сообщил и вам лишь остается выполнить дальнейшие шаги. А вот с реактивным есть вопросы. ЧТо и как надо делать, чтобы :
    1. выяснить что у вас в инфраструктуре есть ошибка/проблема (кстати, она может быть не только в конфигурации, но и в реализации процессов)
    2. Если выяснили, что ошибка/проблема есть, то надо максимально ее локализовать. Понять где она, а уже после этого регистрировать и далее по списку
    Без этого все дальнейшие шаги не имеют смысла.
    По 1 пункту хочу заметить, что само по себе наличие инцидентов вовсе не означает что у вас есть проблемы. Т.е. исходя из определения:
    “Проблема – дефект или иная причина возникновения одного или нескольких инцидентов.” следует, что ошибка/проблема проявляется через инциденты, но это вовсе не значит что любой инцидент – следствие ошибки/проблемы.

    • Добрый день, Андрей! Спасибо за Ваш комментарий и интерес к данной теме! Вы совершенно правы, в управлении проблемами важно сначала идентифицировать проблему.
      Я немного дополню и уточню Вашу мысль.
      Практика управления проблемами состоит из трех процессов:
      идентификации проблемы (проактивной и реактивной), контроля проблемы и контроля ошибки. По сути это фазы обработки проблемы. Как видим, первый процесс как раз идентификация.
      Реактивная идентификация проблемы использует информацию о прошлых и текущих инцидентах для изучения их причин. Она может быть инициирована текущим расследованием инцидента, которое не смогло определить его природу; в этом случае идентификация и контроль проблемы могут быть срочными. Практики управления инцидентами и управления проблемами используются в рамках одного потока создания ценности и, скорее всего, предполагают использование одних и тех же (или пересекающихся) ресурсов, включая команды, инструменты и процедуры.
      Если идентификация проблемы основана на анализе прошлых инцидентов, она может включать статистический анализ, анализ влияния и анализ тенденций с различных точек зрения. Цель – выявить группы инцидентов с возможными общими причинами и значительным общим влиянием на бизнес.
      Теперь по Вашим пунктам:
      1. Некоторые проблемы (первопричины инцидентов) возникают за пределами технических доменов и могут быть связаны с другими аспектами управления услугами.
      Не каждая проблема проходит все три фазы. Некоторые из них могут быть отклонены на фазе идентификации (как дубликаты или из-за низкого влияния на продукты и услуги).
      Ваш второй пункт как раз про вторую фазу (Контроль проблемы). Зарегистрированные проблемы принимаются к анализу на основе их первоначальной категоризации, влияния на бизнес и срочности. Локализация и расследование проблемы происходят именно на этой фазе. Но к этому моменту она должна быть зарегистрирована, чтобы с ней работать.

      Согласно определению ITIL4 “Проблема – причина или потенциальная причина одного или нескольких инцидентов.” Из этого следует, что у любого инцидента есть какая-то причина. Инцидент – это следствие, а причина – это проблема (см. определение).

      Приглашаю обсудить данную тему в рамках нашего курса “VAP: Управление поддержкой ИТ-услуг”. Уверен, что мы сможем прояснить и разобрать все тонкости деятельности по управлению проблемами, а также “подводные камни” с этим связанные. Ну, а хорошим дополнением к курсу будут наши статьи по данной теме на данном портале и ролики на нашем YouTube и RuTube канале.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM