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

Мини-кейс: выбираем приоритеты

Опубликовано 28 сентября 2012
Рубрики: ITSM, Service Desk, Практика и опыт, Управление инцидентами
Комментарии

Подискутировал тут со слушателями спец-курса «Управление инцидентами» про выбор приоритета инцидентов.

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

Дело в том, что в этой организации есть регламент процесса, где, во-первых, приоритет однозначно определяет целевой срок устранения инцидента, а еще заданы признаки выбора приоритета. Примерно такие:

Приоритет «Высокий» – сбой затронул работу всех пользователей

Приоритет «Средний» – сбой затронул значительное число пользователей (более 80% по оценке ИТ-специалиста»).

Приоритет «Низкий» – прочие сбои.

Такая система критики, понятно, не выдержала, на нижнем уровне исполнителей не заработала и недавно была заменена новой. 

Организация (ИТ-служба тут внутреннее подразделение) устроена по принципу территориальных единиц. Условно: квартал – здание – этаж – кабинет. В каждом «кабинете» есть свои ИТ-сотрудники поддержки и пользователи, на каждом этаже инфраструктурщики и ИТ-руководство (и другие пользователи) и далее, до ИТ-директора и других директоров на уровне «квартала».

Теперь приоритеты такие:

«Высокий» – Сбой у всех пользователей квартала

«Средний» – Сбой у всех пользователей здания

«Низкий» – сбой у всех пользователей этажа и прочее.

Стало ли лучше?

Мне кажется, стало. Теперь критерии, по которым определяется приоритет, более объективны. Хотя и здесь есть пространство для ошибочной оценки количества пользователей, все же ее можно скорректировать позже инцидента. С точки зрения тех, кто отвечает за ИТ в квартале в целом, такая система помогает уделять внимание только крупнейшим авариям, приносящим ощутимый ущерб заказчику.

Другое дело, что ИТ-шникам, которые в кабинетах, точно не стало легче: все инциденты в их компетенции попадают исключительно в «Низкий» приоритет, и поэтому такая система всё равно для них не работает.

Как можно её усовершенствовать, коллеги? Подсказка: всякие другие слова, типа "срочность", "серьезность", "влияние", вводить запрещается. Дополнительное значение "Очень низкий" обидит пользователей 😉

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

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

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

  • Pavel Solopov

    А как инциденты регистрируются? В каждом кабинете самостоятельно или через некую “общегородскую” точку входа и затем как-то спускаются вниз до кабинетных специалистов?

    • Pavel Solopov

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

      Для этажа:
      Низкий – сбой в одном кабинете.
      Средний – сбой в нескольких кабинетах.
      Высокий – сбой у всего этажа.

      И т.д.
      А при эскалации инцидента с уровня на уровень, приоритет менять на Низкий (для нового уровня).

      • Константин Нарыжный

        Ойойой, я столько комментов пропустил!
        Павел, да инциденты могут регистрироваться на любом уровне, как пользователями, так и ИТ.
        То есть при наивысшей эскалации будем иметь приоритет Н.В.В.В, по разрядам. А для инцидентов в кабинете приоритет был бы 0.0.0.Н
        Если, конечно, стоит задача сделать сквозные приоритеты. Именно она и стоит.
        Это решение я и предложил бы, если б знал инструмент, способный на такую крутоту;) А вы знаете?

        • Pavel Solopov

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

          Самый лучший инструмент Visual C + DevExpress. 🙂
          А что многоуважаемый OmniTracker не совладает с этой задачкой?

  • Евгений

    А не проще сделать так:

    1. Высокий – VIP пользователи (руководители отделов, директора, совет учредителей и т.д.)
    2. Средний – все остальные пользователи
    3. Низкий – случаи, когда пользователь просит решить его техническую проблему, например, в течении 10 рабочих дней

    …

    • Константин Нарыжный

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

      • Евгений

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

        То же самое и с низким приоритетом: звонит дядя Вася из отдела кадров, говорит, что у него случилась беда с ноутбуком, но он готов его принести на диагностику и ждать до после завтра, так как он (дядя Вася) уезжает в командировку на пару дней…

        • Константин Нарыжный

          Евгений, но если обращений от Иванов Петровых больше, чем 1? Ведь из них тоже придётся как-то выбирать? Сурово по FIFO?)))

          • Niza

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

  • Альберт

    «Высокий» — Сервис не работает у нескольких пользователей
    «Средний» — Сервис не работает у одного или ухудшилось качество сервиса у нескольких пользователей
    «Низкий» — Ухудшилось качество сервиса у одного пользователя

    • Константин Нарыжный

      Альберт, отлично. Но вот только субъективный критерий “Ухудшилось” мне не очень понятен. Вот тут в соседнем посте у Романа – ухудшился сервис или вообще не работал?)))

      • Альберт

        Ухудшилось это все что находится между “Сервис работает” и “Сервис не работает”. Здесь важно чтобы первая линия на основе вопросов и ответов смогла понять, Сервис совсем не работает или работает хоть как-то.
        Если имеется ввиду тема “Вопрос из зала: упрощение эскалации“ то я согласен с высказыванием Владимира Капустина: “Может, стоит чуть заумнить первую линию? Сделать им базу знаний и опросник, чтоб не гонять выключать DND на телефонах?”
        В любом случаи приоритет всегда можно изменить. Очевидно, если обратиться еще пара пользователей с такой же проблемой или это выяснится в процессе опроса первого обратившегося, то приоритет придется повышать.

        • Константин Нарыжный

          Я имел в виду пост про тесты интеллекта, как инструмент сокращения числа голосовых обращений. Там сервис в итоге заработал. Но не сразу, и дороже, чем было задумано. http://www.realitsm.ru/2012/10/testy-intellekta-kak-instrument-podderzhki-polzovatelej/

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

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

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

            Совсем не обязательно. Как раз наоборот – должна быть возможность изменять приоритет без изменения срока (именно для снижения вероятности нарушения сроков). Подробнее смотри здесь: http://www.cleverics.ru/ru/subject-field/webinars/46-core/webinars-and-video/344. Уровень влияния тоже может потребоваться изменить по ходу обработки, но это уже конечно совсем другая история. Здесь важно, какие объекты в ИС используются для организации управления инцидентами.

  • Роман

    У нас в компании нет приоритетов, но есть влияние, которое определяет крайний срок решения обращения пользователя. Для обоих влияний крайние сроки зафиксированы в SLA. Всего два влияния: высокое и обычное. По умолчанию в обращении указывается обычное влияние. В обращении указывается инициатор и его рабочее место. Если инициатор VIP (у нас это большие боссы), то система автоматически устанавливает высокое влияние. А еще у нас в SLA указывается перечень рабочих мест, для которых тоже применяется высокое влияние (при этом это уже не боссы, а очень оперативные работники). Если в обращении указали такое рабочее место, то система тоже устанавливает высокое влияние. Для инфраструктурных инцидентов (ИИ), которые могут вызвать массовое кол-во обращений, у нас для каждой системы прописано свое целевое время восстановления, которое определяет крайний срок решения данного ИИ и оно намного меньше чем сроки решения обращений пользователей, зафиксированные в SLA. В SLA про эти целевые времена по инфраструктурным инцидентам тоже написано.

    • Константин Нарыжный

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

      • Pavel Solopov

        Ну так это разные сущности “обращение” и “ИИ”, соответственно для “обращения” будет свой крайний срок, для “ИИ” свой крайний срок. Пользователю видимо повезёт, его обращение решится раньше, вместе с “ИИ”.

        Кстати нормальная идея, приоритезация по крайним срокам более объективна: “Это реши к такому-то времени, это к такому. За что браться в первую очередь, чтобы успеть реши сам.”
        А два инцидента с одинаковым приоритетом уже приводят к неоднозначности “за что хвататься?”, к тому же не гарантируют получения желаемых результатов на глобальном уровне.

      • Роман

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

        • Константин Нарыжный

          у диспетчеров службы поддержки есть голова на плечах
          О, золотые слова!
          А как с отчетностью, Роман? Мне кажется, что у вас в статистике фактических сроков устранения сервисных инцидентов есть маленькая доля, таких, которые решались значительно быстрее, чем остальные (потому что им достались “богатые родственники” ИИ. Нет такого?

          • Роман

            Конечно есть, Константин, в этом нет ничего плохого, все в соответсвии с нашими процессами и Соглашениями :-).

  • Вадим

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

    • Вадим

      а если же в это время существует пользователь, который с помощью какой-нить хрени АСУТП пытается что-то там включить, или лучше выключить, но у него в этот момент зависает компьютер, оставив хрень невыключенной (или просто в непонятном состоянии)

      и ессно, как обойтись без экскаватора переехавшего кабель связи с центром? ))))

      как будем приоритизировать?

      • Константин Нарыжный

        Будем головой. Чуть выше на алгоритмическое правило указал Роман: список таких бухгалтеров с VBF должен быть включен в SLA. Можно выявлять такие сбои руками и выставлять критический приоритет руками. А как иначе?))
        С экскаватором как раз все понятно. Влияние на услуги для всех пользователей.

  • Niza

    Почему бы не привязать приоритеты к степени критичности систем+масштаб инцидента. И то, и другое легко определяется.

    • Константин Нарыжный

      Да, суперский книжный вариант из процесса SLM. Но, Низа, пробовали ли Вы попросить заказчиков проранжировать системы по степени критичности?)))

      • Niza

        На самом деле это вариант, который был внедрен и успешно работает в нашей компании. Список систем по классам критичности регулярно обновляется. Константин, откуда такое недоверие? 😉 Я не консультант, который работает с заказчиками, а живой менеджер, внедряющий и поддерживающий процессы 🙂 Так что все на своей шкуре проверено и испытано.

        • Константин Нарыжный

          Напротив – мнение практиков ценнее книжных аксиом. Вот я только не представляю себе, что бы ответить какому-нибудь коммунальному хозяйству, которое придет ко мне и скажет:
          “в вашем доме мы управляем канализацией и мусоропроводом. Людей не хватает, поэтому сбои планируем устранять за разные сроки. С засором чего из двух вы готовы мириться дольше?”
          Если серьезно, то ваш подход начинает работать ровно в тот момент, когда переговоры с заказчиками услуг (бизнесом) перешагивают барьер “все системы критические”.

          • Niza

            По вашему примеру:
            «в вашем доме мы управляем канализацией и мусоропроводом. Людей не хватает, поэтому сбои планируем устранять за разные сроки. С засором чего из двух вы готовы мириться дольше?»
            Канализация – это слишком обобщенно. 🙂 Можно говорить о предоставлении услуги на разных уровнях(раковина-унитаз-ванна/вся сантехника в квартире/этаж/подъезд/дом) и с разным качеством (не работает/работает частично/редкие неисправности) и отсюда уже вычислять приоритеты.
            По мусоропроводу выкладки делать? 😉

            • Константин Нарыжный

              Низа, у меня только один такой уровень: вся сантехника в моей квартире должна чиниться быстро. Так же быстро, как мусоропровод. Попробуйте убедить меня, что я должен подождать с устранением засора в моей раковине, если в это же время произошла аварияв соседнем подъезде. Мне-то какое дело?)))

              • Niza

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

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

                  Костя, Niza, я думаю, что вы в сущности спорите о разных вещах. Потому и спорите 🙂 Для того, чтобы навести порядок в разговоре, достаточно сделать следующее:
                  1. Четко развести два понятия: срок устранения и приоритет. Понятие приоритета тесно связано не только с обязательствами заказчику (как срок), но и с наличием внутренних ресурсов и умением планировать работы. Это справедливо и для INC, и для CHG с RFF.
                  2. В диалоге с бизнесом о сроках апеллировать не к критичности систем, а к критичности инцидента, связанного с их отказом, и критичности не для подразделения, а для компании в целом (дли бизнеса). Это очень важный момент.
                  В целом мне кажется, что проблема с приоритетами больше связана не с правилами, а с подвохом в самой постановке вопроса. Пользователям важен не приоритет, а срок. Приоритеты нужны ИТ-подразделениям, чтобы обрабатывать в срок (или с минимальными последствиями от нарушений сроков) инциденты в условиях нехватки ресурсов. В самом деле, если у вас 10 инженеров, которые могут обработать 10 инцидентов в день и их никогда не бывает больше 10, проблемы приоритетов нет вообще, да и такое понятие для инцидентов становится излишним 😉 Нехватка ресурсов же есть всегда сопоставление двух факторов: потока инцидентов на входе (количество в единицу времени, сложность) и наличия ресурсов (количество ресурсов, компетенция).
                  Подвох заключается в том, что обсуждая сроки устранения инцидентов, ИТ-подразделения видят это как изолированную задачу, в то время как в глазах бизнес-руководителей она не может быть отделена от усилий по сокращению потока инцидентов. Потому что если бы инцидентов становилось меньше, сроки решения могли бы сокращаться даже при той же численности ИТ-персонала. То есть если бы мне сказали “давайте увеличим сроки решения или дайте нам дополнительные ресурсы, потому что инцидентов слишком много”, я бы спросил в ответ “а что вы собираетесь делать для того, чтобы их стало меньше”, а следовательно и “на какой срок вам требуются дополнительные ресурсы”? Целенаправленные усилия в этом направлении могут существенно снизить остроту вопроса о сроках и приоритетах 🙂 Не согласны?

                  • Niza

                    Дмитрий, я не спорю, просто пытаюсь в меру своих знаний/опыта помочь в обсуждении. Но не совсем понятно ЧТО обсуждается 😉 Как-то намешано все в кучу.

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

                      “Но не совсем понятно ЧТО обсуждается Как-то намешано все в кучу.”

                      Вот и я ровно о том же.

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

    Что-то устал я уже писать про приоритеты, если честно.
    У них все заказчики одинаковые роботы, что-ли?

    • Pavel Solopov

      Ну давайте тогда про определение ИТ-сервиса, Александр, поговорим. 🙂

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

        ЖЖОШЬ, СОТОНА! )))
        Лучший комментарий месяца, короче – это да, куда уж приоритетам до сервиса )

        • Alexander Peshkov

          Я бы мог многое добавить к сказанному, но добавить к сказанному мне нечего.

    • Константин Нарыжный

      Что-то устал я уже писать про приоритеты, если честно. Александр, где можно почитать?)))
      У них все заказчики одинаковые роботы, что-ли? Да нет, разные. И инциденты разные. См. выше: от комьютера до экскаватора. А система должна быть единой, прозрачной и с объективными критериями. И уж точно должна приносить пользу: помогать сотрудникам отличать важное от неважного.

      • Pavel Solopov

        Немного несовместимые требования предъявляете: Объективной, но разделять важное и не важное. Важно или не важно, это как раз понятие субъективное. Для одних одно важно, для других другое… Не знаю даже, возможно ли абстрагироваться от этого субъективизма…

        • Константин Нарыжный

          Павел, отнюдь. Важнее те сбои, ущерб от которых больше.
          Нужны объективные критерии оценки размера ущерба. Сразу. На первой линии.

          • Pavel Solopov

            В том-то и дело, что ущерб это тоже понятие субъективное. То, что ущерб для этажа, сущая мелочь для здания, а то, что имеет значение для здания, ерунда в масштабах квартала и так далее.
            Поэтому надо понять с чьей точки зрения нужно приоритеты расстанавливать.

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

        Да мне кажется, мы с Димой уже раза 3-4 в разных темах успели обсудить все приоритеты – вон он ниже подмигивает )

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

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

      +1

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

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

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