ITPARK.ru - ERP форум  - ITIL форум  
ITSM база знаний и Форум Параметры  |  Регистрация  |  Посетители  |  Поиск  |  Помощь
    |- Service support > Service desk, Incident management и Problem management Разместить новый топик   Post A Reply
Known-Error Показать принтер версию
next newest post | next oldest post
Автор Сообщение
Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 13:23:25  

В Prob.Mgmt одозначен выход - Известная ошибка (Known-Error)...
А какому процессу эта ошибка поступает на вход?
Я что-то не нашел....
Василий Аксенов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 15:07:29  

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

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

Михаил Завьялов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 15:38:01  

на вход Change Management поступает не известная ошибка (Known-Error), а запрос на обслуживание (RFC)... а информация по известным ошибкам и обходным решениям попадает в Incident Management...
Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 17:19:03  

В Change действительно поступает RFC, в котором предлагаются изменения для устранения известной ошибке.
В Inc. поступает "responce from Icident matching to Problem and Known Errors", собственно сама причина Inc.Mgnt не интересует, ему решение или обход подавай...
Понятно, что сам Prob. Mgnt управляет известными ошибками, есть даже специальная деятельность "Error control", где ошибки записываются и отслеживается их устранение. Но это внутренняя информация.
Опять-таки понятно, что на основе известной ошибки создается RFC... Значиь ли это, что изместная ошибка поступает на вход какого-то процесса, отличного от Prob.Mgnt, чтобы "превратиться в RFC"?
Кому же все-таки нужены Known Errors???

Еще мнения будут?

[Edit by Владимир Вильчинский on Вторник, Март 25, 2003 @ 17:28:43]

Николай Крачун
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 18:12:03  

Если формально - Known-Error (как выход Prob.Mgmt) попадает на вход Configuration M.
"Нужны " Known Errors естественно в первую очередь Incident M.
К слову, инструмент (tool) по ITIL-автоматизации для получения PinkVerify должен "...facilitate the automated matching of incidents to problems and known errors".

Также требуется для принятия решений по соответств-му RFC - т.е. для Change: "...facilitate the association and maintenance of the relationships between known errors records and RFCs." и еще: "...When a change has been successfully implemented does the tool facilitate the closure of all associated known error records?" (оттуда же).

И, само собой, Known Errors нужны самому Problem - этот "выход" одной его activity "идет на вход" других. Но - через CMDB.

То, что это пишется именно в CMDB, пишет например Микрософт (если для кого это аргумент): "...Problem management updates the CMDB as resolutions or workarounds to problems and known errors are found. The service desk can then use this information to resolve future incidents. " и еще: "...an organization tracks all problems, known errors, and incident information in the CMDB. Keep in mind that the CMDB is not necessarily a single repository, but rather a collection of databases that are tied together as a single relational database. " (Все это см. на http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/idc/oag/oagc14.asp ).

Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 19:31:58  

Quote:
Originally posted by Николай Крачун

Если формально - Known-Error (как выход Prob.Mgmt) попадает на вход Configuration M.
"Нужны " Known Errors естественно в первую очередь Incident M.
К слову, инструмент (tool) по ITIL-автоматизации для получения PinkVerify должен "...facilitate the automated matching of incidents to problems and known errors".


В конфиг попадают с целью сохранить там информацию, никакого преобразования в конфиге с KE не происходит. А в инцидентах нужны не КЕ, а Workaround'ы по ним. Вот про соответствие я уже писал выше, нужно отметить все те инциденты, по которым решение (КЕ) найдено, чтобы а дальнейшем устранять подобные предложенным способом.
Quote:

Также требуется для принятия решений по соответств-му RFC - т.е. для Change: "...facilitate the association and maintenance of the relationships between known errors records and RFCs." и еще: "...When a change has been successfully implemented does the tool facilitate the closure of all associated known error records?" (оттуда же).

Опять, ИМХО речь идет о связи (пометке), что данный RFC устраняет указанную КЕ.
Quote:

И, само собой, Known Errors нужны самому Problem - этот "выход" одной его activity "идет на вход" других. Но - через CMDB.

Тоже правильно, но зачем вытаскивать этот выход "неружу" из процесса?
Quote:

То, что это пишется именно в CMDB, пишет например Микрософт (если для кого это аргумент): "...Problem management updates the CMDB as resolutions or workarounds to problems and known errors are found. The service desk can then use this information to resolve future incidents. " и еще: "...an organization tracks all problems, known errors, and incident information in the CMDB. Keep in mind that the CMDB is not necessarily a single repository, but rather a collection of databases that are tied together as a single relational database. " (Все это см. на http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/idc/oag/oagc14.asp ).

Полностью согласен. Мне кажется, что под управление Конфига нужно отдавать все информационные ресурсы всех процессов. Только в этом процессе есть деятельности, которые могут обеспечить "правильное хранение и своевременное обновление" БД.
Для меня вопрос все еще остается? Мысли крутятся вокруг Capacity и "базы знаний" для SD, и SLM...
Будем искать и думать.
Николай Крачун
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 20:24:00  

Quote:
В конфиг попадают с целью сохранить там информацию, никакого преобразования в конфиге с KE не происходит.

Ну и что? Все равно занесение информации в CMDB происходит в рамках процесса Conf.M., т.к. только он устанавливает правила и контролирует эту деятельность.

Quote:
А в инцидентах нужны не КЕ, а Workaround'ы по ним.

И то и другое. Пока нет workaround'a полезно знать хотя бы, что такой-то инцидент имеет известную корневую причину и "над ним работают". Кроме того, описание KE помогает SDesk'у делать workaround'ы (это его, Inc.M., работа).

Quote:
Опять, ИМХО речь идет о связи (пометке), что данный RFC устраняет указанную КЕ.

Пральна, ни больше и не меньше.

Quote:
Тоже правильно, но зачем вытаскивать этот выход "неружу" из процесса?

Чтобы сохранить "hard copy" этой инфы :)
Оно ж только через Conf.M., Вы сами писали, что ...
Quote:
под управление Конфига нужно отдавать все информационные ресурсы всех процессов. Только в этом процессе есть деятельности, которые могут обеспечить "правильное хранение и своевременное обновление" БД.

Quote:
Для меня вопрос все еще остается? Мысли крутятся вокруг Capacity и "базы знаний" для SD, и SLM...
Будем искать и думать.

Честно говоря, не вижу в чем именно вопрос.
Конечно эта инфа и другими процессами юзается (например, SLM отслеживает время пребывания KE в ожидании закрытия), но это уже "высший пилотаж". А на уровне Service Support - IMHO разобрали.
Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 25, 2003 @ 22:49:51  

Вот что смущает:
1. Work-around, который необходим Inc. на выходе Prob. не значится, правда есть Problem record (including a solution and/or any avalible Work-around). Зато (или вместе стем) КЕ на выходе обозначена.
2. В Inc. Mngt дается определение Known Error - "A Problem that is successfully diagnosed and for wich a Work-around is known". Т.е. успешно решенная проблема? Не само решение, не обход, а ЧТО?
3. Последний гвоздь в мозги забивает рисунок:

Error in Infracnhfcture --> IncidentS --> Problem --> Known Error --> RFC --> Structural Resolution

Выходит, что из КЕ формируется RFC, вроде бы правильно. Означает ли это, что есть накие КЕ для которых Prob. самостоятельно не может открыть RFC? Т.е. не может предложить конкретное изменение? В этой связи вспоминается всякая (функциональная и организационная) эскалация.
Пример. Порвали враги оптоволокно, сервисы восстановлены через какой-то модем. Может ли Prob. предложить RFC? Наверное нет, значит результат работы процесса - КЕ.
А вот в каком процессе по этому КЕ, скажем, откажутся от предоставления (временного) ряда сервисов или проедут изменения в SLAs...
Не тут ли "собака порылась"?

Николай Крачун
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 26, 2003 @ 11:08:26  

Quote:
Вот что смущает:
1. Work-around, который необходим Inc. на выходе Prob. не значится, правда есть Problem record (including a solution and/or any avalible Work-around). Зато (или вместе стем) КЕ на выходе обозначена.

Обходной путь обычно создается в Inc.m., а в Problem только проверяется его оптимальность.
В Problem'е люди больше "думают" чем "делают", поэтому их главная работа - разобраться почему что-то не то, а как это обойти - Inc.M. сам справится.

Quote:
2. В Inc. Mngt дается определение Known Error - "A Problem that is successfully diagnosed and for wich a Work-around is known". Т.е. успешно решенная проблема? Не само решение, не обход, а ЧТО?

Действительно, в некоторых местах пишут о жесткой связи "Known Error " <-> "Work-around". Однако на самом деле на практике это параллельные сущности, поэтому иногда может быть KE без Workaround'а, а обычно - есть Workaround хотя Проблема еще не "инвестигирована".

Quote:
3. Последний гвоздь в мозги забивает рисунок:
Error in Infracnhfcture --> IncidentS --> Problem --> Known Error --> RFC --> Structural Resolution

Это диаграмма "с точки зрения" Problem M. Деятельность показанная третьей стрелочкой (от Prob. к KE) это "Investigation and Diagnostics". Ее главная задача - понять в чем корневая причина проблемы. Отсюда вытекает единственно полное и достаточное определение KE - это проблема с известной корневой причиной. Не больше и не меньше.

Quote:
Выходит, что из КЕ формируется RFC, вроде бы правильно.

Ну, не "из" а "на основании". :)

Quote:
Означает ли это, что есть накие КЕ для которых Prob. самостоятельно не может открыть RFC? Т.е. не может предложить конкретное изменение? В этой связи вспоминается всякая (функциональная и организационная) эскалация. Пример. Порвали враги оптоволокно, сервисы восстановлены через какой-то модем. Может ли Prob. предложить RFC? Наверное нет, значит результат работы процесса - КЕ.

Правильно, если "не может" в смысле "RFC не нужен". Термин "Эскалация" мне кажется не надо употреблять, когда речь идет о взаимодействии процессов, а тут именно оно. В Вашем примере КЕ пойдет на вход процесса управления Underpinning Contracts (если волокно арендуется).

Quote:
А вот в каком процессе по этому КЕ, скажем, откажутся от предоставления (временного) ряда сервисов или проедут изменения в SLAs... Не тут ли "собака порылась"?

Тоже возможный вариант - обычно бывает, если корневая причина "не чинится". Тогда - КЕ идет на вход SLM.

Важный момент - решение о том, что делать с этой КЕ, принимает именно Prob.M.
То есть он либо генерит RfC - меняйте, либо "возбуждает" Operations (свой или внешний) - чините, либо извещает SLM - все плохо, (пере)договаривайтесь.

Михаил Завьялов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 26, 2003 @ 16:45:56  

Quote:
Тоже возможный вариант - обычно бывает, если корневая причина "не чинится". Тогда - КЕ идет на вход SLM

может всетаки на основании KE формируется RFC, который отправляется в ChM, а от туда информация попадает в SLM?
Николай Крачун
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 26, 2003 @ 18:49:20  

...Тоже возможный вариант - обычно бывает, если корневая причина "не чинится". Тогда - КЕ идет на вход SLM...

Quote:
Originally posted by Михаил Завьялов
может всетаки на основании KE формируется RFC, который отправляется в ChM, а от туда информация попадает в SLM?


Нет, не всегда. Представьте себе - куплено коробочное ПО, протестировано, добавлено в DSL, дописано в SLA, введено в эксплуатацию. Только через месяц - повисло намертво - инцидент. Перегрузили, работает. Еще через месяц - та же картина. Уже явная проблема. Проблем М. лезет на user forums и читает - известный глюк этого ПО, оно каждые 33 дня виснет :)

Это коробка, патча ждать незнамо сколько. Какой RfC предлагаете писать?!
Ответ - никакой. Надо отправить этот known error в SLM, чтоб они в SLA приписочку организовали, в графе "макс. допустимое количество инцидентов" - "... + раз в месяц из-за нелечимого глюка ПО".
И Change'у тут только и делать, что потом изменение в RfC отконтролить.

Михаил Завьялов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Март 27, 2003 @ 13:39:58  

Quote:
Это коробка, патча ждать незнамо сколько. Какой RfC предлагаете писать?!
Ответ - никакой. Надо отправить этот known error в SLM, чтоб они в SLA приписочку организовали, в графе "макс. допустимое количество инцидентов" - "... + раз в месяц из-за нелечимого глюка ПО".

любое изменение SLA - это изменение стоимости услуги. Может проще было бы воспользоваться обходным решением, например: каждый 33-й день переходить на резервную копию данного ПО. Кто будет оценивать соотношение стоимости?
Николай Крачун
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Март 27, 2003 @ 14:38:46  

Quote:
Originally posted by Михаил Завьялов
любое изменение SLA - это изменение стоимости услуги.

Не всегда. Например, в случае внутренего ИТ-подразделения понятия "стоимость услуги" может не быть (хотя себестоимость конечно есть и она контролируется). Кроме того, в Соглашении о внесении изменений в SLA может быть оговорено, что минорные изменения/дополнения на общую стоимость не влияют (обычно в каких-то границах).

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

Change. Если Problem придумал work-around, а SLM подготовил изменения - решение принимает Change (может запросить инфу у Fin.Man.).

Вообще в ИТИЛ во многих местах проглядывает искаженное (ессесно IMHO) соотношение SLM <-> Change.
Фразы типа "...Change reports to SLM..." могут создать впечатление, что SLM "главнее", хотя на самом деле наибольшие полномочия имеет Change.
Тут дело скорее всего в том, что SLM выше на шкале зрелости и у авторов кое-где проскакивает желание "подчинить" Change Управлению Сервисами. Вечный конфликт продажников с операционщиками :)

Михаил Завьялов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Март 27, 2003 @ 17:00:26  

Quote:
Не всегда. Например, в случае внутренего ИТ-подразделения понятия "стоимость услуги" может не быть (хотя себестоимость конечно есть и она контролируется).

она должна быть. Именно "стоимость", а не "себестоимость". Другое дело, как оформлять финансовые отношения. Но оценка стоимости услуги должна быть.
Quote:
Change. Если Problem придумал work-around, а SLM подготовил изменения - решение принимает Change (может запросить инфу у Fin.Man.).

так собственно и я об этом. отправляем RFC в ChM и пусть они разбираются что выгоднее: поменять структуру или SLA.
Quote:
Фразы типа "...Change reports to SLM..." могут создать впечатление, что SLM "главнее", хотя на самом деле наибольшие полномочия имеет Change.

IMHO смысл этой фразы, что информация поступает из ChM в SLM, а не то, что кто-то кому-то подчинен или главнее.
Николай Крачун
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Пятница, Март 28, 2003 @ 11:22:58  

Quote:
она должна быть. Именно "стоимость", а не "себестоимость". Другое дело, как оформлять финансовые отношения. Но оценка стоимости услуги должна быть.

Сильно сказано, но - бездоказательно. ;) Докажите, убедите, please...

Quote:
так собственно и я об этом. отправляем RFC в ChM и пусть они разбираются что выгоднее: поменять структуру или SLA.

Да, при условии, что есть возможность изменения инфраструктуры (CI и/или их связей) для решения проблемы. Тогда появится RfC и будет проведено его сравнение с SLA change. А Ваш пример - не RfC а именно work-around.

Quote:
IMHO смысл этой фразы, что информация поступает из ChM в SLM, а не то, что кто-то кому-то подчинен или главнее.

Точно! Но к сожалению не все это понимают...

Михаил Завьялов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Суббота, Март 29, 2003 @ 13:40:09  

Quote:
Сильно сказано, но - бездоказательно. Докажите, убедите, please...

а в чем убеждать-то? если мы начнем с бизнес-пользователями говорить о себестоимости, то опять скатимся до: "стоимость починки копьютера Х руб.". Нас же интересует:"стоимость предоставления услуги 'работающий компьютер' - У руб.". Попробуй объяснить, что себестоимость идеально предоставленой услуги (без инцидентов) будет такой же, что и с оговоренным в SLA, разрешенным количеством инцидентов. А если есть стоимость, то какая разница сколько мы потратили на ее поддержание, стоит она одинаково.
Quote:
Да, при условии, что есть возможность изменения инфраструктуры (CI и/или их связей) для решения проблемы. Тогда появится RfC и будет проведено его сравнение с SLA change. А Ваш пример - не RfC а именно work-around.

э нет. work-around, это кода инцидент произошел и мы знаем что нужно предпринять, чтобы его устранить. А когда мы знаем, что можно предпринять некие превинтивные шаги ("каждый 33-й день переходить на резервную копию"), чтобы инцидента вообще не появлялось, то это уже change.
Николай Крачун
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Понедельник, Март 31, 2003 @ 10:34:24  

Quote:
... если мы начнем с бизнес-пользователями говорить о себестоимости, то опять скатимся до: "стоимость починки копьютера Х руб.". Нас же интересует:"стоимость предоставления услуги 'работающий компьютер' - У руб."...

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

Quote:
Попробуй объяснить, что себестоимость идеально предоставленой услуги (без инцидентов) будет такой же, что и с оговоренным в SLA, разрешенным количеством инцидентов. А если есть стоимость, то какая разница сколько мы потратили на ее поддержание, стоит она одинаково.

Что-то я Вашего рассчета стоимости не понял. Как Вам удастся за одни и те же деньги обеспечивать 10 инцидентов в месяц или ни одного?!

Quote:
... work-around, это кода инцидент произошел и мы знаем что нужно предпринять, чтобы его устранить. А когда мы знаем, что можно предпринять некие превинтивные шаги ("каждый 33-й день переходить на резервную копию"), чтобы инцидента вообще не появлялось, то это уже change.

Нет, workaround бывает и проактивный.
Разница между ними скорее в постоянстве вносимых в инфраструктуру изменений.
Посмотрите внимательнее определения:
"Workaround - Method of avoiding an incident or problem, either from a temporary fix or from a technique that means the Customer is not reliant on a particular aspect of a service that is known to have a problem."
"Change - The addition, modification or removal of approved, supported or baselined hardware..."
Разместить новый топик   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 и начинают.
Текущих активных посетителей: 10
Всего текущих 0 посетителей и 10 гостей на сайте. | Большинство пользователей когда-либо было 167 on 04-10-2008 22:55:22
Поиск на этом форуме
Поисковые слова: Искать за:
Powered by CuteCast v2.0 BETA 2
Copyright © 2001-2003 ArtsCore Studios
Все права защищены.
GALPRO ©2003-2018

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