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

Ожидания и злоупотребления

Деятельность по поддержке пользователей организована в огромном множестве компаний. И измеряется она более-менее стандартно уже много лет. Одним из основных показателей качества поддержки является метрика своевременности, которая, упрощенно говоря, определяется как доля обращений, решенных в рамках норматива, от общего количества обработанных обращений. У этой формулы есть свои изъяны, и мы много писали об этом – и на портале, и в статьях, и в нашей книге про измерение ITSM-процессов.

no_excuses_wall_clockНо сейчас не об этом. Бывает так, что исполнитель не имеет возможности обработать запрос не по своей вине, а потому что пользователь не предоставил ему всей информации, или не может обеспечить доступ в свои помещения, или не согласовал выделение средств и так далее. И если мы используем показатель своевременности для оценки деятельности персонала, мы должны как-то учитывать вынужденные ожидания, то есть приостановки в обработке запросов не по нашей вине / причине, чтобы не позволять оправдываться в несвоевременном решении словами «это не я, это они, а я все сделал сразу». Для этого во многих ITSM-продуктах есть функциональность, которая позволяет корректировать общее время обработки запроса на длительность такого вынужденного ожидания. И это функциональность очень востребована на практике.

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

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

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

А вопросы мои таковы:

  • Используете ли вы в своей практике ожидания, которые позволяют «приостанавливать таймер» обработки запросов?
  • Если используете, как боретесь со злоупотреблениями?
  • Если для этого вы, в том числе, используете KPI, то какие?

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

  • Nargiza Suleymanova

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

    Если используете, как боретесь со злоупотреблениями?

    Если для этого вы, в том числе, используете KPI, то какие?

    Используем, конечно 🙂 Несмотря на то, что временные параметры обработки заявок уже включают в себя приемлемые задержки, все равно изредка возникают ситуации, когда исполнители не успевают обработать ее в рамках SLA по не зависящим от них причинам (которые, к слову, бывают разнообразными).

    Поставить заявку на паузу может исключительно менеджер процесса, при этом исполнитель обязан описать необходимость продления срока. Заказчик, после перевода заявки в статус "ожидание" получает соответствующее уведомление. При таком варианте риск злоупотреблений крайне мал.

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

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

    • В расчете KPI мы считаем как и общее время обработки, так и реальные трудозатраты по заявкам (в рамках привязанных задач). В статусе "ожидание" счетчик останавливается.

      Наргиза, если я правильно понял Ваш ответ, то:

      1. при расчете KPI по общему времени обработки время ожидания исключается;

      2. в расчет трудозатрат оно и не попадает.

      Или я запутался? И если запутался, и в KPI по общему времени обработки ожидание все же включается, как построен KPI (формула для расчета и как выполняется оценка)?

      • Nargiza Suleymanova

        Дмитрий, все верно 🙂 Никакой путаницы.

        • Но тогда как ваши KPI помогают контролировать злоупотребления ожиданиями? :-\

          • Nargiza Suleymanova

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

  • Альберт

    1. Да

    2. Автоматические отчёты

    3. Основной показатель незакрытые в течение недели инциденты. Если инцидент попадает в отчёт, то это повод для разбирательства.

    • 3. Основной показатель незакрытые в течение недели инциденты. Если инцидент попадает в отчёт, то это повод для разбирательства.

      Альберт, разрешите пару уточняющих вопросов:

      1. Разбирательство не зависит от того, было ли при обработке данного обращения ожидание? Важем сам факт, что оно не было закрыто, так?

      2. Как быть с обращениями, по которым ожидание в течение недели было (и, возможно, было слишком длинным или необоснованным), но к концу недели обращение было закрыто? Этот факт в ходе указанного Вами разбирательства ведь не "всплывет", верно?

      • Альберт

        1. Верно, но это уже другая история. Если ожидания не было и инцидент не закрыт в течение недели, то он скорее всего попадает в другой отчёт о нарушении SLA.

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

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

          А как Вы узнаете, что он приближается к критическим? Ожидание останавливает таймер, поэтому угрозы просрочки нет. Значит, если других отклонений / угроз отклонений не произойдет (типа возврата на доработку, жалобы пользователя и так далее), ожидание так и останется незамеченным. В том числе неоправданное ожидание, введенное исполнителем в личных целях выиграша по времени. Не так?

          • Альберт

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

  • Андрей

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

    • Это само собой (о чем и написано в тексте). Но я все больше сталкиваюсь с ситуациями, когда этого недостаточно.

  • Николай

    1. Да, на время ожидания запроса доп.информации у инициатора, таймер останавливается.

    2. Административно выделено подрязделение – 1я линия поддержки, которая обрабатывает все заявки, поступающие от пользователей по всей стране. Регистрирует обращения и эскалирует инциденты на 2ю линию. Если исполнителю на 2й линии нужна дополнительная информация от пользователя, то инцидент возвращается на 1ю линию (запрос доп.информации может отправлять только 1я линия поддержки), соответственно, эти люди и контролируют обоснованность такого запроса. Запросом может быть  как уточнение информации по заявке, так и запрос о времени, когда будет предоставлен доступ в помещение и т.п. Существуюет у пользователей определенной категории (сотрудники розничных точек) KPI по времени ответа на эти запросы.

    3. Отдльного KPI для ИТ по количеству запросов и злоупотреблениям – не существует. Как показывает практика, достаточного того, что 1я линия никак не зависит от руководителей ИТ в филиалах (2я линия).

  • Владимир

    У нас нет остановки таймера (в Hold), зато есть функция переноса крайнего срока решения с заполнением комментария по переносу срока и функция демонстрации этого комментария Заявителю. Конечно, этим в ~25% случаях злоупотребляют, иногда пишут в комментариях бред. Контролировать комментарии трудоемко. Как выход из ситуации, наверное, нужно сделать выпадающий список причин для переноса сроков, доступный для выбора конкретного значения. Второй вариант – запретить переносить срок решения, и сделать при закрытии обращения обязательный к заполнению комментарий к причинам нарушения срока решения, если он был нарушен, возможно, тоже выбираемый из списка. В качестве у нас также KPI используется – кол-во переносов срока решения.

    Hold и попытки посчитать чистое время выполнения обращения, по моему мнению, к объективным цифрам не приводят.

    Пользуясь случаем, хочу задать вопрос: как правильнее – включать или не включать время согласования перед выполнением обращения во время решения обращения?

    • В качестве у нас также KPI используется — кол-во переносов срока решения.

      Владимир, два вопрса:
      1. Как именно выглядит KPI (формула)?
      2. Что препятствует однократному переносу срока на длительное время?

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

      • Владимир

        1. Нет никакой формулы: как только переносится срок, срабатывает счетчик переноса срока. Если счетчик отличается от нуля, значит срок переносился, нужно смотреть комментарий к переносу срока.

        2. Многократные переносы сроков, в основном, связаны с изменением планов разработки (реализация переносится из одного релиза ПО в другой: вперед выполняются более приоритетные задачи). Также есть "технические" переносы: пользователя нет на месте, нет ответа на уточняющие вопросы, подводит поставщик/смежник, закупка связана с заключением Договора/проведения тендера. Также просто "договорились с Заявителем", не указывая деталей.

        Срок переносится у ~10% обращений. Для 70% обращений, срок исполнения которых переносился – хвататет переноса одного раза.

  • Андрей

    Таймер стоит при запросе доп инфо по обращени, а так же если обращение приходится отложить по причине выполнения запроса аутсорсингом или инфм прияинам. Контроль со стороны руководителя Сервис Деск, какждый отложенный запрос должен содержать причину или номера ТТ аутсорсинга.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM