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

Как применить статусы, раз уж они есть?

Мария спрашивает:

Как можно перевести статусы инцидентов "Pending Other (ожидание другого исполнителя?) ", "Referred (передан на рассмотрение)", " Resolved (решен)", т.е. к каким ситуациям их применять? Мы используем систему HPSM и решили расшифровать статусы для исполнителей. Быстро найти в интернете адекватную информацию не удалось.

Буду благодарна за помощь!

Уважаемые специалисты по адаптации жизни к HPSM и по статусам инцидентов – предлагайте варианты, пожалуйста!

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Андрей

    По-моему, здесь не вопрос адаптации к жизни какого-либо программного продукта. Мы же отлично знаем, что не правильно пытаться подстроить процессы под средство автоматизации. Поэтому вопрос в обратную сторону: А какие статусы вам-то нужны? Что вы ими хотите сделать? Какие нужны, так и называйте. А лишние выключите. 

    В SM, как и в любом другом средстве, по умолчанию заложена некоторая логика. А уж как ее использовать и использовать ли ее вообще решать вам.

  • Alexey Yusov

    Мария! Наличие запасного колеса в автомобиле не означает, что его надо обязательно куда-то приладить :-)!

    По опыту миграции одного из заказчиков с HPOV (не HPSM, как у Вас, но тенденция налицо!) мы несколько лишних статусов просто ликвидировали. Хотя заказчику было трудно принять это. За сокращение каждого лишнего статуса мы "сражались" до хрипоты почти. Казалос бы, нам -то какое дело. Но тем не менее. Если я вижу, что где-то можно сократить лишнюю информацию, итерацию и т.д., мы всегда рекомендуем настоятельно прислушаться к голосу разума.

    Андрей абсолютно прав. Если Вы задаете такой вопрос, то скорее всего Вам эти статусы вообще не нужны. Возьмите и замерьте с секундомером, сколько времени тратит сотрудник на изменение 1 статуса (если он, конечно, не автоматически проставляется). Затем умножте это время на планируемое количество тикетовс учетом того что в статус может потребоваться перключаться 2-3 и более раз. И затем умножьте на нормочас сотрудника поддержки. И получите и стоимость в деньгах, и общее время задержки обработки запросов.

    Разумеется, есть минимум миниморум по набору статусов для обеспечения процесса. Но, судя по вопросу в заголовке, речь идет как раз о лишних статусах.

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

    • Ну, Алексей, вопрос в заголовке – это произвол редакции портала (в этот раз – в моем лице). Мария ведь спрашивает про три конкретных статуса, их перевод и возможности применения. Поделитесь, что ваш опыт говорит про них? Статусы-то действительно неоднозначные!

      • Alexey Yusov

        Роман, такой произвол несколько сбивает с толку (у меня было ощущение диссонанса между темой и содержанием), но нисколько не отменяет всего того, что я сказал.

        Конкретно по этим статусам:

        1. Статус Resolved (Решено) вызывает меньше всего вопросов. Это статус который четко фиксирует решения инцидента на стороне ИТ. Не факт, что успешно, т.к. клиент может и не принять работу. А если ищет Мария рациональности, тогда другое дело.

        2. Pending Other – разговор ни о чем. А вот заменить его на Pending Customer (Ожидание клиента) вполне логично для случаев когда в силу специфики работы мы можем (или должны) запросить у клиента дополнительную информацию. И этот статус должен влиять на отсчет времени SLA. А ожидание чего бы то ни было на стороне ИТ мало волнует клиента и может вполне решать ся сменой ответственного по запросу или перемещением в другую функциональную группу для решения. И все эти действия фиксируются для дальнейшей отчетности, но сам статус избыточен. Для ИТ и так должно быть ясно, что происходит с тикетом, а Клиенту это, извините, "по барабану".

        3. Статус Reffered вообще как-то не вяжется с целью процесса управления инцидентами ("скорейшее разрешение и т.д."). Сам физичкеский факт передачи с любой целью какого-либо инцидента фиксируется сменой исполнителя либо передачей в другую группу, как в п.2

        Прошу обратить внимание, что к HPSM  я отношения не имею никакого. Я занимаюсь другим продуктом, но здравый смысл говорит, что "бери больше – будет лучше" хорошо только при строительстве мостов. А про оптимизацию производительности сервесной службы я написал уже выше. Важно четко понимать, что любая излишняя, избыточная "хотелка" оплачивается из кошелька владельца бинеса, о чем многие предпочитают не думать. А зачем? Работу работаем, KPI, которые, зачастую, ИТ сами себе и придумываем, даем "на гора". Ну и славненько.

        Может и оффтоп слегка. Просто вспомнился воркшоп (ITSMF Конф-2010 кажется) по одному из первых решений по управлению активами на HPSM в одной из "росатомных" контор. Там по факту было несколько в активах серверов и около 100 ПК + оргтехника. Заказчик сознался под давлением участников (ну стали люди вопросы задавать, что и как было), ближе к концу, а интегратор очень засмущался. После этого откровения народ потянулся к выходу…

        Так и здесь. Если задача состоит в том, чтобы заставить HPSM "отрабатывать номер", то можно и оставить такой перевод, как Мария сама и предложила. 

         

      • Alexey Yusov

        Роман, такой произвол несколько сбивает с толку (у меня было ощущение диссонанса между темой и содержанием), но нисколько не отменяет всего того, что я сказал.

        Конкретно по этим статусам:

        1. Статус Resolved (Решено) вызывает меньше всего вопросов. Это статус который четко фиксирует решения инцидента на стороне ИТ. Не факт, что успешно, т.к. клиент может и не принять работу.

        2. Pending Other – разговор ни о чем. А вот заменить его на Pending Customer (Ожидание клиента) вполне логично для случаев когда в силу специфики работы мы можем (или должны) запросить у клиента дополнительную информацию. И этот статус должен влиять на отсчет времени SLA. А ожидание чего бы то ни было на стороне ИТ мало волнует клиента и может вполне решать ся сменой ответственного по запросу или перемещением в другую функциональную группу для решения. И все эти действия фиксируются для дальнейшей отчетности, но сам статус избыточен. Для ИТ и так должно быть ясно, что происходит с тикетом, а Клиенту это, извините, "по барабану".

        3. Статус Reffered вообще как-то не вяжется с целью процесса управления инцидентами ("скорейшее разрешение и т.д."). Сам физичкеский факт передачи с любой целью какого-либо инцидента фиксируется сменой исполнителя либо передачей в другую группу, как в п.2

        Прошу обратить внимание, что к HPSM  я отношения не имею никакого. Я занимаюсь другим продуктом, но здравый смысл говорит, что "бери больше – будет лучше" хорошо только при строительстве мостов. А про оптимизацию производительности сервисной службы я написал уже выше. Важно четко понимать, что любая излишняя, избыточная "хотелка" оплачивается из кошелька владельца бинеса, о чем многие предпочитают не думать. А зачем? Работу работаем, KPI, которые, зачастую, ИТ сами себе и придумываем, даем "на гора". Ну и славненько.

        Может и оффтоп слегка. Просто вспомнился воркшоп (ITSMF Конф-2010 кажется) по одному из первых решений по управлению активами на HPSM в одной из "росатомных" контор. Там по факту было несколько в активах серверов и около 100 ПК + оргтехника. Заказчик сознался под давлением участников (ну стали люди вопросы задавать, что и как было), ближе к концу, а интегратор очень засмущался. После этого откровения народ потянулся к выходу…

        Так и здесь. Если задача состоит в том, чтобы заставить HPSM "отрабатывать номер", то можно и оставить такой перевод, как Мария сама и предложила.  А если ищет Мария рациональности, тогда другое дело.

         

  • Мария

    Добрый день! Спасибо большое за ответы, все внимательно прочитала! В HPSM действительно большой выбор статусов, мы ищем подходящие для своих целей и хотим понимать смысл каждого статуса. поэтому и возник этот вопрос. Полученные комментарии обязательно учтем!


Добавить комментарий для Роман ЖуравлёвОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM