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

Как регистрировать дополнительные независимые заявки в тех поддержку, возникающие во время решения основной?

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

Добрый день!

От инженеров, использующих систему регистрации заявок (СРЗ) для выполнения нарядов, поступил кейс, верное решение которого не получается определить однозначно.

Часто специалисты выезжающие на места, приходя по одной заявке, делают еще 10. Это происходит потому что другие сотрудники, узнав о том, что специалист тех. поддержки где-то рядом, вспоминают, что у них тоже давно тормозит компьютер или не хватает какого-то ПО (т.е. услуги могут быть самыми разными). Инженеры попросили разработчиков СРЗ дать им возможность самостоятельно заводить себе наряды на такие вот случаи. Это, с одной стороны, позволит не просить заявителя «оставить заявочку», а с другой, точно зафиксирует оказанные услуги.

По результатам выполнения такого наряда заявителю будет отправляться уведомление о выполнении заявки с просьбой оценить или отклонить ее выполнение (как обычно). Т.е. совсем бесконтрольно заводить наряды инженер не сможет.

Насколько правильно давать инженерам такую возможность? Может у кого-то был подобный опыт?

Сейчас такие работы или не учитываются вовсе, или инженер, выполняя просьбу заявителя, в свою очередь, просит его оставить заявку в SD (о чем заявитель может благополучно забыть). Не делать, потому что нет заявки — не вариант (заявку оставят потом и придется ехать снова). Есть еще вариант: инженер сам звонит/пишет и оставляет заявку от имени заявителя.

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

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

  • Sergey

    Нормальная ситуация и нормальное решение. Либо инженер сам заведёт заявку (обязательно от имени пользователя), либо попросит пользователя (пока решает его заявку) зарегистрировать свою.

  • Елена

    Лучше всего дать инженерам возможность регистрировать запросы от имени пользователя — и чтобы пользователю обязательно приходили уведомления о необходимости подтвердить выполнение.

  • Дмитрий

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

    То есть это значит, что люди, даже испытывая трудности, просто не принимают такой подход к получению ИТ услуг как SD. Тогда, конечно необходимо оставлять инженерам возможность создавать запросы самим. Однако, я бы например, ограничил их каким-нибудь лимитом, чтобы не превратить это уже в инструмент для того, чтобы делать то, что хочется, а не то, что нужно бизнесу. Даже если будет приходить уведомление об оценке, не факт, что пользователь эту оценку сделает (это из опыта)! Ведь, если он не создает заявки, то скорее всего он совсем не работает в SD.

    В дальнейшем, этот лимит нужно было бы уменьшать до минимума, постепенно проводя методологическую работу со своими внутренними клиентами по повышению их зрелости во взаимодействии с ИТ.


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

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

  • Рубрики

  •  
  • Авторы

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

    • Куда растворился Access management в ITIL4?
      Коллеги, доброго дня. Неожиданный вопрос: куда растворился Access management в ITIL4? В практике Request Mgmt есть упоминание о том, что запросы на доступ управляются в практике Security Mgmt, но в описании этой практики нет об этом ничего, кроме управления инцидентами безопасности и аудита и ревью. Есть легкий намек, что эта практика используется в access control.
    • Конференция «Качество данных 2022. Стратегии, инструменты, практики, перспективы»
      Приглашаем принять участие в третьей ежегодной конференции «Качество данных 2022. Стратегии, инструменты, практики, перспективы». «Качество данных» – единственная в России конференция, полностью посвященная стратегии и практике обеспечения качества данных, гарантирующего высокий уровень бизнес-решений, сервисов и процессов. «Качество данных 2022» – это совершенно новые практические кейсы и проекты в развитии, привлекшие наибольший интерес участников предыдущих конференций.
    • Лучшие материалы Digital Enterprise за 2021 год
      Редакция Digital Enterprise поздравляет Вас с наступающим Новым годом! В этом посте мы собрали ТОП 5 авторских публикаций от экспертов Cleverics и 10 самых популярных статей портала в этом году.
    • Cleverics. Сколько курсов пройти, чтобы точно хватило?Сколько курсов пройти, чтобы точно хватило?
      В IT невозможно дойти до предела совершенства — всегда есть куда расти. Основная сложность в работе специалиста IT в том, что IT очень изменчивая область. Вам необходимо постоянно учиться, чтобы выжить во всем этом — и не остаться в колесе Сансары, когда оно будет делать новый оборот.
    • Почему запуск продукта проваливается (и как этого избежать)
      Сколько запусков новых продуктов происходит каждый год? По данным Nielsen около 30 000 среди товаров повседневного спроса. Для программного обеспечения гораздо труднее найти
    • Российскому стандарту ITAM быть!
      Управление ИТ-активами (ITAM), как дисциплина, существует уже не первое десятилетие. Однако в силу ряда причин именно сейчас ИТ-организации начинают проявлять к нему все больший практический интерес. Почему ИТ-менеджеры сейчас обращают на ITAM пристальное внимание?
    • Здравствуй, (VUCA) Новый год!
      Каждый раз, провожая уходящий год, хочется оглянуться назад, посмотреть на то, что было и попробовать помечтать и спрогнозировать то, что будет (или может быть) в новом году.
    • Возврат в системе канбан
      Что делать на доске канбан с задачей, по которой требуется переделка?
    • Записи вебинаров 21 сезона CleverTALK
      16 декабря завершился двадцать первый сезон вебинаров CleverTALK. Благодарим вас за интерес к нашим вебинарам и за то, что делитесь информацией о них!
    • Играйте в деловые игры ответственно
      Мы довольно давно проводим различные деловые игры. Надо сказать, что они действительно учат делать правильные выводы. И эти выводы рождаются благодаря приобретаемому опыту. Один
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT