Библиотека ITIL – самый известный свод знаний по управлению ИТ-услугами (ITSM), разработанный правительством Великобритании. На русский язык в настоящее время не переведен, и очень вряд ли будет.
Несмотря на то, что теперь к названию ITIL® запрещено добавлять любые идентификаторы версии и издания, энтузиасты признают важность прошлогоднего обновления библиотеки. Например, новые книги подверглись модной операции "умного картографирования" (Mindmapping). Скачать или просмотреть в браузере новую карту процессов ITIL по книгам 2011 года можно в его блоге: itservicemngmt.blogspot.com. Спасибо авторам. Как вам такой инструмент?
Во многих ITSM-проектах менеджером процесса управления инцидентами назначают начальника отдела поддержки пользователей (Service Desk). Такой вариант обладает рядом понятных минусов. Основной – риск вытеснения функций менеджера сквозного процесса функциями руководителя отдела поддержки. Как следствие, сложности во взаимодействии со второй линией, риск появления изолированных самостийных видов поддержки, с поступлением обращений мимо первой линии, без регистрации в системе автоматизации. Особенно вероятна такая «параллельная реальность» в отделах сопровождения прикладных систем. Причина: первая линия относительно редко бывает достаточно компетентной, чтобы оказывать полноценную начальную поддержку по прикладному ПО. А значит и пользователями, и «прикладниками» может восприниматься как лишнее звено, только увеличивающее общее время обработки обращений….
Все слушатели курсов "Основы управления ИТ-услугами" почти всегда тонко чувствуют терминологическое болото, в котором не-англоговорящим коллегам предлагается утонуть, буквально с первого дня знакомства что с сервисным, что с процессным подходом. Дело, наверное, в различных культурных установках, на которых и строятся языки. В любом случае, весь тяжелый словесный багаж может привести к разочарованию в ITSM. Не расстраивайтесь, в жизни всё гораздо веселее, чем в универсальных сводах знаний. Так вот, однажды я получил вопрос: ITIL описывает роли в процессах: владелец процесса и менеджер процесса. Все прозрачно: владелец занимается целеполаганием и инвестициями в процесс и заинтересован в результатах процесса. "Надо выкопать канаву вооон…
Наверное, каждый свод знаний в какой-то момент пытается стать универсальным, всеобъемлющим и достаточным. И, видимо, стать таковым нельзя без написания списка всего того, что нужно иметь/применять для того, чтобы правильно и успешно управлять информационными технологиями/услугами. Список, конечно, тоже должен быть универсальным, всеобъемлющим и достаточным. Вот, например, в COBIT 3 говорилось, что для того, чтобы предоставлять бизнесу информацию надлежащего качества, нужно управлять ресурсами, и этих ресурсов пять: Данные / Data Прикладные системы / Application systems Технологии / Technology Инфраструктура / Facilities Персонал / People. В COBIT 4 и 4.1 этот список несколько сократился: Информация / Information Приложения / Applications Инфраструктура / Infrastructure…
Обсуждали недавно интересный вопрос, касающийся договоренностей с бизнесом об уровне ИТ-сервисов. Допустим, для простоты, что уровень ИТ-сервиса включает в себя только характеристики поддержки. Например: время поддержки время решения инцидентов И пусть мы в соглашении об уровне ИТ-сервиса фиксируем долю инцидентов решенных в обещанные сроки. Построить отчетность по времени решения инцидентов и соблюдению сроков довольно просто, любая система автоматизации нам это легко сделает. Да и с точки зрения процесса все более-менее понятно. Звонят пользователи, регистрируются и решаются инциденты, считаются сроки. Но как только мы начинаем работать еще и с инфраструктурными инцидентами (сбоями), которые пришли не от пользователей, а стали известны, например…
Институт EXIN сообщает, что приводит свою систему экзаменов по ITIL в соответствие с требованиями и планами APMG (владельцев сертификационной схемы). С 7 июля 2012 года из названий всех продуктов ITIL будет удалена приставка с номером версии библиотеки: "V2" или "V3" . Это завершающий этап многолетней деятельности по выводу с рынка сертификационной линейки на основе предыдущей второй версии библиотеки. В дальнейшем всем нам предлагается не говорить о различиях между версиями и, говоря "ITIL", подразумевать партию все версии сразу. Кроме того, изменяются названия сертификатов Foundation и Master, с тем, чтобы придать всей линейке единообразие: ITIL Foundation Certificate in IT Service Management ITIL Continual Service…
В последние годы я довольно много сталкиваюсь с практическими вопросами организации SLM и построения каталога ИТ-услуг. Одним из актуальных вопросов в этой области является назначение и содержание такого документа как Operational Level Agreement (OLA). Есть бородатый анекдот про хозяйку, которую соседка обвинила в том, что когда та брала у неё горшок, она вернула его треснувшим. Ответ был таков: «Во-первых, это неправда – я вернула его целым. Во-вторых, когда я брала горшок, он уже был треснувшим. И в-третьих, я вообще его не брала». Так вот, про OLA я могу сказать буквально следующее: во-первых, такого документа не существует, а во-вторых применение OLA…
Много раз уже слышали от различных Заказчиков "хотелку" под условным названием "доска аварий". Звучит она так: хотим, чтобы можно было быстро и наглядно увидеть инфраструктурные инциденты, которые еще оказывают влияние на предоставляемые ИТ-услуги. Цель понятна: хочется иметь перед глазами краткий снимок инфраструктуры, на котором видны все проблемные области, для того чтобы быстро принимать решения о возможных причинах инцидентов, использовать эту информацию при диагностике, ответах звонящим пользователям и т.д. Идея прекрасная, но смущает меня в ней следующее: влияние инфраструктурных инцидентов на ИТ-сервисы в каждом конкретном случае – вещь требующая вдумчивой оценки (иногда быстрой, иногда нет). Влияние может быть отложенным, влияние может…
Канадский эксперт по управлению ИТ Ларри Купер представил в своей авторской колонке на itsmportal.com свой взгляд на структуру соглашений об уровне услуг. Как водится, статья начинается с определения услуги и с критики ITIL: Вроде всё просто: идёте в интернет, находите бесплатные (или даже платные) шаблоны соглашений, подгоняете их под свою ситуацию, наполняете их содержанием, утверждаете у руководства, собираете подписи – готово. Так ведь? Скорее всего, придётся ещё очень потрудиться. Чтобы SLA отражали реальность, недостаточно наполнить шаблон, хоть бесплатный, хоть за 200 долларов. С чего же начать? Сначала, надо понять, что значит слово "услуга" – нужно сделать это до того, как…
Вопрос задаёт наш постоянный читатель и комментатор Андрей Капустин: Вопрос вынесен отдельно из обсуждения "Многоликие услуги" В каких случаях сервисный подход не нужен или вредит бизнесу? Для примера ситуации к обсуждению предлагаю свой проект: крупный иностранный банк аутсорсит в российского подрядчика разработку и поддержку заказчик декларирует, в том числе и через внутренние политики, свою высокую культуру ведения деятельности, в том числе и в связанных с автоматизацией областях в проекте в котором я участвую как руководитель поддержки, интуитивно очевидно что уровень зрелости процессов в лучшем случае первый; при этом проблемы на мой взгляд порождены в далеко не последнюю очередь "весьма совковой"…
На днях меня попросили показать примеры вопросов, которые можно задавать пользователям для оценки их удовлетворенности итогами решения инцидента. То есть по итогам решения инцидента пользователь не просто должен сказать: "да работает/нет не работает", а дать "развернутый" ответ о том, как все прошло и насколько он счастлив. Я решил заодно и на портале упомянуть эту тему и важные моменты: Нужно точно понимать, зачем проводится опрос, какие выводы предполагается сделать. Только так можно подобрать правильные вопросы и понять как затем обрабатывать ответы. Вопросов не должно быть много (2-3 достаточно) иначе есть риск вообще не получить ответов или получить случайные ответы Пользователя не…