Для тех, кто не любит ждать

 

Есть такая практика — включать в число статусов обрабатываемых объектов (инциденты, обращения, задания/наряды на работы и т.д.) статус "Ожидание". Задача, которую решает этот статус, простая: обеспечить участникам процессов возможность отложить в сторону обрабатываемый объект в ситуации, когда по каким-то причинам его обработка пока невозможна. Например, ждем, пока пользователь вернется из отпуска или ждем, пока будет поставлена техника и т.д. В общем, найти разумное объяснение существованию этого статуса можно. Однако понятна и обратная сторона такой возможности: появляется способ отлынивать от работы. Традиционный способ сокращения халтуры — обязать переводящего в статус "Ожидание" указывать причину перевода. Однако при наличии богатой фантазии отдельные личности наверняка придумают миллион способов обойти это ограничение. К тому же проверка причин перевода в ожидание потребует от проверяющего (например, менеджера) определенных трудозатрат, зависящих от количества проверяемых объектов. 

В итоге разумным решением кажется следующее:

  • переводить в статус "Ожидание" может только ограниченный круг лиц, например, руководители функциональных групп после получения объяснения от своих сотрудников;
  • должен выполняться регулярный контроль наличия объектов, которые переводились в подобный статус с последующей (возможно выборочной) проверкой обоснованности применения данного статуса.

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

Есть два варианта: останавливать время, сдвигая срок дальше на продолжительность времени ожидания, либо не останавливать. Если время останавливать, то "как смотреть потом в глаза Заказчикам"? Ведь обещали решить за 6 часов, а в ожидании инцидент пробыл два дня пока ждали. Если не останавливать, то что дает этот статус?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

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

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

  1. Anton Lykov

    Что касается способов контроля и минимизации «халявы»: на мой взгляд, хорошая практика — при переводе в статус «Ожидание» указывать планируемую длительность ожидания, чтобы система по истечении этого срока выталкивала задание обратно в статус «Направлен в группу» или «В работе» (в какой именно — можно обсуждать, есть варианты).

    А по длительности — в каких-то используемых у нас суппортных системах я встречал два статуса: «Pending customer» и «Pending provider». Т.е., ждём заказчика и ждём по каким-то внутренним причинам (например, создали запрос внешнему поставщику и ждём, пока он там починит у себя что-то). Срок по SLA в первом случае можно честно продлять, а причину показывать заказчику. Во втором случае — срок по SLA, разумеется, не изменяем.

    По-моему, более или менее логично.

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

    Плюсую к Антону. Ещё одно хорошее решение для предотвращения недобросовестного использования статуса «Ожидание» — не просто требовать сформулировать причину, но отправлять пользователю уведомление о том, что его обращение мы больше не обрабатываем по указанной причине. Пользователи быстро помогут выявить нарушителей «Женевской конвенции по правам человека» 🙂

    0
    0
  3. Pavel Solopov

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

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

    Что касается вопроса останавливать или нет время. То всё зависит от ситуации.

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

    Всё также зависит от существующих правил, политик и договорённостей.

    Может ли тех-поддержка влезать в ПК пользователя во время его отсутствия или нет?

    Должен ли поставщик хранить запас запчастей или они покупаются по согласованию с заказчиком и т.д.

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

    0
    0
    1. Анатолий Павлюченко

      Соглашусь и добавлю, что часто забывают о том, что SLA — это двухсторонний договор, а не только обязательства ИТ службы. Т.е. вполне логичным выглядит не останавливать срок исполнения, а статус «Ожидание» использовать как статистическую информацию при «разборе полётов» как для одной сотроны договора, так и другой.

      0
      0
  4. Сергей Посыльный

    Мы в статусе Ожидание вообще отключили перенос времени, при подходе срока специалист (на контроле Лидера команды) обязан перенести срок (обязательно связавшись с пользователем и получив его согласие — то есть по сути продлив договоренность по SLA), если пользователь не согласен Спец. передаёт (с соответствующей записью) Лидеру команды который может продлить срок (SLA) по согласованию со Службой Заказчика (часто пользователю безразлично есть или нет техника а Служба Заказчика более вменяема, естественно суть переговоров и решение фиксируется в истории).

    Если пользователь отсутствует ещё может непосредственный начальник пользователя подтвердить продление «крайнего срока».

    Если уж и СЗ не подтверждает продления -тогда считаем что SLA нарушен.

    В любом случае на комитете качества — такие ситуации разбираются в основном в пользу «невиновных и непричастных».

    0
    0
  5. Alexander Peshkov

    Добрый день.

    Схема работы со статусом Ожидание отточена и работает весьма успешно.

    1. Чтобы исключить маскировку безобразия фиговым листочком, в первые месяцы мы не останавливали счетчик, но никому об этом не сказали. Таким образом, все натянутые за уши ожидания выявлялись по итогам каждого месяца, проводилась разъяснительная работа.

    2. Определили круг причин, объективно позволяющих ставить в ожидание с остановкой SLA. Это ожидание пользователя, ожидание поставки, ожидание административного решения (например, согласование доступа с ДИБ), замечательная причина ожидания «Отложено» (договорились с пользователем, что выполним в следующем году). Теперь нужно выбрать, где останавливать SLA, а где нет. Конечно же, не останавливать во втором случае. Пооокааа.

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

    4. Периодический просмотр причин ожидания на предмет всякой дряни («.», «-», «,,,^oo^,,,» и тп) дает эффект вкупе с Положением о премировании, в котором прописано условие следования стандартному процессу для получения премий. Всякие отклонения и нестандартные причины становятся быстро известны, так же и благодаря пользователям, которые моментально отправляют то, что им непонятно в СЗ, а она устраивает поиски виноватых.

    Вот такая схема. Работает.

    0
    0
    1. Alexander Peshkov

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

      0
      0

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

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

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

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

НОЯ
27
Учебный курс:
Основы ITIL (очно)