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

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

Добрый день,

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

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

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

Спасибо.

ITIL ITIL Intermediate: Operational Support and Analysis

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

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

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

  1. Николай Шаповалов

    Добрый день,

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

    1. Alexey

      Спасибо!

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

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

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

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

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

  2. Alexander

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

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

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

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

  3. 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

  4. 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. Пока детали не знаем. Ждём следующие книги как там распределены действия и ответственность по ролям.

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

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

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

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

НОЯ
18
Учебный курс:
Release, Control and Validation (ITIL RCV)