Оценка влияния инцидента

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

Но, вспоминая, что на первой линии нам обычно доступны только сами пользователи с их суждениями о сложившейся ситуации, а объем диагностической информации минимален, приходится придумывать вопросы, которые специалист первой линии может задать пользователю и на основании ответов оценить влияние. К вопросам предъявляется ряд требований: 

  • пользователи могут дать ответ
  • трактовка более-менее однозначна 
  • вопросов не много (обычно 2-4)

Традиционную схему, которую часто приводят в пример, приходится усложнять. Базовая схема такова — есть два вопроса:

  • у вас одного не работает, или ваши коллеги тоже испытывают трудности?
  • у вас совсем не работает или недоступна только часть функционала?

На основании ответов есть 4 уровня влияния: самый простой случай — у одного сотрудника снижено качество ИТ-услуги (например, не работает часть функционала), самый тяжелый — у отдела или компании не доступна ИТ-услуга

В ней есть масса недостатков, вот пара примеров:

  1. Сотрудник может и не знать, что творится у его коллег
  2. Непонятно, что есть граница между "совсем не работает" и "частично не работает". Если сотруднику сейчас нужно распечатать отчет и он не печатается, а при этом всё остальное работает, то вряд-ли он согласится, что им надо заниматься в последнюю очередь.

Усложнение схемы обычно связано с дополнением ее более четкими условиями. например:

  1. Могут быть определены сценарии повышения влияния для определенных ИТ-услуг (ИТ-систем). Например, в конце месяца нарушения в работе функционала подготовки отчетности всегда имеют высокое влияние.
  2. Могут быть определены VIP пользователи (группы пользователей), обращения от которых имеют повышенное влияние, при этом VIP статус не обязательно связан с их должностью. Это может быть функциональный-VIP — сотрудник выполняющий важную бизнес-функцию.
  3. Могут быть определены отдельные ИТ-услуги (ИТ-системы) для которых уровень влияния устанавливается по своим правилам (например, всегда повышенный).

Единственное, усложняя схему, приходится помнить о том, что пользоваться ей будут люди, и чтобы не получилось 3 правила с 45 исключениями, лучше 40 раз подумать 🙂

Всем удачных выходных!

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

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

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

      1. Александр Жилинский

        Женя (лучше меня называть Саша, плз! иначе мне неудобно будет писать Женя — но так явно короче : )))

        А если не цепляться за догму, что влияние вообще должно быть запрошено у пользователя (про догму «влияние играет роль в оценке нормативного срока» я пока молчу ; ).

        Смотри, по твоему же тексту «В ней есть масса недостатков, вот пара примеров» ©

        И далее «Усложнение схемы обычно связано с дополнением ее более четкими условиями. например:». Ты внимательно посмотри на свои последние 3 пункта — ведь там вообще у пользователя ничего не нужно спрашивать, не так ли?

  1. Андрей Загорский

    со срочностью нет перекосов типа: «пользователь всегда считает свое обращение срочным»? — бывает конечно, но компания ИТшная, поэтому, как мне кажется, дисциплина на достаточно высоком уровне, пользователи квалифицированные.

    Что касается влияния на других пользователей, то как правило влияние на коллег по отделу/раб. группе пользователь знает.

      1. Андрей Загорский

        что именно может указать пользователь в поле «срочность»? — 4 значения — Low, Average, High, Critical. Это дефолтовые коды OOB, мне кажется в любой системе почти.

        На что влияет — на приоритет, увы у нас по ITIL, приоритет из срочности и влияния рассчитывается.

          1. Андрей Загорский

            Не совсем верно 🙂

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

            P.S. Поправка — пользователь параметр «воздействие» (Impact) напрямую не указывает, он может указать лишь кол-во затронутых инцидентом пользователей (Employees Affected). А «воздействие» выставляет уже служба Хелпдеска.

            1. Роман Журавлёв

              и как, работает эта схема? в смысле:

              1. приоритет действительно влияет на порядок обработки?

              2. случаи некорректной приоритизации бывают? много?

              Если на первый вопрос ответ — «да», а на второй — «нет», то и прекрасно. Пока что. Повезло вам с нагрузкой и с пользователями 🙂

              1. Андрей Загорский

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

                2. Вот это не могу сказать, нужно уточнить как часто бывает.

                Нагрузка около 1000—1200 инцидентов в месяц.

                1. Grigory Kornilov

                  Андрей, если у вам компания IT, то вы под 1000 (54 в день) инцидентами подразумеваете не обращения, а именно инциденты?

                  Имхо —

                  1. Надо определить уровень Major Incident и сначала сосредоточиться на нем при классификации.

                  Можно составить таймкарту бизнес процессов (перечень бизнес процессов и их критичность во времени) и согласовать ее со всеми. Причем туда же могут входить процессы разработки\внедрения проектов.

                  2. Для VIP определить роль в SD.

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

                  1. Pavel Solopov

                    правильнее спрашивать какую бизнес функцию он не может выполнить из-за инцидента

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

                    1. Grigory Kornilov

                      У пользователя есть знания на момент первого обращения, что он не может выполнить 'другую' бизнес функцию?

                      Мы ведь понимаем, что бизнес функция это не всегд конкретное исполнение «здесь и сейчас». Например, если я дежурный 3-й линии (по sms\звонку 2-й линии), то не работоспособность операции авторизации (то есть удаленно работать не получиться) уже инцидент — не могу исполнять функцию, даже если мне конкретно сейчас не надо ничего делать, все работает нормально.

    1. Георгий

      Андрей, если у Вас ИТ-компания, поставьте себе систему мониторинга Ит-сервисов и инфраструктуры, для вас это не должно быть сложно.

      Причем и компонентного и транзакционного мониторинга.

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

      Это помимо того, что знать будете об инцидентах еще до звонка пользователя 😀

      1. Андрей Загорский

        Георгий, спасибо конечно за совет, система мониторинга у нас стоит, и не одна я так думаю (Zabbix точно есть) 🙂

        Если бы все вопросы Управления Инцидентами решались установкой системы мониторинга и проактивным анализом, жизнь стала бы намного прекраснее 🙂

        1. Георгий

          Не за что. Zabbix прекресная система, но не делает то о чем писал я 🙂 ну и если вы ищете ответов сразу на все вопросы- то это не к ITIL, а к Библии 🙂

          я написал ровно о том, что для того, чтобы избежать естественных ошибок пользователя в определении влияния инцидента, можно использовать правильно выбранные и настроенные системы мониторинга

  2. Андрей Загорский

    Посоветуйте нужную прекрасную систему?

    Вдруг случится так что наши ИТшники о ней не подозревают 🙂

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

    1. Александр Жилинский

      Андрей, дело не в системе. Мне стыдно ссылку на свою статью про приоритеты, срочности и влияния давать, устал уже — можно найти в гугле. У Димы Исайченко в его разделе здесь же лежит достаточно детально обсуждение приоритетов (уже с другой точки зрения). Это только первое, что на ум приходит.

      Догма, расписанная в ITIL сейчас — «приоритет (крайний срок) = срочность х влияние» устарела еще до выхода в свет ITILv3.

      1. Андрей Загорский

        Александр, я Вашу статью на ITSM форуме очень внимательно читал.

        Тем не менее, имею возразить:

        — в ряде случаев ИМХО все же итиловская схема вполне приемлемо работает

        — конкретно у нас срочность выбирает пользователь, параметр Impact устанавливает служба Хелпдеск, и крайний срок собственно зависит от SLA

        Вы постоянно напоминаете что ITIL это не стандарт, а лишь свод лучших практик, нужно уметь их применить, но упорно считаете схему расчета приоритета из ITIL категорически неприменимой, и лишь предложенную Вами правильной и безгрешной 🙂

          1. Андрей Загорский

            Насколько я понимаю —

            1. выстраивать очередность инцидентов не по приоритету, а по крайнему сроку (а кто в таком случае выставляет крайний срок?)

            2. приоритет считать не по итиловскому методу срочность х влияние, а по SLA, для чего нужно иметь каталог услуг и работающий процесс SLM.

            1. Александр Жилинский

              Андрей, нет, неправильно! В том-то и дело я не предлагал в статье никакой схемы (ну, кроме основанной на услуге), а только доказывал неработоспособность текущей и обсуждал практики, которые стоит пробовать.

              >приоритет считать не по итиловскому методу срочность х влияние, а по SLA, для чего нужно иметь каталог услуг и работающий процесс SLM

              Андрей, я прямо стесняюсь спросить — а раз вы так ратуете за стандартные решения из ITIL, вы в определение инцидента и в цель процесса управления инцидентами вообще заглядывали? Первое как бы подразумевает наличие услуги, а второе подразумевает разработанный SLA. Причем это не версии v2, а самое что ни на есть v3.

              Резюме. За последние несколько лет я нашел столько подтверждений нежизнеспособности стандартной схемы, что убедить меня ваш работающий пример может только в одном — у вас исключительная ситуация. Вполне вероятно. Ну что же, тогда опишите подробно кейс и пишите большую статью "оно все-таки работает "8)

              1. Андрей Загорский

                Страшные люди эти консультанты, стоит только попасть к ним в руки, они даже работающие процессы заоптимизируют до неузнаваемости 🙂

                >В том-то и дело я не предлагал в статье никакой схемы (ну, кроме основанной на услуге), а только доказывал неработоспособность текущей и обсуждал практики, которые стоит пробовать.

                Александр, ваша статья емнип 2008 годом датируется — за минувших 4 года есть какие-то новые схемы выстраивания очереди инцидентов, практики внедрения?

                То что предлагаемая ИТИЛом схема имеет недостатки никто не спорит. Но ведь уже много лет худо-бедно но используется.

                Я не ратую за буквальное следование советам ИТИЛ — если Вы не заметили, у нас как раз крайний срок по SLA считается, из Каталога услуг, а не по приоритету.

                1. Александр Жилинский

                  Конечно есть. Те, что я предполагал в статье - они самые отлично работают. Услуга + критерий (критерии). Просто они очень разные для разных организаций.

                  Например:

                  — [Услуга х Подразделение инициатора]

                  — [Услуга х Подразделение инициатора х Период возникновения]

                  Можно даже Услуга х Влияние (если вы его научились мерять не со слов пользователя), Услуга х Инициатор.

                  Для определенного типа контрактов (SLA) бывают и более интересные сочетание, например [Услуга х КЕ].

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

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

        «Догма, расписанная в ITIL сейчас — «приоритет (крайний срок) = срочность х влияние» устарела еще до выхода в свет ITILv3.»

        Саш, ну мне кажется ты преувеличиваешь. В ITIL v3 нет однозначного утверждения, что приоритет отождествляется с крайним сроком. Нет и утверждения про схему «Приоритет -> Крайний срок». По-моему там сказано очень обтекаемо, что приоритет и срок связаны, но как конкретно — не раскрыто. Или я не нашёл? Приведи пруфлинк. Я, например, честно считаю свою «любимую» схему связи приоритета и срока полностью совместимой с ITIL. И не могу сказать, что она устарела и не работает.

        Явная рекомендация схемы «Приоритет -> Крайний срок» мне известна только в ISO 20000-2:2005, и наличие там такой рекомендации меня очень удивляет — откуда? ISO 20000-2:2012 пока не видел.

        1. Александр Жилинский

          Дим, разработчики (подозреваю, что это Дэвид, на самом деле, которому лень процесс переписать) тупо скопировали таблицу с явным практическим примером из ITILv2 прямо в ITILv3!

          И там прямо так и написано написано Приоритет = Влияние х Срочность, а потом Критичный = 1 час, Среднекритичный = 4 часа и прочее. Если это не рекомендация, тогда не знаю, что брать за рекомендацию.

          1. Роман Журавлёв

            Для начала поддержу Сашу в этом вопросе. В словаре ITIL явно сказано: Priority is based on impact and urgency, and is used to identify required times for actions to be taken. Это из определения термина «приоритет». А у терминов Impact и Urgency в свою очередь говорится: Impact and urgency are used to assign priority.

            То есть, особенно с учетом упомянутой таблички, таки да, приоритет у них это декартово произведение срочности и влияния.

            Но. Теперь поддержу Диму.

            Во-первых, times for action to be taken не обязательно означает «крайний срок». С тем же успехом может означать сроки начала работ, эскалации, обеда, отбоя и активации плана самоуничтожения.

            Во-вторых, там же, буквально в следующем предложении, говорится: For example, the service level agreement may state that Priority 2 incidents must be resolved within 12 hours.

            То есть SLA определяет требования к времени решения инцидентов некоторой относительной важности (а приоритет определен в ITIL именно как относительная важность события), но именно для услуг(и), описанной (-ых) в этом SLA.

            То есть вот она — Сашина схема «SLA+критерии».

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

            1. Александр Жилинский

              Рома, мне лень сейчас копаться в исходниках, но я абсолютно уверен, что рекомая таблица-пример (во второй версии она была в приложении, в третьей версии ее врезали прямо в тексте) показывает 1) связь u х s = priority 2) связь priority — target resolution time. А trt, очевидно, это никак не время обеда. Я в этом уверен на 100%, ибо именно копирование таблицы v2->v3 вывело меня из себя настолько, что я сел и написал тогда ту самую старую статью.

              1. Роман Журавлёв

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

                Вообще же, коль скоро дискуссия ушла от оценки влияния к приоритетам, рискну заметить на полях, что само понятие «приоритет» имеет смысл только в случае ресурсного конфликта. А потому не является обязательным атрибутом всякого инцидента. (Это я так, чтобы ты не подумал вдруг, что я призываю слепо следовать ITIL :))

        2. Александр Жилинский

          Заметь, что я твою статью также рекомендую в «перечень материалов» выше )

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

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

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

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

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

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

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20