ITPARK.ru - ERP форум  - ITIL форум  
ITSM база знаний и Форум Параметры  |  Регистрация  |  Посетители  |  Поиск  |  Помощь
    |- Service support > Service desk, Incident management и Problem management Разместить новый топик   Post A Reply
Incident mgmt - activity2 Показать принтер версию
next newest post | next oldest post
Автор Сообщение
Konakov
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Август 1, 2002 @ 12:45:19  

Второй вид деятельности в управлении инцидентами - классификация инцидента.

Мое понимание: на этом этапе сначала проверяется, не прислал ли пользователь RFC. Если да, отправить в change mgmgt. Если нет, классифировать его, оценить "угрозу" инцидента, попытаться решить его (так и хочется написать "на халяву" - поискать похожий решенный инцидент, применить собственные смекалку и сообразительность :) ). Если удалось решить - закрыть. Не удалось - переправить инцидент тому, кто сможет решить.

Это в целом.

[Edit by Konakov on Пятница, Август 2, 2002 @ 11:19]

[Edit by Konakov on Пятница, Август 2, 2002 @ 11:20]

Konakov
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Пятница, Август 2, 2002 @ 13:12:05  

Теперь тонкости.

Классификация. По-моему, цель классификации: определить, кому передать инцидент для решения. Поскольку решение может быть найдено без передачи инцидента специалисту, предлагается такой алгоритм: по умолчанию инцидент получает признак "не классифицирован" (красиво: "не классифицирован за ненадобностью") и service desk просто не задумывается над этим. Если service desk не нашел решение инцидента и передает его специалистам, то тут уже надо присвоить какой-нибудь признак.

prusak
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Август 21, 2002 @ 12:02:06  

У нас в подразделении (HelpDesk Вымпелкома) классификация введена для решения двух задач: 1-я - классификация для задач дальнейшего анализа (Отчетность). 2-я - "Маршрутизация проблемы".
Причем наша классификация опирается не на CI, а на сервисы.
Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Август 21, 2002 @ 17:56:11  

А у вас инциденты и запросы на изменение разделены?
prusak
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Август 21, 2002 @ 18:07:21  

Да, несомненно.
База Incident Management разработана для регистрации только Инцидентов. Следующий шаг - система Problem Management и т.д.. Создаются они - как общеинтегрированный продукт.
Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Август 21, 2002 @ 18:27:49  

Я немного не об этом спросил.

Есть поток, как бы их назвать, запросов. Все они (в идеале) приходят в service desk и регистрируются. После чего производится сортировка на RFC и инциденты. Разницу между ними я понимаю так:
Инцидент - это когда что-то сломалось и надо приложить усилия, чтобы выяснить что сломалось, как это починить, починить и устранить последствия.
RFC - это когда пользователь только просит дать ему то, что может сломаться в дальнейшем. Выяснять, КАК это сделать, не нужно (например, подключить принтер), есть стандартная процедура, нужно только получить санкцию на этот change.

prusak
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Август 21, 2002 @ 18:50:27  

Да, делятся.
В нашей компании есть два варианта: есть подразделене, которые занимается только укрупненными запросами (т.е. к ним де-факто такие (частные) RFC не попадают), заводятся укрупненные проблемы компании;
есть подразделение, которое "возится" с пользовательскими запросами. В нем регистрируются весь поток - в качестве "обращений". Они уже, в свою очередь, могут превращаться в Тикеты - инциденты или получать статус RFC.
Евгений Крылов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Август 21, 2002 @ 21:38:32  

Инцидент - это когда что-то сломалось и надо приложить усилия, чтобы выяснить что сломалось, как это починить, починить и устранить последствия.
------
Инцидент-это любое событие, которое не является частью стандартных операций по предоставлению сервиса и которое вызывает или может вызывать прерывание сервиса или уменьшение его качества.
--------
Устрание инцидента может быть произведено использованием обходного пути (workaround) так, что не обязательно это "починить". Например PC можно заменить на другой.
---------
RFC - это когда пользователь только просит дать ему то, что может сломаться в дальнейшем. Выяснять, КАК это сделать, не нужно (например, подключить принтер), есть стандартная процедура, нужно только получить санкцию на этот change.
[/B][/QUOTE]

---------
По поводу санкции - верно. Но кто ее дает?

Термины: из IT Service Management, an introduction. Publication of: itSNF-international, May 2002.

"Service Requests (here: standard changes)- fully defined and approved changes, which are individually recorded, but not individually assessed by Change Management. These changes are made routinely. (Note: not all Service Reaquests are changes.)
Requests For Change - all other requests for modidfication of the managed infrastructure."

Леонид Точилов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Август 21, 2002 @ 22:44:55  

"Service Requests (here: standard changes)- fully defined and approved changes, which are individually recorded, but not individually assessed by Change Management. These changes are made routinely. (Note: not all Service Reaquests are changes.)
Requests For Change - all other requests for modidfication of the managed infrastructure."
--------------------
Пример:
Вышестоящая организация запросила информацию:
вариант 1: она собирается и может быть получена по
(Service Requests)
вариант 2: она не собирается и необходимо а) как-то ее быстро получить б) организовать процесс ее сбора в дальнейшем с назначением ответственных(Requests For Change)

--------------------

Евгений Крылов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Август 22, 2002 @ 10:26:29  

Quote:
Размещено prusak
Да, делятся.
В нашей компании есть два варианта: есть подразделене, которые занимается только укрупненными запросами (т.е. к ним де-факто такие (частные) RFC не попадают), заводятся укрупненные проблемы компании;
есть подразделение, которое "возится" с пользовательскими запросами. В нем регистрируются весь поток - в качестве "обращений". Они уже, в свою очередь, могут превращаться в Тикеты - инциденты или получать статус RFC.

Иными словами - нет единой точки входа для RFC. Так?

Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Август 22, 2002 @ 10:51:14  

Большая просьба не сваливать все в кучу!
Предлагаю сделать так: я открою топик про incident mgmt в целом, и там напишу (перепишу из ITIL) какие в нем activities, а частные вопросы по кажому виду деятельности предлагаю обсуждать в отдельных топиках. Например, прием запросов здесь: http://itsm.itpark.ru/cgi-bin/cutecast/cutecast.pl?forum=1&thread=34.

Тема текущего топика - классификация. Кто как классифицирует? Почему? Может быть, вместе мы найдем лучший способ?

Евгений Крылов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Август 22, 2002 @ 10:56:19  

Quote:
Размещено Сергей Конаков
[B]Большая просьба не сваливать все в кучу!

А что свалено?
Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Август 22, 2002 @ 11:13:15  

...нет единой точки входа для RFC.

По-моему, это все таки не к классификации относится.

Евгений Крылов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Август 22, 2002 @ 11:22:57  

Давайте разберемся
http://itsm.itpark.ru/cgi-bin/cutecast/cutecast.pl?forum=1&thread=45#1
Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Август 22, 2002 @ 18:31:00  

Вроде бы разобрались.

Итак, обращение получено и зарегистрировано. Теперь надо его классифицировать - т.е. понять, что с ним делать.
1) Выяснить легальность (Был случай, когда от техподдержки одной местной софтовой компании пользователь хотел чтобы ему решили проблему по другой, но тоже бухгалтерской системе. Мотивировка: я же вам деньги плачу), т.е. наличие контракта.
2) Выяснить, не RFC ли это или service request, т.е. ничего не надо расследовать, надо просто передать этот запрос на санкционирование.

Есть возражения?

Леонид Точилов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Пятница, Август 23, 2002 @ 21:31:15  

Quote:
Размещено Сергей Конаков
Вроде бы разобрались.

Итак, обращение получено и зарегистрировано. Теперь надо его классифицировать - т.е. понять, что с ним делать.
1) Выяснить легальность (Был случай, когда от техподдержки одной местной софтовой компании пользователь хотел чтобы ему решили проблему по другой, но тоже бухгалтерской системе. Мотивировка: я же вам деньги плачу), т.е. наличие контракта.
2) Выяснить, не RFC ли это или service request, т.е. ничего не надо расследовать, надо просто передать этот запрос на санкционирование.

Есть возражения?

Да. По-моему у eskrylov уже звучало: INC, RS, RFC.

prusak
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Воскресенье, Август 25, 2002 @ 14:35:26  

>Итак, обращение получено и зарегистрировано. Теперь надо его классифицировать - т.е. >понять, что с ним делать.
>1) Выяснить легальность (Был случай, когда от техподдержки одной местной софтовой >компании пользователь хотел чтобы ему решили проблему по другой, но тоже бухгалтерской ?>системе. Мотивировка: я же вам деньги плачу), т.е. наличие контракта.
>2) Выяснить, не RFC ли это или service request, т.е. ничего не надо расследовать, надо >просто передать этот запрос на санкционирование.

3) Классификация.
Практика показывает возможность создания классификации по 2-м типам: либо по воздействию на клиентский сервис(ex., "проблемы с BeePay"), либо - по затронутому оборудованию (Ex.,"FrameRelay/PassportNet/Passport4400"). И в том, и в другом случае целесообразно создание деревьев (для наглядности). Во втором случае также целесообразно "прикрутить" ссылки на базу CI? для ведения истории инцидентов по тому или иному затронутому узлу.

Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Понедельник, Сентябрь 2, 2002 @ 14:46:43  

Как бы сначала что ли все начать.

Итак, обращение зарегистрировано и проверено на легальность: выяснили, что это наш клиент и мы ему будем помогать.

Классификация:
1) инцидент - передаем специалистам для решения

дальше мне не совсем понятно
2) service request - предаем специалистам для выполнения (исполнения)?
3) RFC - передаем в Change mgmt? Т.е. в Incident mgmt вообще это не рассматриваем?

Евгений Крылов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Понедельник, Сентябрь 2, 2002 @ 20:59:06  

Quote:
Размещено Сергей Конаков
Как бы сначала что ли все начать.

Итак, обращение зарегистрировано и проверено на легальность: выяснили, что это наш клиент и мы ему будем помогать.

Классификация:
1) инцидент - передаем специалистам для решения

дальше мне не совсем понятно
2) service request - предаем специалистам для выполнения (исполнения)?
3) RFC - передаем в Change mgmt? Т.е. в Incident mgmt вообще это не рассматриваем?

service request - это разновидность инцидента.
RFC - передаем в Change mgmt. но фиксируем в HD (SD)

Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Сентябрь 3, 2002 @ 16:29:41  

Quote:
Размещено prusak
У нас в подразделении (HelpDesk Вымпелкома) классификация введена для решения двух задач: 1-я - классификация для задач дальнейшего анализа (Отчетность). 2-я - "Маршрутизация проблемы".
Причем наша классификация опирается не на CI, а на сервисы.

Если пока не трогать отчетность, то классифицируем для правильной маршрутизации. Обычно получается, что есть исторически сложившаяся структура (группы специалистов), которая и выполняет работу. Имеет ли смысл просто отразить эту структуру в схеме маршрутизации (а ведь придется - маршрутизировать-то надо) или есть мнения, что ее нужно перед этим как-то изменить?

Никита Кузьмин
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Сентябрь 4, 2002 @ 02:36:30  

В том-то и дело, что автоматизация предполагает уточнение и процедурное закрепление существующих структурных связей между родразделениями. Как их иначе построить? Важно, чтобы была единая точка входа (HD), которая бы ведала вопросами маршрутизации запросов.
Классификация проводится на HD, причем (как правило) в 90% случаев всю матрицу ТраблШутинга оператор HD обязан держать в голове (это надо требовать!), а в оставшихся случаях - руководствовался исчерпывающей процедуройЮ где вся инфа есть.

Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Сентябрь 4, 2002 @ 09:46:41  

А зачем между ними связи? Если инцидент не в области компетенции данной группы, они просто отправляют его обратно в SD. Т.е. связь нужна между группой и SD.
Леонид Точилов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Воскресенье, Сентябрь 8, 2002 @ 11:57:41  

Предлагаю от понятия классификация перейти к более конкретному понятию Классификатор для HD. По-моему основные вопросы от которых надо отталкиваться при его формировании:
Что - когда? (варианты того что может случиться и планируемое время на устранение)
Кто - кому? (кто будет устранять - кто принимать)
Не классифицируемый инцидент оператор должен "временно классифицировать", исходя из своего опыта. Утвердить временную классификацию должен по-моему Problem mgnt.
Таким образом классификатор должен постоянно совершенствоваться.

--------------------

Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Понедельник, Сентябрь 9, 2002 @ 18:14:12  

классификатор должен постоянно совершенствоваться

Абсолютно согласен!

Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Сентябрь 11, 2002 @ 13:07:25  

Я "ответвил" обсуждение влияния инцидента:
http://itsm.itpark.ru/cgi-bin/cutecast/cutecast.pl?forum=13&thread=65
Сергей Конаков
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Пятница, Сентябрь 13, 2002 @ 17:28:41  

По поводу классификации.

Если делать маршрутизацию на основе каталога сервисов (то есть определили, какой сервис нарушен - инцидент автоматически направляется в соответствующую группу), то зачем тогда классификация? Для отчетности? Если да, то для какой?

Леонид Точилов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Пятница, Сентябрь 13, 2002 @ 22:01:28  

Наименование сервиса, который нарушен и идентификация клиента - начало классификации. То, что по каждому сервису есть своя группа, которая закроет инцидент не учитывает сложность организации CI. Классификация должна доводить до конкретной CI, либо давать подсказку, что смотреть. Для этого пользователя можно, в частности, попросить пользователя ответить было ли такое раньше, другие наводящие вопросы. Наверное, классификатор не даст конкретную CI (это будут выяснять специалисты), но уровень все-же должен быть более глубокий, чем идентификация сервиса.

--------------------

Разместить новый топик   Post A Reply Перейти к:
Написать вебмастеру | ИТСМ форум | Политика Privacy All times are GMT +4 Hours.
Добро пожаловать на форум, Guest!  
Login
Имя :
Пароль :
Чтобы пользоваться нашим форум необходимо зарегистрироваться! Пришлите заявку.В заявке необходимо указать имя и фамилию, и желательно место работы.

Уведомление о регистрации вас на форуме и логин будут высланы на ваш E-mail!
Имя и пароль регистрозависимы!
Правила форума здесь.
Forum Rules & Description
Who Can Read The Forum? Any registered user or guest
Who Can Post New Topics? Any registered user
Who Can Post Replies? Any registered user
Who Can Edit Posts? Any original author
Одно подразделение и два процесса. Часто именно с Service Desk и начинают.
Текущих активных посетителей: 2
Всего текущих 0 посетителей и 2 гостей на сайте. | Большинство пользователей когда-либо было 167 on 04-10-2008 22:55:22
Поиск на этом форуме
Поисковые слова: Искать за:
Powered by CuteCast v2.0 BETA 2
Copyright © 2001-2003 ArtsCore Studios
Все права защищены.
GALPRO ©2003-2018

Яндекс.Метрика