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

Who is incident manager?

Опубликовано 19 августа 2012
Рубрики: ITIL, ITSM, Service Desk, Всё это - ЛЮДИ, Управление инцидентами
Комментарии

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

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

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

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

Что более всего интересно в такой схеме – кто тогда будет менеджером процесса управления проблемами? 😉

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Александр

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

    • Дмитрий Исайченко

      Честно говоря, скорее напрашивается вопрос о совмещении судьи и присяжного, а также следователя и прокурора 🙂
      Но поясните, пжл, как это всё связано с нашим вопросом про инцидент-менеджера? Кого с кем надо / не надо совмещать?

  • Александр

    Руководитель первой линии “лицо процессуально независимое”. Если некого больше назначить – то его. А иначе встречный вопрос, а почему к примеру не руководителя админов или вообще каких нибудь безопасников. Если на должность менеджера назначить кого-то из профильных специалистов то резко повышается риск сбагривания неудобных заявок от себя подальше. Ну а далее как в анекдоте – “у вас неправильная память, поэтому она неправильно исполняет наш код”. Идеальный вариант – выделенный менеджер, конечно, но на безрыбье и командир первой линии сгодиться. Все остальные слишком заинтересованы.

    • Дмитрий Исайченко

      “Все остальные слишком заинтересованы”

      Да, критика принимается. Тут, конечно, всё зависит от конкретного персонажа. На моей памяти были такие руководители, которых менеджером процесса я бы ни за что не назначил. Но были и прекрасные inc-менеджеры именно в руководстве профильных отделов.

      Но есть и контраргументы. Дело в том, что если следовать принципу segregation of duities, то все процессные менеджеры будут вдалеке от предметной компетенции, что также приносит свои риски. На самом деле, мне кажется более важным SoD в таких процессах, как prb и chg. inc в данном случае попроще, поскольку это большой поток и триггер вне ИТ. То есть и просто игнорировать его не получится, и “сбагривать”, как Вы пишете, при большом потоке – это отдельная работа (это совсем не то же самое, что “слить” 1-2 изменения в неделю).

  • Андрей

    А не правильнее тогда руководителя отдела сопровождения прикладных систем сделать владельцем процесса ведь он ЗАИНТЕРЕСЛОВАН в “организации сквозного процесса”?
    В этом случае начальника SD можно оставить менеджером процесса.

  • Pavel Solopov

    Я к Вам, Дмитрий, опять с мантрой из предыдущего обсуждения: Вся беда в том, что пытаются натянуть новую парадигму на старую структуру. 🙂

    Из моей практики, разделение на линии разграничивалось лишь декларациями. Реально линии поддержки не создавались. Линии назначались на разные отделы, как вы пишите, что в корне не верно.
    первой линией объявляются отделы поддержки пользователей, которые на самом деле занимаются всеми вопросами связанными с ПК, рабочими местами и общим ПО. Но реально задачи они решают задачи и более высоких линий. Выдвигаются на место и чинят на местах, разбираются в сложных проблемах с общим ПО, разбираются проблемами в железе и т.д.
    В то же время какой-либо отдел поддержки прикладных систем объявляется второй линией, хотя часто они решают задачи первой – консультируя пользователей, какую кнопку нажать, чтобы выгрузить отчёт в системе ХХХ.

    В идеале же, чтобы получить действительно оптимизацию деятельности надо создавать реальную первую линию, которая будет брать на себя вопросы из всех возможных областей, надо организовать процесс передачи знаний от вторых линий к первой, надо организовать механизм непрерывной консультации (в смысле с переключением на специалиста более высокой квалификации, если это возможно).
    А для этого нужно подумать либо о добавлении новой оргструктуры, либо о введении матричной схемы управления. ведь почему часто назначают менеджером процессов начальника отдела – чтобы не заморачиваться с введением принципов матричного управления. Он как начальник отдела руководит сотрудниками SD по оргструктуре, он же как руководитель процесса руководит SD по процессной модели. И никакой головной боли.

    • Дмитрий Исайченко

      В идеале же, чтобы получить действительно оптимизацию деятельности надо создавать реальную первую линию”…

      Павел, так ведь это всё делается во вполне себе реальных проектах. Вы почему об этом пишете, как о какой-то новой, системной альтернативе тёмному прошлому? 🙂

      • Pavel Solopov

        Из вашего поста я этого, Дим, не увидел. Я увидел как раз обратное: “первая линия относительно редко бывает достаточно компетентной, чтобы оказывать полноценную начальную поддержку по прикладному ПО”
        А она почему не компетентна, потому что просто ярлык “первая линия” повесили на один из отделов, иллюзорно более близкий к пользователям.

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

        • Дмитрий Исайченко

          Просто эти мероприятия дают эффект не мгновенно. Уж точно позже, чем назначен менеджер процесса.

          • Pavel Solopov

            Под “эти” Вы какие мероприятия имеете в виду?

            • Дмитрий Исайченко

              “…надо создавать реальную первую линию, которая будет брать на себя вопросы из всех возможных областей, надо организовать процесс передачи знаний от вторых линий к первой, надо организовать механизм непрерывной консультации…”

          • Pavel Solopov

            Что-то я, видимо, туго соображаю сегодня, но что-то я не пойму причём тут эффекты.
            Я говорю о том, что зачастую процессный подход только декларируется, а на самом деле подход остаётся прежним функциональным или скорее “оргструктурным”.
            И роли назначаются не по принципу участия в процессе, а по принципу принадлежности к какому-то подразделению.

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

  • Grigory Kornilov

    Можно рассуждать так:
    Целью является качество процесса.
    Для этого определены KPI.
    Для достижения KPI процесса кто-то ответственнен (обязан контролировать\требовать\оценивать достижение показателей по KPI).

    На практике этот ответственный может быть:
    1. Руководителем тех сотрудников IT, кто в большей степени влияет на достижение KPI.
    2. Сотрудником подразделения качества, который аля третейский судья. Прямого подчинения нет, но и вроде объективности больше.

    Какие KPI обычно есть и считаются важными на практике?
    Время назначения заявки на админа, который компетентен и в состоянии ее решить.
    Количество заявок решенных на 1-й линии (дешевле ресурс, быстрее решение).
    Количество заявок решенных за час.

    При таких KPI по п1 получаем руководителя 1-й линии.

    • Дмитрий Исайченко

      “При таких KPI по п1 получаем руководителя 1-й линии.”

      KPI 1-2 просто являются показателями L1, так что Ваш вывод неудивителен. Но KPI 3 вряд ли оценивает L1, вряд ли он “ведёт” нас к такому назначению. Так же нас не ведут к такому назначению классические KPI управления инцидентами – доля своевременно решённых инцидентов, доля инцидентов с соблюдением времени реакции (как вариант – реакции на назначение), доля инцидентов, решённых с первого раза (без возвратов на доработку).

      Так что, пожалуй, я с такой логикой не соглашусь.

      • Grigory Kornilov

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

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

        Например, если менеджер процесса является руководителем (или лидером\старшим сотрудником) первой линии, то он будет статистом\наблюдателем для KPI – ‘доля инцидентов, решённых с первого раза’, если 80% инцидентов решаются не внутри его подразделения. Предположу, что его влияние мало и как следствие вклад в улучшение этого показателя будет ничтожно.

        • Дмитрий Исайченко

          “Я предлагаю связывать ответ на вопрос с практикой применения.”

          Я только так и делаю. Примеры KPI привёл. Кроме того, обычно есть KPI, которые связаны со всеми ключевыми ролями процесса. Для управления инцидентами – это не только менеджер процесса, но старшие групп поддержки и старший L1. Поэтому выбирать менеджера по метрикам мне кажется странной идеей. Не говоря уже о том, что хронологически сначала появляется менеджер процесса, потом процесс с метриками.

          “Например, если менеджер процесса является руководителем (или лидером\старшим сотрудником) первой линии, то он будет статистом\наблюдателем для KPI — ‘доля инцидентов, решённых с первого раза'”

          И поскольку это один из классических KPI управления инцидентами (как и своевременность решения и реакции), то получается, что, как правило, старший L1 не самый лучший кандидат на роль менеджера, верно я понял Вашу мысль? Но если руководствоваться именно этой логикой, то любой функциональный руководитель плохой кандидат. Тут Павел Солопов прав – налицо отсутствие матричного управления 🙂

          • Grigory Kornilov

            Я указывал на взаимосвязь между менеджером\KPI процесса\проблемами качества процесса.

            Является ли это рекомендацией\алгоритмом к выбору менеджера? Прямой нет, но если определены приоритетные на данный момент KPI, то надо искать менеджера, который имеет влияние именно в подразделениях, где эти KPI ‘достигаются’ … или наделять его этим влиянием … или готовиться к проблемам качества.

            Матричное управление – может где-то оно в каком-то виде и есть. Может в виде сбора из матрицы на время проекта выделенной команды под управлением PM-а.

            PS: Опять у вас ссылка на обобщение – “это один из классических KPI управления инцидентами”

            • Дмитрий Исайченко

              “Опять у вас ссылка на обобщение — «это один из классических KPI управления инцидентами»”

              А чем это плохо?

  • ZW

    Схема не будет работать, если в организации несколько прикладных отделов.
    Вообще, это серьёзный вопрос, увязка управления процессами с существующей административной структорой.
    На мой взгляд, один процесс- один менджер из одного отдела. Иначе получится перетягивание каната на уровне вышестоятщего руководства

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.