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

Как соблюдать SLA в условиях ожидания ответа

В редакцию портала поступил вопрос:

Добрый день, коллеги! Подскажите как соблюдать SLA в условиях ожидания ответа от клиента/бизнеса. Например, определили опытным путем SLA по сервису «Настройка бухгалтерской базы» в 24 рабочих часа. То есть все обращения по этому сервису должны решатся в этот согласованный срок. В поддержку поступает обращение, классифицируется по этому сервису и в ходе решения обращения выясняется, что требуется настройка, затрагивающая учетную политику. Это требует согласования главного бухгалтера. Гл. бухгалтеру отправляется запрос на согласование, бухгалтер рассматривает согласование, например, в течение 72 или более часов. Что делать с обращением в таком случае? Ведь фактически срок SLA будет нарушен. Сейчас мы переводим такие обращения в статус «Ожидает ответа» и срок решения ставится на паузу. Но это плохая практика, так как под этот статус можно подогнать многие обращения: клиент не решил, клиент ждет согласования, клиент в отпуске, клиент заболел и т.д.

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

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

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • Сергей

    Приветствую.
    Для выявления трендов причин приостановки ввели для такого статуса – подстатусы (наиболее распространенные причины ожидания).
    Бороться обязали старших групп поддержки – регламентами (не реже одного раза в неделю актуализировать записи в заявках находящихся в ожидании – что бы было видно что про заявку забыли – Старшие групп вынуждены теперь делать записи *например: напомнили пользователю письмом о том что ждём его реакции или направили поставщикам официальный запрос и т.д.*).
    Настаивали систему SD так что при переводе заявки в ожидание – обязательно указывался срок “до какого числа\времени” заявка переводится в этот статус – по достижении часа “Х” заявка автоматически возвращалась в работу (что б не забывали).
    Естественно контроль что “срок ожидания” не завышается и записи еженедельно актуализируются группами поддержки (и не по формальным признакам! тут требуется ручной аудит).
    Такими путями и Заказчик видит через SD нашу работу (что мы контролируем завки приостановленные) и специалисты не могут расслабиться ))

  • Виктор

    У нас используется 2 способа решения данного вопроса:
    1. Ожидание ответа от пользователя в течение суток. Если пользователь не ответил, обращение закрывается с комментарием, что в случае, если вопрос актуальный, пользователю необходимо создать новое обращение и (указывается чего не хватало для решения первоначального запроса);
    2. в системе заводятся разные услуги с разным уровнем сервиса и разными последовательностями. Например, пользователь хочет установить специфическое оборудование (редко используемое). Если оно у нас есть на складе, мы выбираем последовательность, состоящую из 2 нарядов (выдача со склада и установка нового оборудования), если же нет, то другую, состоящую из 3 нарядов, в которой к первым двум добавляется наряд на закупку.

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

  • Сергей

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

  • Владимир Невский

    У нас было в SLA было прописано так. Время выполнения Обращения по SLA может быть изменено в случаях:
    1. Согласовано с Заявителем (Заказчиком).
    2. Задачу нужно выполнить к определенному времени (раньше выполнить нельзя).
    3. Для выполнения задачи нужно дождаться выполнения другой работы/наряда (раньше выполнить нельзя/нецелесообразно).
    4. Задача решается установкой релиза/патча (установка невозможна без согласования с Бизнесом).
    5. Ожидание согласования (крайний срок решения обращения может быть сдвинут на срок проведения согласования).
    6. Ожидание ответа Заявителя на уточняющие вопросы (крайний срок решения обращения может быть сдвинут на Срок ожидания ответа Заявителя).
    Т.е. когда переносится крайний срок решения обращения – нужно выбрать категорию переноса и написать осознанный предметный комментарий, информацию которого можно было бы проверить. Конечно, это даёт некоторую возможность **** переносами сроков решения. Но при должном контроле и накладывании санкций за введение в заблуждение – процесс выглядит прозрачным и эффективным.

    • Владимир Невский

      Прошу прощения: звездочками движок сайта заменил слово “злоупотре+падшая женщина” 🙂

  • Роман

    1. У нас большая часть обращений пользователя в статусе “ожидание” привязано к заявке на доработку, заявке на изменение, к иному обращению, к запросу на согласование… в любом случае к сущности, которая имеет срок исполнения.
    2. Если исполнитель отправляет запрос заявителю, ответ ожидается 3 рабочих дня, если ответ не получен, то и не надо.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM