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

Границы ответственности инцидент-менеджера

В редакцию портала поступил вопрос:

Добрый день всем! У меня с нашим проблем-менеджером возник спор, кто же все-таки должен контролировать решение ИТ-проблем? Он утверждает, что инцидент-менеджер, он же инициатор проблемы, должен вести непрерывный контроль за решением проблемы, при необходимости "пинать" инженеров или change-менеджемент, который решает проблему, так ли это? В моем понимании инцидент-менеджер безусловно является инициатором проблем, но далее он передает это на уровень проблем-менеджмента, и в его зоне остается лишь окончательная проверка и подтверждение устранения проблемы.

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Что в данном случае стоит за словом «контролировать»?

    Управлять (manage) детальностью в рамках процесса управления проблемами (PRB)? Для этого у процесса PRB есть роль менеджер процесса. И эти роли (менеджер PRB и менеджер INC) совмещать не рекомендуется (хотя, если я правильно помню, на портале есть активный участник, с опытом совмещения этих ролей 😉 ).

    В чём заключается контроль в контексте вопроса?

     

    • Андрей

      Контроль — это со слов нашего проблем менеджера, ты, как инициатор проблемы, заинтересован в ее скорейшем решении, значит ты должен следить за сроками ее решения, и при необходимости "пинать" ответсвенных за ее решение. Для меня ответственный за решение — проблем менеджер, я не могу и не должен знать какие ресурсы он привлекает для ее решения.

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

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

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

        • Андрей

          Игорь, спасибо за ваш подробный ответ. К сожалению у нас нет координатора проблем, а сервис менеджер и менеджер проблем в одном, единственном лице, судя по всему мне как рук-лю Сервис Деск и инцидент менеджеру и пытаются совместить роль координатора проблем.

  • Альберт

    Это уж как вы договоритесь.

    Вариант, как это может быть. Начнем с того что должны быть согласованные KPI для данного процесса которые должен разработать менеджер по управлению проблемами. Соблюдение KPI обеспечивают руководители групп, которые участвуют в процессе.

    Если вернуться к вопросу, то контролирует решение каждой проблемы в отдельности владелец этой проблемы, как правило владелец CI, привлекая для решения необходимые группы. Каждая группа, вовлеченная в процесс должна соблюдать установленные KPI.

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

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

    • Андрей

      Я вижу это процесс так, передав инцидент в проблем менеджмент, они назначают на него проблему, сами привлекают ресурсы, сами устанавливают сроки, по решению проблемы сообщают об этом инициатору проблемы. После инциатором проверяется решено\не решено. Не понимаю почему инициатор должен быть привлечен к ее решению.

  • Владимир

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

  • Андрей другой

    Задача процесса " Incident management" — максимально быстро восстановить сервис. Задача процесса "Problem management" — выяснить и по возможности устранить проблемы — причины возникновения инцидентов. По аналогии с медициной — "Incident management" — это скорая/реанимация, её задача максимально быстро вывести пациента из критического состояния. "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