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

Как организовать работу с нестандартными запросами?

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

Добрый день,

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

Часто не совсем ясно, как провести грань между проектом и изменением (не всегда очевиден объем и масштаб работ).

Поделитесь опытом, как у вас организовано формирование очереди работ,  как прогнозируются сроки решения. Как «вклиниваются» срочные задачи.

Спасибо.

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Николай Шаповалов

    Добрый день,

    Долго боролись с подобной ситуацией — в итоге вышли на рабочую схему — все стандартизированные запросы идут через стандартную тикетинг систему. Если попадается нестандартный запрос (не попадает под SLA) — идем в отдельный процесс — где реквестора просим объяснить «что, как и почему?» (с обязательным указанием ожидаемых выгод для комании) он просит, документируем это все, а дальше приоритизируем на анализ вместе с пулом остальных проектов.

    • Alexey

      Спасибо!

      >>дальше приоритезируем на анализ вместе с пулом остальных проектов.

      * что такое «на анализ»?

      * как часто разбираете «пул проектов»?

      * используете ли процесс «Запросов на изменения» и «Изменения» (Change management)?

      * как поступаете при появлении срочного проекта\изменения, как пересматриваете и смещаете сроки?

  • Alexander

    Если запрос действительно нестандартный, нет описанных случаев в БЗ, но косвенно относится к какой либо услуге или сервису — начальнику заявителя задается вопрос «на сколько увеличится, к примеру, ros компании, если выполнить данный запрос?»

    в результате ответа 99% таких запросов отменяется.

    Да, сурово, местами не клиентоориентированно, но ставит перед фактом и помогает отсеять неадекватов, тех, кто не подумал перед заведением тикета и тд

    Компания 300к персонала.

  • Sinan Aliyev

    * используете ли процесс «Запросов на изменения» и «Изменения» (Change management)?

    Если нестандартный запрос (а чаще всего именно так) ведёт к изменению, то заполняется форма RFC с Change Proposal, если форма RFC не хватает для оисания причины запроса. Change Proposal может фактически быть и Business Case-ом. То есть включать в себя cost, риски, issues , benefits и другие аспекты.

    Фактически это Normal change. Далее рассматриваем в рамках процесса Change Management. Называется это Change Evaluation (Таблица 4.13 в книге Service Transition). Далее по процессу как указано в ST, Change Management, Figure 4.2

  • Sinan Aliyev

    Если по результату понимаем что normal change стоит ценности (оценили introduced risks vs removed risks, introduced cost vs removed risks, affected outcomes vs supported outcomes) прикреляем наш анализ к RFC , RFC к Project Charter и запускаем проект. Всё это контролирует и мониторит Change Management. В конце и по ходу исполнения результат проекта показываем инициатору RFC, при утверждении что он получил то что хотел закрываем RFC и проект.

    В версии ITIL4 теперь задействованы две практики — это Change Control и Organizational Change Management. Пока детали не знаем. Ждём следующие книги как там распределены действия и ответственность по ролям.


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

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

  • Рубрики

  •  
  • Самое свежее

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT