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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;