ITIL

Безвыходные инциденты

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

Евгений Шилов, 26 сентября 2012, последний комментарий 4 октября 2012

Чей это профиль?

Заранее прошу прощения за многословность. Помогите разобраться с профилем, пожалуйста. Вдруг кто читал "Стратегию услуг"… в режиме краудсорсинга, например. Есть в книге Service Strategy такой процесс – управление спросом. Как и многое добавленное в ITIL в 2007 году, он не предлагает ничего принципиально нового, но добавляет деталей и красоты. Вот вкратце чем он занят: Предпосылки: Бизнес-процессы ведут к формированию бизнес-результатов. Для этого они используют ИТ-услуги Чтобы предоставлять услуги, поставщик услуг использует ресурсы. Потребность в ресурсах определяется спросом на услуги. Активность бизнес-процессов может меняться, вместе с ней – спрос на услуги. Можно выявить закономерности, которым подчинены эти изменения, и использовать…

Роман Журавлёв, 24 сентября 2012, последний комментарий 13 января 2014

Функциональная эскалация

Недавно в свете выпуска нового релиза CleverENGINE обсуждали внутри тему функциональной эскалации в управлении инцидентами. Этот, на первый взгляд, несложный вопрос на практике имеет очень важное значение, а принятые по нему решения определяют не только принципы разграничения ответственности за поддержку пользователей, но сказываются и на структуре каталога ИТ-услуг, и на содержании SLA. Так вот можно выделить два принципиально различных способа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом. В случае произвольного маршрута специалист, отвечающий за обработку инцидента, выбирает следующий шаг эскалации самостоятельно, в зависимости от результатов диагностики. Например, инцидент, связанный с отказом информационной системы по результатам диагностики может быть…

Дмитрий Исайченко, 11 сентября 2012, последний комментарий 22 сентября 2012

Сегодня EXIN расскажет об ITIL Master

Сегодня в 18:00 по московскому времени состоится открытый вебинар экзаменационного института EXIN, посвященный сертификации ITIL Master. Долгожданная, загадочная ITIL Master in Service Management является высшей ступенью сертификации, доступной сегодня специалисту по управлению ИТ-услугами. Как именно проводится аттестация действующих ITIL Expert'ов, что входит в программу ITIL Master, обо всех требованиях к кандидатам и о цвете значка нам обещают рассказать на сегодняшнем вебинаре и на ряде последующих. Зарегистрироваться на вебинар (технология WEBEX) можно на сайте EXIN.

Сертификация инструментов ITSM

Ведущий аналитик Forrester Research Стивен Манн высказался на тему сертификации программных продуктов на соответствие принципам и процессам ITSM. Поводом к его размышлениям стало обновление программы сертификации от компании PinkElephant. Напомним, что всемирно известный значок PinkVerify призван подтвердить наличие автоматизации процессов ITIL в программном продукте. Набор параметров, по которым могут быть оценены продукты был обновлен в 2011 году, чтобы отразить изменения в библиотеке ITIL. Стивен провел опрос среди 20 вендоров крупных решений для автоматизации ITSM. Из 13 ответивших на его вопросы: Десять уже обладают либо собираются получить новейшую сертификацию PinkVERIFY, а остальные трое уже обладают предыдущими версиями. Большинство наблюдают рост спроса…

Первый шаг на пути к совершенству

В одном из пробных экзаменов ITIL Foundation есть вопрос про первый шаг на пути к преобразованию практик работы ИТ. Вопрос звучит так: Что является первым действием постоянного совершенствования услуг? а. Понять видение и цели бизнеса б. Провести оценку базового состояния, чтобы понять текущую ситуацию в. Согласовать приоритеты улучшения г. Создать и проверить план Правильный ответ "из книжки" – "а". Лирическое отступление про ответ "а" Слово "Бизнес" очень расстраивает слушателей из ГУПов и бюджетных учреждений, которые не воспринимают деятельность своего предприятия как коммерческую, а также тех, кто работает в системном интегрировании, у кого заказчиков больше, чем один. Не волнуйтесь, ITIL "всех…

Шпаргалка по ITIL 2011

Несмотря на то, что теперь к названию ITIL® запрещено добавлять любые идентификаторы версии и издания, энтузиасты признают важность прошлогоднего обновления библиотеки. Например, новые книги подверглись модной операции "умного картографирования" (Mindmapping). Скачать или просмотреть в браузере новую карту процессов ITIL по книгам 2011 года можно в его блоге: itservicemngmt.blogspot.com. Спасибо авторам. Как вам такой инструмент?

Who is incident manager?

Во многих ITSM-проектах менеджером процесса управления инцидентами назначают начальника отдела поддержки пользователей (Service Desk). Такой вариант обладает рядом понятных минусов. Основной – риск вытеснения функций менеджера сквозного процесса функциями руководителя отдела поддержки. Как следствие, сложности во взаимодействии со второй линией, риск появления изолированных самостийных видов поддержки, с поступлением обращений мимо первой линии, без регистрации в системе автоматизации. Особенно вероятна такая «параллельная реальность» в отделах сопровождения прикладных систем. Причина: первая линия относительно редко бывает достаточно компетентной, чтобы оказывать полноценную начальную поддержку по прикладному ПО. А значит и пользователями, и «прикладниками» может восприниматься как лишнее звено, только увеличивающее общее время обработки обращений….

Дмитрий Исайченко, 19 августа 2012, последний комментарий 12 сентября 2012

Владельцы и менеджеры услуг в дикой природе

Все слушатели курсов "Основы управления ИТ-услугами" почти всегда тонко чувствуют терминологическое болото, в котором не-англоговорящим коллегам предлагается утонуть, буквально с первого дня знакомства что с сервисным, что с процессным подходом. Дело, наверное, в различных культурных установках, на которых и строятся языки. В любом случае, весь тяжелый словесный багаж может привести к разочарованию в ITSM. Не расстраивайтесь, в жизни всё гораздо веселее, чем в универсальных сводах знаний. Так вот, однажды я получил вопрос: ITIL описывает роли в процессах: владелец процесса и менеджер процесса. Все прозрачно: владелец занимается целеполаганием и инвестициями в процесс и заинтересован в результатах процесса. "Надо выкопать канаву вооон…

Константин Нарыжный, 30 июля 2012, последний комментарий 5 декабря 2017

Джентльменский набор. Всё, что нужно для управления ИТ

Наверное, каждый свод знаний в какой-то момент пытается стать универсальным, всеобъемлющим и достаточным. И, видимо, стать таковым нельзя без написания списка всего того, что нужно иметь/применять для того, чтобы правильно и успешно управлять информационными технологиями/услугами. Список, конечно, тоже должен быть универсальным, всеобъемлющим и достаточным. Вот, например, в COBIT 3 говорилось, что для того, чтобы предоставлять бизнесу информацию надлежащего качества, нужно управлять ресурсами, и этих ресурсов пять: Данные / Data Прикладные системы / Application systems Технологии / Technology Инфраструктура / Facilities Персонал / People. В COBIT 4 и 4.1 этот список несколько сократился: Информация / Information Приложения / Applications Инфраструктура / Infrastructure…

Роман Журавлёв, 15 июля 2012, последний комментарий 26 июля 2012

Влияние сбоев на ИТ-услуги

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

Евгений Шилов, 1 июля 2012, последний комментарий 5 июля 2012

Портал №1 по управлению цифровымии информационными технологиями

ITIL

Портал №1 по управлению цифровыми
и информационными технологиями