Разбор полётов или 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п.

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

Практика управления инцидентами

Определение инцидента есть внештатная работа предоставляемого сервиса, а именно любое нарушение в работе сервиса есть инцидент. Хотелось бы обратить внимание на ключевое слово сервис(услуга). По мнению пользователя и он прав, суть услуги или сервиса сводится к определенному набору функций в определенном и конечном числе операций. Но за каждым сервисом или услугой стоят аппаратно-программные мощности и ресурсы в том числе и человеческие. Администраторы сервисов это эксперты по сопровождению данного сервиса. Их роль очень важна в непрерывности предлагаемой услуги и качественного её сопровождения.
Для организации процесса управления инцидентами необходимы участники с конкретными функциями. Таким образом функционал возможно разделить на роли которые участники процесса выполняют на всем протяжении жизненного цикла инцидента.
Роль - именованная совокупность функциональных обязанностей определяющая поведение участника процесса в данном процессе.
Как правило при формировании портфеля ролей участников процесса "Управление инцидентами" есть несколько сложных вопросов, а именно:

1. Кто инициирует открытие инцидента.
2. Кто устраняет инцидент.
3. Как проводить горизонтальную эскалацию инцидента, между участниками экспертной группы.
   

Собственно эти вопросы и определяют непосредственно роли и взаимосвязь между ними в рамках управления инцидентами.
Остановимся на каждом из вопросов отдельно. Однако необходимо отметить один не маловажный факт, который есть основопологающим в концепции ITIL - что организация взаимодействия необходима двухсторонняя. Поскольку обмен информацией должен быть обоюдным то и роль инициатора регистрации инцидента включает в свой состав не одну группу сотрудников. Роль инициатора инцидента составная, в неё могут входить:

• группа экспертов, которые ответственные за штатную работу сервиса;
• обращение пользователя(ей) использующих сервис;
• система(ы) мониторинга сервиса;
  

Для организации процесса управления инцидентами основным является центр консолидирования информации т.е. владелец процесса. Данное заключение лежит в основе любого процесса - у каждого процесса должен быть владелец, в частном случае в процессе управления инцидентами - это менеджер процесса управления инцидентами.

CNews: ИТ-услуги: есть ли альтернатива ITIL?

Статья

ИТ-услуги: есть ли альтернатива ITIL?

Бизнес Интеграция

версия для КПК

14.03, Ср, 10:34, Мск, фото: СФН

Часто можно слышать, что библиотека ITIL стала стандартом "де-факто" для организации процессов обслуживания ИТ. Так ли это? Существуют ли альтернативы этому подходу? На вопросы корреспондента CNews ответил Сергей Овчинников, директор по развитию компании "Итилиум".

CNews: Как вы считаете, стала ли библиотека ITIL стандартом для сектора ИТ-услуг? Или альтернативы существуют?

Сергей Овчинников: Конечно, альтернативы есть, и они широко используются. Одним из основных принципов ITIL является концепция предоставления услуг, когда результатом работы ИТ-службы являются необходимые для бизнеса ИТ-услуги. Альтернативой ITIL, или даже ITSM (управление ИТ-сервисом), является подход, использующий взгляд на ИТ не как на услугу, а как на подразделение, обслуживающее определенные ИТ-активы. Если на предприятии есть некие ИТ-активы, обслуживать их можно точно так же, как и обычные производственные активы: проводить ремонты, устранять сбои.

В этом случае применимы обычные процессные ремонтные стандарты, такие как ISO 18322, полностью соответствующие концепции управления качеством. Или ГОСТ 2.601, 2.602 и другие.

Ознакомится с полной версией статьи -> CNews: ИТ-услуги: есть ли альтернатива ITIL?

Service Desk – кто это ?

Service Desk – кто это?

Немного истории. Поскольку методология ITIL подразумевает взаимодействие Бизнеса и ИТ в чистом виде т.е. посредством каких либо показателей то эти показатели необходимо как то учитывать, функция Service Desk – в сборе количественного показателя обращений пользователя по вопросам связанных с работой ИТ.

Service Desk - есть функция, она составляющая часть процесса «Управления Инцидентами». Это Единая Точка Входа для всех инцидентов в организации. Функция данного подразделения, консолидированние информации по инцидентам от Бизнеса к ИТ и от ИТ к Бизнесу.

А как же это выглядит на практике ?

Что нужно знать до внедрения автоматизированного ПО?

Принято считать что на протяжении ЖЦ (жизненного цикла) внедрения процесса есть время "До" и "После" того как было принято к использованию автоматизированное ПО. А так же с его внедрением управление станет прозрачным для всех участников процесса.

На практике это далеко не так!

Вот пример типичных путей внедрения:

1. Сложный - когда в процессе использования ПО мы постепенно изучаем мат.часть процесса и параллельно проводим точечные переговоры с каждым участником процесса объясняя его роль в этом процессе. Данный метод очень отрицательно сказывается на дальнейшей работе и приведет всех участников процесса к полному не понимаю, а работу до бездумного занесения информации в БД.
2. Простой – когда ещё до начала использования автоматизированного ПО будут определены все участники процесса и четко описаны роли, которые они выполняют в этом процессе. Как правило, такой способ занимает намного меньше времени на этапе внедрения автоматизированного ПО для обработки данных этого процесса и ещё до его внедрения, четко формализирует бизнес логику процесса в правила более понятные для алгоритмизации.

В зависимости от того какой вы выбрали путь такой и будет результат. Уделите больше времени на планирование процесса и результаты будут отличными! На этапе планирования обратите внимание на корректное описание ролей участников процесса.

"Начало пути"

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

1. Определение конечной цели, т.е. какой именно процесс Вы хотите внедрить.
2. Ландшафт систем, которые будет покрывать данный процесс. Как один из вариантов развития внедрения процесса, это его масштабируемость на другие системы, отработав на одной системе , данным процессом покрыть другую систему.
3. Определение участников процесса. Какие подразделения участвуют в процессе.
4. Какие роли у участников процесса. Функциональная нагрузка участника в процессе.
5. Определение ключевых показателей процесса. Т.е. критерии, по которым можно будет оценить работу процесса.
6. Определение графика внедрения.

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

ITIL-изация предприятий.

ITIL-изация предприятий.

Данная статья достаточно полно и кратко описывает процесссы, которые входят в библиотеку ИТ. В ней описано все, но как и в большинстве статей не говорится о том как выполнить внедрение процессов и организацию коммуникации между подразделениями. Большой опыт по внедрению базовых процессов таких как Управление Инцидентами, Управление Проблемами накапливается в организациях, но таким опытом предпочитают не делиться и хранить эти навыки внутри организации.
Многие из организаций предпочитают пользоваться услугами консультатнтов , которые и внедряют ПО для управления процессами , такие как НР Open View.

http://www.management.com.ua/ims/ims089.html