Who is incident manager?

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

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

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

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

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

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

    1. Дмитрий Исайченко Автор

      Честно говоря, скорее напрашивается вопрос о совмещении судьи и присяжного, а также следователя и прокурора 🙂

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

      0
      0
  1. Александр

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

    0
    0
    1. Дмитрий Исайченко Автор

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

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

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

      0
      0
  2. Андрей

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

    В этом случае начальника SD можно оставить менеджером процесса.

    0
    0
  3. Pavel Solopov

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

    Из моей практики, разделение на линии разграничивалось лишь декларациями. Реально линии поддержки не создавались. Линии назначались на разные отделы, как вы пишите, что в корне не верно.

    первой линией объявляются отделы поддержки пользователей, которые на самом деле занимаются всеми вопросами связанными с ПК, рабочими местами и общим ПО. Но реально задачи они решают задачи и более высоких линий. Выдвигаются на место и чинят на местах, разбираются в сложных проблемах с общим ПО, разбираются проблемами в железе и т.д.

    В то же время какой-либо отдел поддержки прикладных систем объявляется второй линией, хотя часто они решают задачи первой — консультируя пользователей, какую кнопку нажать, чтобы выгрузить отчёт в системе ХХХ.

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

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

    0
    0
    1. Дмитрий Исайченко Автор

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

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

      0
      0
      1. Pavel Solopov

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

        А она почему не компетентна, потому что просто ярлык «первая линия» повесили на один из отделов, иллюзорно более близкий к пользователям.

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

        0
        0
            1. Дмитрий Исайченко Автор

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

              0
              0
          1. Pavel Solopov

            Что-то я, видимо, туго соображаю сегодня, но что-то я не пойму причём тут эффекты.

            Я говорю о том, что зачастую процессный подход только декларируется, а на самом деле подход остаётся прежним функциональным или скорее «оргструктурным».

            И роли назначаются не по принципу участия в процессе, а по принципу принадлежности к какому-то подразделению.

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

            0
            0
  4. Grigory Kornilov

    Можно рассуждать так:

    Целью является качество процесса.

    Для этого определены KPI.

    Для достижения KPI процесса кто-то ответственнен (обязан контролировать\требовать\оценивать достижение показателей по KPI).

    На практике этот ответственный может быть:

    1. Руководителем тех сотрудников IT, кто в большей степени влияет на достижение KPI.

    2. Сотрудником подразделения качества, который аля третейский судья. Прямого подчинения нет, но и вроде объективности больше.

    Какие KPI обычно есть и считаются важными на практике?

    Время назначения заявки на админа, который компетентен и в состоянии ее решить.

    Количество заявок решенных на 1-й линии (дешевле ресурс, быстрее решение).

    Количество заявок решенных за час.

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

    0
    0
    1. Дмитрий Исайченко Автор

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

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

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

      0
      0
      1. Grigory Kornilov

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

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

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

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

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

        0
        0
        1. Дмитрий Исайченко Автор

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

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

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

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

          0
          0
          1. Grigory Kornilov

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

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

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

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

            0
            0
  5. ZW

    Схема не будет работать, если в организации несколько прикладных отделов.

    Вообще, это серьёзный вопрос, увязка управления процессами с существующей административной структорой.

    На мой взгляд, один процесс- один менджер из одного отдела. Иначе получится перетягивание каната на уровне вышестоятщего руководства

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)