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

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

Опубликовано 29 апреля 2012
Рубрики: ITIL, Обо всём на свете, Управление инцидентами
Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

    Увы, но уточнять влияние у инициатора (пользователя) в 99% случаев бессмысленная задача

    • Евгений Шилов

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

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

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

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

        Смотри, по твоему же тексту “В ней есть масса недостатков, вот пара примеров” (с)

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

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

    У нас в компании юзер указывает только срочность (Urgency:) и кол-во затронутых инцидентом пользователей (Employees Affected:)

    • Евгений Шилов

      Андрей, а со срочностью нет перекосов типа: “пользователь всегда считает свое обращение срочным”? И всегда ли пользователь знает, что кроме него пострадали и другие пользователи?

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

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

    • Роман Журавлёв

      Андрей, а расскажите, если не секрет: что именно может указать пользователь в поле “срочность”? И на что это потом влияет?

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

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

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

          (тут смайлик, хватающийся за голову)

        • Роман Журавлёв

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

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

            (и тут смайлик, убивающий себя ап стену) 🙂

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

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

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

            • Роман Журавлёв

              и как, работает эта схема? в смысле:
              1. приоритет действительно влияет на порядок обработки?
              2. случаи некорректной приоритизации бывают? много?

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

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

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

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

                • Grigory Kornilov

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

                  Имхо –
                  1. Надо определить уровень Major Incident и сначала сосредоточиться на нем при классификации.
                  Можно составить таймкарту бизнес процессов (перечень бизнес процессов и их критичность во времени) и согласовать ее со всеми. Причем туда же могут входить процессы разработки\внедрения проектов.
                  2. Для VIP определить роль в SD.
                  3. Собрать свою статистику обращений и особенно недовольных результатами, решать что и как можно изменить. Пользователь не очень подобное любит, но правильнее спрашивать какую бизнес функцию он не может выполнить из-за инцидента и на основании этого выставлять критичность.

                  • Pavel Solopov

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

                    • Grigory Kornilov

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

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

    • Георгий

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

      • Pavel Solopov

        Вы что Георгий, в ИТ-компаниях не принято внедрять такие системы. 🙂 Нет возможности на внутренние проекты отвлекать специалистов с коммерческих проектов. да и дорого. 🙂

        • Георгий

          Павел, отчасти это правда, но не всегда и не везде, к счастью. 🙂
          Ну и потом – сервис-деск же они внедрили, даже вот судя по вопросу развивают… 🙂

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

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

        • Георгий

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

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

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

    Посоветуйте нужную прекрасную систему?
    Вдруг случится так что наши ИТшники о ней не подозревают 🙂
    Хотя в любом случае ошибок определения влияния у нас и так немного, и искать/ставить некую систему мониторинга чтобы их еще снизить – смысла нет вижу, затраты превышают полученную выгоду.

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

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

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

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

        Александр, я Вашу статью на ITSM форуме очень внимательно читал.
        Тем не менее, имею возразить:
        – в ряде случаев ИМХО все же итиловская схема вполне приемлемо работает
        – конкретно у нас срочность выбирает пользователь, параметр Impact устанавливает служба Хелпдеск, и крайний срок собственно зависит от SLA

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

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

          Андрей, если вы внимательно читали – тогда скажите, а какую собственно схему я предложил? 8)

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

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

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

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

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

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

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

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

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

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

                Александр, ваша статья емнип 2008 годом датируется – за минувших 4 года есть какие-то новые схемы выстраивания очереди инцидентов, практики внедрения?
                То что предлагаемая ИТИЛом схема имеет недостатки никто не спорит. Но ведь уже много лет худо-бедно но используется.

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

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

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

                  Например:
                  – [Услуга х Подразделение инициатора]
                  – [Услуга х Подразделение инициатора х Период возникновения]

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

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

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

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

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

        Саш, ну мне кажется ты преувеличиваешь. В ITIL v3 нет однозначного утверждения, что приоритет отождествляется с крайним сроком. Нет и утверждения про схему “Приоритет -> Крайний срок”. По-моему там сказано очень обтекаемо, что приоритет и срок связаны, но как конкретно – не раскрыто. Или я не нашёл? Приведи пруфлинк. Я, например, честно считаю свою “любимую” схему связи приоритета и срока полностью совместимой с ITIL. И не могу сказать, что она устарела и не работает.
        Явная рекомендация схемы “Приоритет -> Крайний срок” мне известна только в ISO 20000-2:2005, и наличие там такой рекомендации меня очень удивляет – откуда? ISO 20000-2:2012 пока не видел.

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

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

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

          • Роман Журавлёв

            Для начала поддержу Сашу в этом вопросе. В словаре 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) связь u х s = priority 2) связь priority – target resolution time. А trt, очевидно, это никак не время обеда. Я в этом уверен на 100%, ибо именно копирование таблицы v2->v3 вывело меня из себя настолько, что я сел и написал тогда ту самую старую статью.

              • Роман Журавлёв

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

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

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

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

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

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

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

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

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