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

Советы по приоритетам

Опубликовано 9 июня 2011
Рубрики: Service Desk, Аналитика: точка зрения, Управление инцидентами
Комментарии

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

Американский консультант Ден Кейн опубликовал несколько советов на эту тему, основываясь на своем опыте:

  1. Распространите информацию о приоритетах обработки заявок по всей организации, избегая употребления любых технических терминов и уделив внимание дизайну и вёрстке ваших публикаций.
  2. Рассказывая о приоритетах, обязательно упомяните, о чем этот приоритет свидетельствует для пользователя. Включите следующую информацию: ожидаемое время реакции, ожидаемые трудозатраты, ожидаемый срок решения, порядок информирования (например, с какой частотой вы собираетесь информировать заявителя о статусе заявки).
  3. Не поддавайтесь соблазну пообещать то, что вы не в состоянии измерить. Например, если нельзя измерить время регистрации  заявок, поступивших по электронной почте, то не пишите "обработка заявок поступивших по электронной почте, производится в течении 30 минут". Пользователь воспримет эту фразу как "когда дойдут руки".
  4. Используйте инструмент автоматизации, чтобы направлять пользователям уведомление сразу после регистрации заявки. Краткое описание, идентификатор заявки, а главное – ожидаемые сроки реакции и решения – вот самое существенное, что должно присутствовать в этом уведомлении.
  5. В этом же уведомлении, сообщите заявителю о том, как можно повысить приоритет заявки. Не пугайтесь: воспользуются этим немногие. Важно сообщить пользователям о том, что у них есть право и инструмент контроля.
  6. По ходу исполнения заявки, постарайтесь обеспечить заявителя информацией по статусу. Желательно, чтобы инструмент автоматизации позволял пользователям настраивать частоту и объем обновлений под свои нужды.
  7. Очень важно соблюдать ожидаемые сроки, которые вы сообщили пользователям. Однако, если выполнить обещанное не удаётся, обязательно информируйте заявителя об этом. Здесь лучше использовать личное общение, а не инструмент автоматизации. Как говорится, "плохие новости лучше, чем отсутствие новостей". 

В комментариях приглашаем вас дополнить этот практичный список.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

  • Анатолий Павлюченко

    Добавить нечего. Можно убрать п.5.

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

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

    • Олег Скрынник

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

      • Анатолий Павлюченко

        А почему кто-то за клиента решил что ему важно? А почему только срок исполнения?
        После прочтения заметки и оригинала я, думаю, что достаточно точно понял мысль, которую хотел автор. “Давайте повернёмся лицом к клиенту”. 🙂 Давйте покажем ему наши благородные и чистые помыслы. При этом не будем плести никаких небылиц и откровенной чуши.
        Мне кажется, здесь идёт речь больше о маркетинге в ИТ и “работе по воспитанию ожиданий”, чем о приоритетах самих по себе.

        • Олег Скрынник

          “А почему кто-то за клиента решил что ему важно?”
          Мы все каждый день бываем клиентами, в том числе и по айтишной части. Поэтому в данном случае я мерил по себе – если мне в ответ на заявку (например, по поводу хостинга) скажут, “принято, приоритет четыре”, я не очень буду рад. Что принято – спасибо, что четыре – непонятно. Дальше неизбежно должно последовать объяснение, что этот приоритет значит (может и не дальше, а, наоборот – раньше).

          Тогда вопрос – зачем мне говорить приоритет, лучше уж скажите что он за собой влечёт.

          Мне вот интересны в таких случаях ровно две вещи: мной уже занимаются? когда всё будет работать?

        • Олег Скрынник

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

    • Олег Скрынник

      Диаметрально противоположный вариант – использовать механизм, предложенный Скептиком в книжке “Введение в реальный ITSM”:

      “В Real ITSM SLA не определяют время отклика. Основываясь на приоритете, они определяют, сколько людей будет назначено для работы с инцидентом, сколько часов в день они будут работать, и какой другой работой они при этом смогут пренебречь.”

  • Георгий

    мне все нравится.
    если с умом выполнить п.1, то можно намного сделать службу намного более прозрачной для клиента, я всегда за такой подход
    кстати, если п.1 выполнить и с умом и с прямыми руками, то клиент, который “не хочет” и не будет видеть ничего кроме срока решения. а тот, кому нужно зачем-то знать больше – найдет исчерпывающую инфу в нормальной форме без лишних терзаний.

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

    В итоге есть два параметра “срок” и “приоритет”. Вот что думается:
    1. Сообщать пользователю приоритет, мне кажется, бесполезно, т.к. это ни о чем не говорит. Он ведь не видит очереди обращений с таким же приоритетом. В итоге могут возникнуть вопросы: почему мое обращение с высоким приоритетом обрабатывается целый день.
    2. Сообщать пользователю срок полезно, т.к. исходя из него он может планировать собственную работу и в течение этого срока не будет теребить ИТ. НО! У него конечно же возникнут вопросы: почему срок такой и что это за срок? Поэтому:
    3. Необходимо разъяснять откуда берутся сроки и что они означают. Например:
    3.1. Срок решения обращения это максимально возможный в данной ситуации срок. Возможно все исправят быстрее, но обещать не можем.
    3.2. Срок зависит не от громкости Вашего крика на оператора, ваших знакомств среди руководителей, а так же умения убеждать. 3.3. Срок зависит от: А, Б, В. Где: А, Б, В – понятные для пользователя и измеримые им параметры.

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

    Ожидаемый срок решения – это фикция, экспертная оценка, в большинстве случаев. Пользователям интересны не наши цели по срокам, а чтобы о его обращении думали. Постоянно. Хотя бы кто-нибудь.
    В этом смысле интересна идея автора про настройку уведомлений под себя.
    На практике не могу вспомнить self-service интерфейс, который позволял бы это делать для конечных пользователей.
    Коллеги?

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

      Константин, по сроку решения не согласен. Если заявок не 10-20 в день, а значительно больше – ожидаемый срок решения вполне счетная величина.

      • Олег Скрынник

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

        Опять же, меряю по себе.

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

          Олег, ты опять про приоритет? Клиенту зачем приоритет сообщать – чтобы он знал, что есть задачи и клиенты важнее, чем его? )

          Я еще в статье “мифов о лучших практиках” (про срочность-влияние и приоритет как раз) специально вытащил определение приоритета из словаря.

          • Олег Скрынник

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

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

            Я же не тётенька-бухгалтерша, я понимаю, что я не один тут с проблемами. В очереди могу и постоять. Но не долго 🙂

            Пример №1 из обычной жизни: лёг web-сайт, мы за него платим кучу денег, мне не важны приоритеты – мне нужно немедленно. Мне важно, чтобы мной стали заниматься прямо сейчас, и решили максимально быстро.

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

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

            В любом случае приоритет мне ни о чём не сказал бы. Время – вот что важно.

            Разве нет?

            • Георгий

              Все верно, очень хорошие примеры.

              Но вы, коллеги, как-то уцепились за идею “сообщить пользователю приоритет”. Такое ощущение, что это можно сделать, только сказав ему дословно “ваш приоритет в нашей системе – 4, ждите” :)))
              Это же не так. я так понял автора и мой коммент именно в том, что можно дать интересующемуся (уж зачем он интересуется, другой вопрос) пользователю больше инфы о наших внутренних процессах – о том, как мы обрабатываем его запрос, где он сейчас, какое время ожидания и какое время решения (плановое) его заявки, почему оно такое, что можно сделать чтобы повлиять на процесс итп 🙂

              • Олег Скрынник

                Не, ну с этим я согласен, это ж лицом к клиенту.

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

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

                • Георгий

                  Спрашивали – отвечаем. Есть заявка поданная через клиент-банк. Увеличить какой-нибудь лимит (например, лимит дневных расчетов или лимит снятия наличных).
                  Мне, кстати, в первую очередь, инетресно не то в какой срок дадут ответ, а какой дадут ответ (да или нет), но это детали.
                  Срок плановый важен, однако, в некоторых случаях моя заявка проходит такой интересный этап как созвон представителя банка со мной 🙂 и мне хотелось бы знать – будут ли мне звонить, когда и куда 🙂 например чтобы я сам им перезвонил если мне не дозвонились
                  это навскидку, для примера клиент-банка. Еще примеры есть я думаю.
                  Важно что при максимальной прозрачности (даже если я ей не пользуюсь) мое восприятие сервисной службой существенно улучшается. Возможно только мое 🙂

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

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

                    • Олег Скрынник

                      О, я был бы счастлив! 🙂
                      Я такой важный, мною уже столько народу озадачено-озабочено! 🙂

                    • Георгий

                      менять банк 🙂

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

                      Банк-то ладно, вообще-то этот пример я привел из реальной организации, такие уведомления выдает служба ИТ )

                      Вопрос – у какого числа пользователей ответы (и вопросы!) SD сыпятся в папку спам?

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

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

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

        Приветствую, Александр.
        Ну это будет статистическая оценка, так ведь? А статистику следует сначала накопить, это раз, и представлять она будет “среднюю по больнице”. А представьте что из ну скажем 1000 заявок 990 решились за час, а один инцидент расследовался целую неделю?

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

          Ну эээ, Константин, статистическая оценка не означает средняя оценка )

          • Олег Скрынник

            Мой любимый пример – как мы на позапрошлой работе пытались нормативы по выполнению обращений рассчитать на основе накопленных данных за прошлые периоды. Несколько десятков тысяч записей было. Фильтровали по категории, приоритетам, ещё по нескольким параметрам.

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

            Работало замечательно. Даже расчёт был динамическим, если я правильно помню.

            Только один раз на заявку “установка нового телефонного аппарата” был предложен плановый срок “394 дня”. Все порадовались, включая инженера и пользователя. Оказалось, что в прошлый раз номер на этом филиале подключали реально больше года, т.к. нужно было то ли АТС менять, то ли плату какую-то докупать, а это же подрядчик-бюджет-поставка-и-т-д…

            Наверное, на бОльшем объёме данных и с учётом бОльшего числа нюансов расчёт можно сделать точнее.

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

            Пусть эксперт сосчитает распределение вероятностей, построит гауссианы по разным приоритетам, да на основании данных за год – его оценки всё равно останутся экспертными, причём со стороны ИТ.

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

            Ну а подменил понятия – увы мне, гуманитарию, увы =)

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

              Константин, я все-таки позволю себе второй раз не согласиться с экспертной оценкой. Да, в большинстве случаев так и бывает.
              Ожидаемый срок, регламентный срок – обычно берется только из экспертной оценки ИТ, и как самый лучший вариант – из “среднего по больнице”, как мега-вариант из “среднего по больнице” с выборкой за много лет, по хорошей системе. Как супер-мега-гипер вариант – с корректировкой статистики (чтобы не вылезали штуки вроде 394 часа).

              Но я сейчас говорю о другом – использовать карты Шухарта (с модификациями). Это все равно оценка со стороны провайдера (ИТ), но оценка на порядок более осмысленная, позволяющая не только выдать “реальный ожидаемый срок”, но и искать дыры в процессе на системной основе.

              Потому что, Константин, сколько бы много не думали о простоях и цене часа, если у нас кривой процесс или банально не хватает ресурсов – то ожидаемый срок решения от этого не изменится. Т.е. подрядчик хочет 1 час (и ему нужен 1 час, т.к. там реально критичный процесс, крупные потери) – но поставщик 1 час все равно дать не сможет, а сможет выдать 2,5 часа (на деле 2,57) по куче причин.

              • Олег Скрынник

                Саш, а есть практический опыт использования карт Шухарта для той задачи, которую мы обсуждаем? Было бы интересно узнать детали.

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

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

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

                Александр, у нас с Вами нет противоречий.
                К тому моменту, когда поставщик будет достаточно зрел, чтобы ответить заказчику “2,57 часа”, он сможет сразу сказать что “а 1 час будет стоить дополнительно $1 млрд.”. Тут же начнется поиск компромисса, о котором я выше писал…
                В любом случае, сам этот компромиссный целевой срок, потребителю мало скажет, вне зависимости от уровня зрелости поставщика услуг.
                Потребителю важно, чтобы о нём помнили, и проявляли заботу, но не сыпали в него фразами “4 часа” (будет пить кофе ровно 4 часа или пойдет домой).

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

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

    Из практики могу сказать, что информирование клиентов о приоритетах – крайне редкая практика и по-моему не зря. Что касается предложенных пунктов, то:

    – 3-4 – must have и по факту делаются всегда;
    – 7 – стараются делать, но на больших потоках это получается не всегда. И согласен с высказываниями выше, что соблюдение срока важнее приоритета в большинстве случаев (приоритет – это наш механизм, помогающий соблюсти срок);
    – 5-6 очень спорно.

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

    Может быть автор писал эти пункты для какой-то мега-зрелой организации, где уже всё так круто, что осталось только играть с приоритетами?

  • Наргиза С.

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

    • Олег Скрынник

      “…считаю необходимым давать пользователям информацию о предельном времени решения и, при изменении приоритета, об изменении срока решения в ту или иную сторону”

      Вот! С этим я полностью согласен.

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

        А я вроде бы первой строкой согласился? )

        • Наргиза С.

          Если занудствовать, то ожидаемое время решения не есть предельный срок решения. 😉
          Может, лучше обсудим критерии информирования пользователей? Я однозначно за информирование по изменению статусов (для примера: “зарегистрирован”, “принят в работу”, “решен”, “устранены последствия”).

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

            Ну, если занудствовать – то я просто использовал терминологию исходного текста, убрав все лишнее и незначимое )

            Я в принципе за информирование инициаторов (это точнее, чем пользователей), но тут много нюансов.

            Например, у большинства сервисных служб своя “легенда” по статусам, и даже такие простые статусы “зарегистрирован”, “принят в работу” могут означать десяток разных вариантов. А вот погружение пользователя внутрь деталей процесса обслуживания – это лишняя, совершенно не нужная ему информация.

            • Наргиза С.

              Занудствовать более не буду 🙂
              +1 “А вот погружение пользователя внутрь деталей процесса обслуживания — это лишняя, совершенно не нужная ему информация.”
              Хочется конкретики по информированию инициаторов, из жизни. Поделитесь? Сама сейчас в стадии разработки параметров для автоматического информирования.

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

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

                Например:
                – назначен ID обращению и время начало обработки (инициатор может быстро идентифицировать обращение)
                – поставлено в ожидание (продолжение работы требует действия инициатора)
                – обработка завершена (пользователю нужно оценить качество работы)
                – и т.д.
                На основе этого списка и строите систему уведомлений. А не на основе любого изменения статуса, рабочей группы, исполнителя, какого-нибудь классификатора.

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

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

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