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

Обработка нестандартных запросов на обслуживание

Рафхат спрашивает у знатоков-практиков процесса управления запросами на обслуживание:


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

Какая практика обработки запросов существует в подобных случаях? Как правильно/прозрачно/просто донести до автора запроса об увеличении сроков исполнения запроса и при этом корректно считать соответствующую метрику процесса?


ITIL, конечно же, напоминает, что There will always be grey areas which prevent generic guidance from being usefully prescribed (SO, Request Fulfillment, 4.3.2). Но мы-то сможем помочь практическим советом?

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

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

  • Андрей Шилов

    В моем представлении Заказчика не очень интересует состав сущностей/процессов, задействованных для его обслуживания. Важнее четкое понимание границы между стандартной функциональностью услуги, подпадающей под целевые сроки, и нестандартной – возможно, требующей от ИТ специальных усилий/ресурсов.

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

    Если соглашение – одно, ограничения фиксируются в спецификациях конкретных услуг.

    Про донесение информации об обработке до инициатора – либо закрывать первоначальное обращение и информировать о ходе обработки связанного изменения, либо НЕ закрывать обращение (и тогда что-то делать с его нормативным сроком). Общий принцип – адекватно информировать в случае, если запрос вышел за рамки стандартных.

    Имхо.

  • Рафхат, мне известны три способа:

    1. Нормируется время первичной оценки запроса на изменение, а не полной его реализации. Тогда поступил запрос, мы его оценили и в установленный срок выдаем ответ “да, принимаем запрос к дальнейшей обработке” или “нет, не принимаем”. После предоставления ответа исходный запрос закрывается. Если решение положительное, создается связанный объект “Изменение” и дальнейшее взаимодействие выполняется в рамках обработки изменения. Такой метод широко используется для запросов, связанных с заказом доработок ИС.

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

    3. Отказ от нормирования времени исполнения запросов, требующих реализации изменения. В этом случае срок исполнения запроса должен корректироваться по ходу реализации изменения. Такой подход не очень удобен с точки зрения исполнителей, зато предъявляет меньше требований к системе автоматизации ITSM-процессов и подходит в случаях, когда у вас не нормирована длительность первичной оценки RFC.

    Какой-то из этих вариантов Вам подходит?

    • Рафхат

      Способы подходят

    • Рафхат

      1. Правильно я понимаю, что автору запроса предоставляется ответ о его исполнении или озвучивается время исполнения без уведомления о фактическом исполнении? 

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

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

      • 1. Почему же – с уведомлением. В уведомлении решение о приеме либо отказе от приема к реализации запроса на изменение.

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

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

        С технической точки зрения ответ зависит от того, устраивает ли Вас для реализации стандартных изменений функцинальность запросов на обслуживание (планирование дочерних заданий, средства согласования и прочее). Если устраивает, то можно и не переводить. ИМХО.

        • Рафхат

          1. Тут все понятно. Видимо необходимо только решить для себя вопрос по поводу уведомления о фактическом исполнении запроса.

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

           

          “…устраивает ли Вас для реализации стандартных изменений функцинальность запросов на обслуживание…”

          Вот тут у меня совсем картинка не сложилась. Речь идет о наличии ПО (например на уровне SD), которое позволяет реализовывать стандартное изменение? Или подразумевается что то иное?

          • Имеются ли статьи по поводу реализации контроля?

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

            Вот тут у меня совсем картинка не сложилась.

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


Добавить комментарий для РафхатОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM