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

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

Опубликовано 31 января 2017
Рубрики: ITSM, Вопрос из зала, Всё это - ЛЮДИ, Обо всём на свете, Общие вопросы менеджмента, Управление инцидентами
Комментарии

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

Добрый день всем! У меня с нашим проблем-менеджером возник спор, кто же все-таки должен контролировать решение ИТ-проблем? Он утверждает, что инцидент-менеджер, он же инициатор проблемы, должен вести непрерывный контроль за решением проблемы, при необходимости "пинать" инженеров или 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
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.