Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

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

    • Как обучать команду удаленно
      Обучение — это важный обряд посвящения, который проходит каждый новый сотрудник, чтобы узнать о своей новой роли и обязанностях, встретиться со своими товарищами по команде и …
    • Книга Cleverics про метрики и KPI рекомендована слушателям MBA по направлению ИТ
      Вышедшая в начале года книга Дмитрия Исайченко и Павла Демина «Управление услугами на основе измерений» получила рекомендацию от Высшей школы бизнес-информатики НИУ ВШЭ в качестве …
    • Определяем полюс потребителя
      При анализе и построении «путешествия заказчика» (customer journey) одной из важнейших задач является получение ответов на ряд вопросов, а именно: кто конкретно …
    • Семь распространённых мифов о DevOps
      В сообществе разработчиков бытует множество мифов о DevOps. И это и неудивительно, учитывая, сколько новшеств привнесла эта концепция за последние годы. DevOps — это …
    • Разрешение конфликтов в Agile-командах
      Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при …
    • Очередность прохождения курсов ITIL 4
      Имеет ли значение, в каком порядке проходить курсы по ITIL? Рассказывает аккредитованный тренер по ITIL 4 Игорь Фадеев. Cleverics — первая в России и одна из первых в …
    • 1 октября конференция «Роботизация бизнес-процессов 2020»
      1 октября 2020 издательство «Открытые системы» проведет ежегодную конференцию «Роботизация бизнес-процессов 2020» https://www.osp.ru/iz/rpa2020, где на одной площадке будут …
    • ITIL® 4 DITS — огонь, вода и медные трубы
      Мы уже писали о скором релизе последнего экзамена в сертификационной линейке ITIL 4 Digital and IT Strategy (DITS). Сейчас стоит добавить следующее (из информации, которую можно …
    • Как бизнес-аналитику встроиться в гибкую среду?
      Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики  зачастую считают, что они должны …
    • Деловая игра Grab@Pizza: вкусный кейс
      Деловые игры – один из наиболее эффективных видов тренинга, позволяющий на основе близкого к реальному кейса попрактиковаться в выстраивании любой работы. Участники деловой игры …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT