Мария спрашивает:
Как можно перевести статусы инцидентов "Pending Other (ожидание другого исполнителя?) ", "Referred (передан на рассмотрение)", " Resolved (решен)", т.е. к каким ситуациям их применять? Мы используем систему HPSM и решили расшифровать статусы для исполнителей. Быстро найти в интернете адекватную информацию не удалось.
Буду благодарна за помощь!
Уважаемые специалисты по адаптации жизни к HPSM и по статусам инцидентов – предлагайте варианты, пожалуйста!
Мария! Наличие запасного колеса в автомобиле не означает, что его надо обязательно куда-то приладить :-)!
По опыту миграции одного из заказчиков с HPOV (не HPSM, как у Вас, но тенденция налицо!) мы несколько лишних статусов просто ликвидировали. Хотя заказчику было трудно принять это. За сокращение каждого лишнего статуса мы "сражались" до хрипоты почти. Казалос бы, нам -то какое дело. Но тем не менее. Если я вижу, что где-то можно сократить лишнюю информацию, итерацию и т.д., мы всегда рекомендуем настоятельно прислушаться к голосу разума.
Андрей абсолютно прав. Если Вы задаете такой вопрос, то скорее всего Вам эти статусы вообще не нужны. Возьмите и замерьте с секундомером, сколько времени тратит сотрудник на изменение 1 статуса (если он, конечно, не автоматически проставляется). Затем умножте это время на планируемое количество тикетовс учетом того что в статус может потребоваться перключаться 2-3 и более раз. И затем умножьте на нормочас сотрудника поддержки. И получите и стоимость в деньгах, и общее время задержки обработки запросов.
Разумеется, есть минимум миниморум по набору статусов для обеспечения процесса. Но, судя по вопросу в заголовке, речь идет как раз о лишних статусах.
Так что вариант один – ревизия и оптимизация процесса, а потом уже решать, нужны ли эти статусы вообще. Может Вам вообще другие статусы нужны.
Ну, Алексей, вопрос в заголовке – это произвол редакции портала (в этот раз – в моем лице). Мария ведь спрашивает про три конкретных статуса, их перевод и возможности применения. Поделитесь, что ваш опыт говорит про них? Статусы-то действительно неоднозначные!
Роман, такой произвол несколько сбивает с толку (у меня было ощущение диссонанса между темой и содержанием), но нисколько не отменяет всего того, что я сказал.
Конкретно по этим статусам:
1. Статус Resolved (Решено) вызывает меньше всего вопросов. Это статус который четко фиксирует решения инцидента на стороне ИТ. Не факт, что успешно, т.к. клиент может и не принять работу. А если ищет Мария рациональности, тогда другое дело.
2. Pending Other – разговор ни о чем. А вот заменить его на Pending Customer (Ожидание клиента) вполне логично для случаев когда в силу специфики работы мы можем (или должны) запросить у клиента дополнительную информацию. И этот статус должен влиять на отсчет времени SLA. А ожидание чего бы то ни было на стороне ИТ мало волнует клиента и может вполне решать ся сменой ответственного по запросу или перемещением в другую функциональную группу для решения. И все эти действия фиксируются для дальнейшей отчетности, но сам статус избыточен. Для ИТ и так должно быть ясно, что происходит с тикетом, а Клиенту это, извините, "по барабану".
3. Статус Reffered вообще как-то не вяжется с целью процесса управления инцидентами ("скорейшее разрешение и т.д."). Сам физичкеский факт передачи с любой целью какого-либо инцидента фиксируется сменой исполнителя либо передачей в другую группу, как в п.2
Прошу обратить внимание, что к HPSM я отношения не имею никакого. Я занимаюсь другим продуктом, но здравый смысл говорит, что "бери больше – будет лучше" хорошо только при строительстве мостов. А про оптимизацию производительности сервесной службы я написал уже выше. Важно четко понимать, что любая излишняя, избыточная "хотелка" оплачивается из кошелька владельца бинеса, о чем многие предпочитают не думать. А зачем? Работу работаем, KPI, которые, зачастую, ИТ сами себе и придумываем, даем "на гора". Ну и славненько.
Может и оффтоп слегка. Просто вспомнился воркшоп (ITSMF Конф-2010 кажется) по одному из первых решений по управлению активами на HPSM в одной из "росатомных" контор. Там по факту было несколько в активах серверов и около 100 ПК + оргтехника. Заказчик сознался под давлением участников (ну стали люди вопросы задавать, что и как было), ближе к концу, а интегратор очень засмущался. После этого откровения народ потянулся к выходу…
Так и здесь. Если задача состоит в том, чтобы заставить HPSM "отрабатывать номер", то можно и оставить такой перевод, как Мария сама и предложила.
А можно удалить этот вариант?
Роман, такой произвол несколько сбивает с толку (у меня было ощущение диссонанса между темой и содержанием), но нисколько не отменяет всего того, что я сказал.
Конкретно по этим статусам:
1. Статус Resolved (Решено) вызывает меньше всего вопросов. Это статус который четко фиксирует решения инцидента на стороне ИТ. Не факт, что успешно, т.к. клиент может и не принять работу.
2. Pending Other – разговор ни о чем. А вот заменить его на Pending Customer (Ожидание клиента) вполне логично для случаев когда в силу специфики работы мы можем (или должны) запросить у клиента дополнительную информацию. И этот статус должен влиять на отсчет времени SLA. А ожидание чего бы то ни было на стороне ИТ мало волнует клиента и может вполне решать ся сменой ответственного по запросу или перемещением в другую функциональную группу для решения. И все эти действия фиксируются для дальнейшей отчетности, но сам статус избыточен. Для ИТ и так должно быть ясно, что происходит с тикетом, а Клиенту это, извините, "по барабану".
3. Статус Reffered вообще как-то не вяжется с целью процесса управления инцидентами ("скорейшее разрешение и т.д."). Сам физичкеский факт передачи с любой целью какого-либо инцидента фиксируется сменой исполнителя либо передачей в другую группу, как в п.2
Прошу обратить внимание, что к HPSM я отношения не имею никакого. Я занимаюсь другим продуктом, но здравый смысл говорит, что "бери больше – будет лучше" хорошо только при строительстве мостов. А про оптимизацию производительности сервисной службы я написал уже выше. Важно четко понимать, что любая излишняя, избыточная "хотелка" оплачивается из кошелька владельца бинеса, о чем многие предпочитают не думать. А зачем? Работу работаем, KPI, которые, зачастую, ИТ сами себе и придумываем, даем "на гора". Ну и славненько.
Может и оффтоп слегка. Просто вспомнился воркшоп (ITSMF Конф-2010 кажется) по одному из первых решений по управлению активами на HPSM в одной из "росатомных" контор. Там по факту было несколько в активах серверов и около 100 ПК + оргтехника. Заказчик сознался под давлением участников (ну стали люди вопросы задавать, что и как было), ближе к концу, а интегратор очень засмущался. После этого откровения народ потянулся к выходу…
Так и здесь. Если задача состоит в том, чтобы заставить HPSM "отрабатывать номер", то можно и оставить такой перевод, как Мария сама и предложила. А если ищет Мария рациональности, тогда другое дело.
Добрый день! Спасибо большое за ответы, все внимательно прочитала! В HPSM действительно большой выбор статусов, мы ищем подходящие для своих целей и хотим понимать смысл каждого статуса. поэтому и возник этот вопрос. Полученные комментарии обязательно учтем!
По-моему, здесь не вопрос адаптации к жизни какого-либо программного продукта. Мы же отлично знаем, что не правильно пытаться подстроить процессы под средство автоматизации. Поэтому вопрос в обратную сторону: А какие статусы вам-то нужны? Что вы ими хотите сделать? Какие нужны, так и называйте. А лишние выключите.
В SM, как и в любом другом средстве, по умолчанию заложена некоторая логика. А уж как ее использовать и использовать ли ее вообще решать вам.