Разбор полётов или Post Incident Report.

Разбор полётов или Post Incident Report.
Продолжая тему внедрение процесса Управление Проблемами, хотелось бы остановиться на своего рода переходном отчете или другими словами Post Incident Report(PIR).
Данный отчет направлен на первоначальное анализ причин которые вызвали инцидент. Согласно утвержденного регламента он направляется на всех кто принимал участие в регистрации и устранении инцидента. Далее экспертом(экспертной группой) проводится анализ причин и формализируется в виде отчета. Данный анализ подразумевает ответы на следующие вопросы:

• причины инцидента есть следствие Известной Ошибки(Known Error)?
• причины инцидента не определены и это есть проблема?
• какое альтернативное решение имеет данный инцидент?
• какое влияние имеет данный инцидент на предоставление Сервиса?
  

Вот пример данного отчета :

№	Incident category/ System	Status and duration	Type incident impact & incident description	Reason	Possible or Real Impact description	Problem Identification

Колонка «Reason» заполняется следующим образом:

• Необходимо ответить на вопрос: «Какая нештатная ситуация в работе программно-аппаратного обеспечения вызвала полное или частичное прерывание в штатной работе Сервиса?»

Колонка «Possible or Real Impact description» заполняется следующим образом:

• В случае если нештатная ситуация имеет влияние на программное обеспечение, с которым работает ТС:
• Необходимо ответить на вопрос: Какая штатная функциональность Сервиса не доступна для работы пользователей?

• В случае если нештатная ситуация имеет влияние на производительность серверного программно-аппаратного комплекса (Server OS,Application Server, SMDB & etc.)
• Необходимо ответить на вопрос: Какая функциональность не может быть выполнена в штатном режиме работы программно-аппаратного комплекса.

Колонка «Problem Identification» заполняется следующим образом:

• В случае открытия и регистрации проблемы: Problem has been open: ID #, responsible person xxxxxxx, division xxxxxxx
• В случае решения не открывать проблему: Problem has no been opened. Reason: xxxxxx

Получателем этого отчета должна быть служба Service Desk она в свою очередь из него получает информацию о имеющихся проблемах и альтернативных решениях.

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

Сервис - что это?

В этом разделе речь пойдет о Сервисе.
Давай те все таки поглубже разберемся что из себя представляет сервис. Но для начала нам необходимо вспомнить что поскольку речь идет о внедрении ITIL и сама библиотека направлена на внедрение процессного подхода, то при внедрении процессов мы так или иначе отказываемся от функционального разделения бизнес-процессов, соответственно должны по новому взглянуть на наш функционал, который теперь будет одним целым для пользователя Сервисом. В чем же отличие Сервиса от Функционала?
Под Сервисом подразумевается перечень всех составляющих бизнес и операционных процессов. Т.е. если мы посмотрим на Сервис со стороны Бизнеса то увидим не что иное как набор инструментов, к слову сказать все эти инструменты(ИТ - ресурсы) мы (ИТ) предоставили Пользователю для работы, а именно:

1. Терминальное оборудование (рабочая станция, принтер, факс, сканер, телефонный аппарат, АТМ, или POS терминал и т.д.);
2. Канал связи (любой канал связи который необходим для осуществления доставки Сервиса пользователю);
3. Программное обеспечение (если оно необходимо);
   

Это был вид на Сервис со стороны Пользователя, для ИТ эти Сервисы состоят из множества других составляющих таких как серверное оборудование, серверное программное обеспечение, сервер приложений, сервер СУБД и многое другое.
Определение Сервиса как игла пронизывает все функциональные возможности ИТ для одного конкретного сервиса, но не определяет функции в частностях.
Стоит так же более подробно остановится на таких определениях как Бизнес Сервис и Операционный Сервис.
Бизнес Сервис - это набор функциональности и совокупность ИТ ресурсов для обеспечения одного конкретного сервиса который предоставляет пользователю возможность выполнить совокупность бизнес правил. Для примера обслуживание платежных карт. Это набор функциональстей которые позволят выполнить одну платежную операцию это может быть как снятие наличных с текущего счета , перевод платежных средств между счетами. Т.е. Вы конкретно и четко определяете Сервис обслуживание электронной карты, а то что в него входят дополнительные функции так же может быть выделено в отдельный Сервис если есть подобная необходимость отличать выполнение операций для клиента внутри какой то платежной системы или это выходит за рамки платежной системы.
Операционный Сервис - это сервис который может быть дополнением какого либо Бизнес Сервиса и позволяет выполнить функциональные (бизнес) правила или является низкоуровневым Сервисом для обеспечение доступности Бизнес Сервиса. К этому сервису относятся выполнение бизнес модели или предоставление канала связи или предоставление программного обеспечения которое позволит пользователю воспользоваться Бизнес Сервисом.

Сертификация Специалиста.

Экзамены

Очень важным и серьёзным шагом для каждого специалиста в сфере ИТ является подтверждение его квалификации и знаний соответствующим сертификатом. Для сертификации специалистов ИТ по процессам ITIL существует следующая система сертификации , она представлена на Рис. 1.

	ITIL Foundation Первая квалификационная ступень в подготовке специалистов по ITSM			ITIL Practitioner Support and Restore Для специалистов в области управления инцидентами, проблемами и Service Desk.
				ITIL Practitioner Release and Control Для специалистов в области управления изменениями, конфигурациями и релизами.
				ITIL Service Manager: ITIL Service Support ITIL Service Delivery Для менеджеров и консультантов в области ITSM, участвующих во внедрении и управлении процессами.

Рис.1 -> IT Expert

Для получения специализированных сертификатов в области управления различными процессами по методологии ITIL необходимо наличие сертификата начального уровня ITIL Foundation. Для получения его необходимо понимание основных процессов а так же их взаимосвязи между собой обязательным требованием к получению сертификата начального уровня является наличие опыта работы в сфере ИТ не менее 2-х лет.
Дополнительную информацию Вы узнаете на сайте компании http://www.exin-exams.com/

Оцените себя самостоятельно!

Оцените зрелость процессов ITIL в Вашей организации самостоятельно!!

На данном ресурсе Вам представиться уникальная возможность оценить зрелость своей организации на предмет внедрения на ней процессов ITIL . Данный ресурс предложит Вам оценить все аспекты Вашего ИТ и работы с ним, а так же поможет оценить направление в котором Ваша организация должна двигаться для улучшения качества услуг ИТ.

ITIL Service Management Self Assessment

http://www.itsmf.com/trans/questionlist.asp

Тематика :: ITIL :: SLA в практических примерах.

Тематика :: ITIL :: SLA в практических примерах.
SLA в практических примерах. для печати ссылки мнения В первую очередь надо предостеречь от бездумного применения нижепривеженных шаблонов и примеров к конкретной ИТ-организации. Без знания хотя бы основ теории и/или без учета специфики вы рискуете загубить благое начинание. Однако для лучшего понимания существа вопроса всегда полезно ознакомиться с чужим опытом. Все-таки ITIL - это именно "лучшие практики"... Итак, в Сети доступны: · Ссылки на статьи, отчеты, рекоммендации на nextslm.org · Процесс создания SLA на примере - Blueprint for an Exchange Service Level Agreement · SLA в Центрах Обработки Данных от SUN (.pdf) · Active Directory SLA для кампусной сети · HelpDesk SLA в учебном заведении · Пример сводной таблицы по финансовому SLA (.pdf) · Крайне полезно почитать "Красную Книгу" Introducing IBM Tivoli Service Level Advisor · И снова nextslm.org (теперь шаблоны) - Customer Satisfaction Survey, Internal SLA, Short-Form Internal SLA Помимо предоставления периодических отчетов, образцы которых приведены выше, очень важно дать потребителю ИТ-услуги возможность видеть состояние сервиса он-лайн. Об этом - в статье Рика Стурма (Rick Sturm). Кроме того, еще несколько примеров отчетов - в присоединенных файлах. 20/11/2003 Файлы по теме: Пример SLA для третьего уровня поддержки приложений SLA между Отделом ИТ и бизнес-подразделениями (источник - techrepublic.com) SLA, отчеты, чеклисты (от Рика Леопольди) Ссылки по теме: NextSLM.org The SLM Community (Articles, SLA Templates, Software Vendors, Links, Books, Q & A). Amazon.co.uk The Complete Guide to Preparing and Implementing SLAs (at Amazon, UK). TechRepublic.com IT Manager's Guide to Business Strategy + CD. « предыдущая статья следующая статья »

ITIL Service Catalogue example www.ITILsurvival.com all your ITIL ITSM Service Management process documents, books, cds, elearning

ITIL Service Catalogue example www.ITILsurvival.com all your ITIL ITSM Service Management process documents, books, cds, elearning: "The creation of a Service Catalogue according to the ITIL Framework, is used as a starting point for the implementation of the Service Level Management process.



ITIL Service Catalogue examples are not commonly found on the internet as they tend to be too specific. An ITIL Service Catalogue example must be viewed with caution as the author of the template will be basing their layout on their own experiences. While there is no substitute for experience there are simply too many variables that go in to the creation of such a critical document.



ITIL Service Catalogue example are naturally a way to save time in terms of development, but the reader must ensure that they do not compromise their own standards by accepting work that was prepared by others, for others.



The list below presents various reference points that can lead to ITIL Service Catalogue examples and other products that would be a useful starting point for those looking for such information.



Want to find out more about ITIL Service Catalogue examples and other products:



ITIL Exams

ITIL Books & CD Licensing

ITIL Documentation

ITIL Downloads

ITIL Online Education

ITIL Toolkit

E-mail us for ITIL"

Эскалация инцидента в процесс РМ.

Итак процесс обработки инцидентов построен, что же дальше ?
Далее не менее интересный и самый важный этап - анализ причин инцидентов. Данный этап подразумевает поиск причин инцидента и их анализ. Формализация методов устранения причин по своей методологии ближе к процессу управления проблемами, а значит для того что бы принять стратегическое решение по устранению причин.
Для качественного проведения анализа необходимы данные по инцидентам и эксперт, который в свою очередь предложит на основании этих данных конкретное решение по устранению причин инцидента.
Вот типичные вопросы которые могут возникнуть:
1. Нужен ли менеджер по управлению проблемами для каждой проблемы отдельно или это должен быть один человек с ролью координатора?
2. Кто должен эскалировать инцидент из процесса управления инцидентами в процесс управления проблемами ?
3. Какой уровень сотрудников должен проводить анализ причин инцидентов: начальник отдела, начальник управления или это должен быть независимый эксперт? Который имеет достаточный опыт в данной предметной области и его заключение будет иметь официальный характер.
Так же есть ответы на эти вопросы
Аналогично ответам и придерживаясь нумерации )))

1. Логичнее всего предположить что - решение проблемы необходимо представить как проект, тогда вопросы "кто крайний?" и "кто и что делает?" а также "В какие сроки устранят проблему?" отпадают.

2. Старший экспертной группы ( по какому либо сервису/услуге ) проводя анализ инцидентов самостоятельно принимает решение о необходимости проведения каких либо мероприятий по устранению источника инцидентов. Тем самым инициирует процесс "управления проблемами", а именно принимает решение о открытии проекта по устранению проблемы.

3. Собственно вопрос был о квалификации сотрудника проводящего анализ причин инцидентов, я сам себе ответил на этот вопрос в 2п.

Прочитать полную версию на форуме