ITIL

Для тех, кто не любит ждать

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

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

Управление проблемами и время решения инцидентов

Задача сокращения среднего времени решения инцидентов стоит перед многими руководителями. На традиционный вопрос «Как сделать так, чтобы инциденты решались быстрее?», есть не менее традиционный ответ «Давайте проанализируем, где теряется время». Здесь работает простая аналогия с подходом к сокращению затрат: начать надо с выявления наиболее затратных областей. Именно там усилия по сокращению затрат могут принести наибольшие результаты. Где же искать ответ? В книге ITIL Service Design в главе про управление доступностью есть любопытный раздел «Expanded incident lifecycle». Это метод, описывающий основные этапы решения инцидента с целью последующего анализа, за счёт чего можно сократить время обработки на каждом из этапов – быстрее…

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

Lifecycle популярнее Capability

Грегори Такер, независимый ITSM-консультант с двадцатилетним опытом, регулярно отслеживает статистику сдачи экзаменов по официальной схеме ITIL. Собственно статистика публикуется компанией APMG с изрядной задержкой; так, недавно стали доступны данные за июль этого года. Рассмотрим наиболее интересные наблюдения Грегори. ITIL Foundation На июль 2012 года было сделано более 148 000 попыток сдачи базового экзамена, что привело к выдаче 132 000 сертификатов тем, кто справился. Доля тех, кто сдаёт успешно, стабильно растёт с 85% в 2010 году до 90% в 2012 (примечание: по этому поводу президент Pink Elephant Дэвид Рэтклиф в своём блоге высказал мнение: так как после обучения доля успешной сдачи…

Разрабатывать или покупать приложения: книжный ответ

То ли делать нечего, то ли коллеги застыдили, а я опять открыл умные книжки, и снова хочу на примере продемонстрировать, что в ITIL гораздо больше полезного, чем представляется скептикам. Эпиграфом к ITIL Service Strategy 2007 была цитата Вильяма Д. Грина из Accenture: How do you become not optional? Её вольно можно перевести так: "Что нужно делать, чтобы без вас не смогли обойтись?". Фраза настолько откровенно и ёмко позиционировала саму библиотеку и описывала чаяния целевой аудитории, что в 2011 году Девид Кэннон, переписывая Стратегию Услуг, вычеркнул её со всем старым вступлением (а многие русскоязычные авторы – еще нет). Но далее по новому тексту…

Константин Нарыжный, 17 октября 2012, последний комментарий 22 октября 2012

Что такое план управления услугами?

Известный ITSM-эксперт Ян ван Бон на международном ITSM портале сообщает, что окончательно запутался и просит помощи сообщества. Работая в области IT Service Management практически с момента её формирования в 80-90х годах прошлого столетия и являясь автором нескольких книг, Ян не может найти ответ на, казалось бы, простой вопрос: что такое план управления услугами? Запутаться ему помогают популярные книги ITIL и недавно обновлённый стандарт ISO 20000. Кто же поможет навести порядок в голове эксперта?

Новостной поток, 11 октября 2012, последний комментарий 13 октября 2012

ROI: 7148%, срок окупаемости: 1 неделя

В известную фразу про ложь, наглую ложь и статистику, похоже, пора добавить четвёртую составляющую: заявления вендоров программного обеспечения. Рецепт изготовления красивого отчёта прост: немного текста, пара-тройка диаграмм, большая таблица с расчётами. При этом таблицу важно красиво оформить, а заполнять можно и нулями. Доказательство гигантского возврата инвестиций при минимальном сроке можно уложить в четыре страницы, отведя примерно 40% ширины страницы под красивые белые поля. Так и поступила недавно некая компания. Хорошо, что с 2008 года в ITSM-индустрии работает специальный сервис, называемый Crap Factoid. Его представитель уже выполнил небольшой анализ упомянутого выше отчёта и присвоил ему высшую категорию: "Extreme Crap Factoid Alert"….

Новостной поток, 9 октября 2012, последний комментарий 12 октября 2012

Разрушители легенд: управление конфигурациями невозможно без процесса управления изменениями

Недавний разговор об управлении конфигурациями и изменениями опять напомнил мне извечный вопрос о курице и яйце. А разговор, в сущности, был на тему, правда ли необходимо внедрение управления изменениями для обеспечения актуальности CMDB? Распространённое мнение гласит: «Да, управление изменениями необходимо, иначе мы не сможем отслеживать изменения и, следовательно, CMDB утратит актуальность». Я не согласен. Даже если апеллировать к каноническим текстам (книжкам ITIL), назначение процесса управления конфигурациями – «is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed». В то время,…

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

Наконец-то: автоматическое внедрение ITIL

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

Новостной поток, 1 октября 2012, последний комментарий 2 октября 2012

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

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

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

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

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

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

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

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

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

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

ITIL

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