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"
четверг, 28 февраля 2008 г.
ITIL Service Catalogue example www.ITILsurvival.com all your ITIL ITSM Service Management process documents, books, cds, elearning
пятница, 15 февраля 2008 г.
Эскалация инцидента в процесс РМ.
Итак процесс обработки инцидентов построен, что же дальше ?
Далее не менее интересный и самый важный этап - анализ причин инцидентов. Данный этап подразумевает поиск причин инцидента и их анализ. Формализация методов устранения причин по своей методологии ближе к процессу управления проблемами, а значит для того что бы принять стратегическое решение по устранению причин.
Для качественного проведения анализа необходимы данные по инцидентам и эксперт, который в свою очередь предложит на основании этих данных конкретное решение по устранению причин инцидента.
Вот типичные вопросы которые могут возникнуть:
1. Нужен ли менеджер по управлению проблемами для каждой проблемы отдельно или это должен быть один человек с ролью координатора?
2. Кто должен эскалировать инцидент из процесса управления инцидентами в процесс управления проблемами ?
3. Какой уровень сотрудников должен проводить анализ причин инцидентов: начальник отдела, начальник управления или это должен быть независимый эксперт? Который имеет достаточный опыт в данной предметной области и его заключение будет иметь официальный характер.
Так же есть ответы на эти вопросы
Аналогично ответам и придерживаясь нумерации )))
1. Логичнее всего предположить что - решение проблемы необходимо представить как проект, тогда вопросы "кто крайний?" и "кто и что делает?" а также "В какие сроки устранят проблему?" отпадают.
2. Старший экспертной группы ( по какому либо сервису/услуге ) проводя анализ инцидентов самостоятельно принимает решение о необходимости проведения каких либо мероприятий по устранению источника инцидентов. Тем самым инициирует процесс "управления проблемами", а именно принимает решение о открытии проекта по устранению проблемы.
3. Собственно вопрос был о квалификации сотрудника проводящего анализ причин инцидентов, я сам себе ответил на этот вопрос в 2п. 
Прочитать полную версию на форуме
Практика управления инцидентами
Определение инцидента есть внештатная работа предоставляемого сервиса, а именно любое нарушение в работе сервиса есть инцидент. Хотелось бы обратить внимание на ключевое слово сервис(услуга). По мнению пользователя и он прав, суть услуги или сервиса сводится к определенному набору функций в определенном и конечном числе операций. Но за каждым сервисом или услугой стоят аппаратно-программные мощности и ресурсы в том числе и человеческие. Администраторы сервисов это эксперты по сопровождению данного сервиса. Их роль очень важна в непрерывности предлагаемой услуги и качественного её сопровождения.
Для организации процесса управления инцидентами необходимы участники с конкретными функциями. Таким образом функционал возможно разделить на роли которые участники процесса выполняют на всем протяжении жизненного цикла инцидента.
Роль - именованная совокупность функциональных обязанностей определяющая поведение участника процесса в данном процессе.
Как правило при формировании портфеля ролей участников процесса "Управление инцидентами" есть несколько сложных вопросов, а именно:
- Кто инициирует открытие инцидента.
- Кто устраняет инцидент.
- Как проводить горизонтальную эскалацию инцидента, между участниками экспертной группы.
Остановимся на каждом из вопросов отдельно. Однако необходимо отметить один не маловажный факт, который есть основопологающим в концепции ITIL - что организация взаимодействия необходима двухсторонняя. Поскольку обмен информацией должен быть обоюдным то и роль инициатора регистрации инцидента включает в свой состав не одну группу сотрудников. Роль инициатора инцидента составная, в неё могут входить:
- группа экспертов, которые ответственные за штатную работу сервиса;
- обращение пользователя(ей) использующих сервис;
- система(ы) мониторинга сервиса;
CNews: ИТ-услуги: есть ли альтернатива ITIL?
Статья
ИТ-услуги: есть ли альтернатива ITIL?
14.03, Ср, 10:34, Мск, фото: СФН
Часто можно слышать, что библиотека ITIL стала стандартом "де-факто" для организации процессов обслуживания ИТ. Так ли это? Существуют ли альтернативы этому подходу? На вопросы корреспондента CNews ответил Сергей Овчинников, директор по развитию компании "Итилиум".
CNews: Как вы считаете, стала ли библиотека ITIL стандартом для сектора ИТ-услуг? Или альтернативы существуют?
Сергей Овчинников: Конечно, альтернативы есть, и они широко используются. Одним из основных принципов ITIL является концепция предоставления услуг, когда результатом работы ИТ-службы являются необходимые для бизнеса ИТ-услуги. Альтернативой ITIL, или даже ITSM (управление ИТ-сервисом), является подход, использующий взгляд на ИТ не как на услугу, а как на подразделение, обслуживающее определенные ИТ-активы. Если на предприятии есть некие ИТ-активы, обслуживать их можно точно так же, как и обычные производственные активы: проводить ремонты, устранять сбои.
В этом случае применимы обычные процессные ремонтные стандарты, такие как ISO 18322, полностью соответствующие концепции управления качеством. Или ГОСТ 2.601, 2.602 и другие.
Ознакомится с полной версией статьи -> CNews: ИТ-услуги: есть ли альтернатива ITIL?