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. Дмитрий Исайченко Автор

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

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

  1. Александр

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

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

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

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

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

  2. Андрей

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

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

  3. Pavel Solopov

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

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

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

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

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

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

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

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

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

      1. Pavel Solopov

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

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

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

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

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

          1. Pavel Solopov

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

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

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

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

  4. Grigory Kornilov

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      1. Grigory Kornilov

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

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

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

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

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

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

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

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

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

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

          1. Grigory Kornilov

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

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

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

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

  5. ZW

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

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

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

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

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

Empty