Управление инцидентами Archives – Страница 6 из 18

Анестезия для сервиса

Любая боль – это сигнал о том, что есть проблема, о которой нам сообщает организм. А что в ITSM? Есть проблемы, о которых нам сигнализируют инциденты. Мелкие или значительные – они все равно остаются инцидентами, сигнализирующими об уровне боли для бизнеса. И как скорая помощь, Service Desk бросается на устранение боли. Подчеркну, это всего лишь снятие симптоматики, анестезия, которая потребует последующей терапии. С этой ситуацией сталкиваются и те, кто находится на стороне потребителя, и те, кто находится на стороне поставщика услуг. Вопросы управления инцидентами рассматриваются в рамках одноименного процесса в библиотеке ITIL v3, а также в руководстве по практике управления…

Как сделать приоритет реальным показателем очередности выполнения запросов и инцидентов

Все мы привыкли к ставшей уже общепринятой методике определения приоритета запроса или инцидента. Определяется срочность запроса (как быстро необходимо его выполнить), и воздействие/влияние запроса на пользователя или бизнес-процесс. На основе матрицы из срочности и влияния определяется приоритет запроса, который в свою очередь (в числе прочих параметров, например тип запроса – запрос на консультацию или обслуживание или изменение или инцидент – или статус Пользователя – VIP\не VIP), определяет выбор SLO и, в конечном счете, определяет, как быстро ИТ должно отреагировать и выполнить этот запрос – т.е. конечный срок выполнения запроса. Соответственно, сотрудникам поддержки ИТ, в рамках регламентов и рабочих инструкций предписывается…

Новостной поток, 20 февраля 2020, последний комментарий 26 февраля 2020

Типовые роли в поддержке и в управлении услугами

Известный эксперт в области ITSM Рой Аткинсон (Roy Atkinson) в своей статье делится перечнем и описанием типовых ролей в ИТ-поддержке и в управлении услугами, которые использует в своих отчётах Ассоциация профессионалов в области технической поддержки HDI. Первая линия поддержки / Аналитик Центра ПоддержкиСпециалисты технической поддержки первой линии, которые получают и обрабатывают заявки. Эти специалисты отвечают за предоставление клиентам информации, восстановление услуг, предоставление специфических услуг и эскалацию заявок на следующие линии. Могут иметь другие названия, например Аналитик службы поддержки, Агент службы поддержки. Вторая линия поддержкиСпециалисты технической поддержки, которые обрабатывают заявки, переданные с первой линии. Этим специалистам необходимы более продвинутые технические навыки…

Что можно узнать на курсе ITIL 4 CDS

Как вы знаете, курс ITIL(r)4 Create, deliver and support появился прошлой осенью. Разработан он на основе одноимённой книги и отдельных публикаций, в которых описаны практики, упоминающиеся в этой книге. Практики, вообще говоря, в книге упоминаются практически все, но для успешной сдачи экзамена нужно иметь представление об основных понятиях и подходах к организации ключевых (по мнению авторов ITIL) практик – ключевых в контексте двух потоков создания ценности, упоминаемых, кстати говоря, уже на курсе ITIL(r) Foundation. В список ключевых попали следующие из них: Поток создания новой услуги Проектирование услуг (Service design) Управление релизами (Release management) Подтверждение и Тестирование Услуг (Service validation and…

Зачем нужна категоризация?

Обсуждая тему эксплуатации услуг и сравнивая модели инцидентов и запросов на обслуживание, возник вопрос: а зачем нужна категоризация? И действительно, кому нужна эта информация? Как создать категоризатор и на что ориентироваться? Общий подход к категоризации используемый процессами в поддержке предоставляемых услуг может быть не только полезен с точки зрения осмысления и обработки данных, но и в повышении производительности службы поддержки. Категоризация является важным шагом многих процессов управления услугами. Категоризация инцидентов. Категоризация – это способ сортировки инцидентов по классам или категориям. В процессе управления инцидентами это дает нам возможность отслеживать аналогичные инциденты, связанные с продуктами и услугами, предоставляемыми бизнесу. В управлении…

Игорь Фадеев, 21 декабря 2019, последний комментарий 13 февраля 2023

Закрываем инциденты на второй линии, возможен ли такой сценарий?

Что говорит о закрытии инцидентов ITIL ITIL рекомендует закрывать инциденты на первой линии с помощью функции service desk. Рекомендация почти дословно звучит так: «Службе service desk следовало бы удостовериться в том, что инцидент полностью исчерпан, пользователи удовлетворены и согласны с тем, что инцидент можно закрыть» (Service Operation 4.2.5.9). Кроме этого, ITIL рекомендует службе service desk выполнить несколько процедур: указать код закрытия выполнить опрос удовлетворенности пользователя выполнить документирование закрытия инцидента определить есть ли связь с текущей проблемой с целью избегания повторения инцидента формально закрыть инцидент (изменить статус на «закрыто») Мало того, не стоит забывать о том, что тот же ITIL пишет…

Денис Подольский, 11 февраля 2019, последний комментарий 25 февраля 2019

Портал самообслуживания как катализатор позитивных изменений

Одна из частых проблем ИТ-поддержки заключается в высоком влиянии человеческого фактора при низком уровне зрелости ИТ-процессов. Рассмотрим практический случай. Я опишу в виде кейса опыт решения данной задачи, который был получен ещё до начала работы в Cleverics. Я считаю его удачным и применимым в других компаниях, поэтому хочу поделиться. Статья написана для того, чтобы продемонстрировать как создание портала самообслуживания может стимулировать позитивные изменения в работе внутреннего ИТ-подразделения компании. Ситуация и текущая проблематика до создания портала Несколько слов о компании: крупная промышленная компания географически распределенные подразделения количество пользователей – более 3000 внутреннее ИТ-подразделение с низким уровнем зрелости ИТ-процессов. Ситуация с первой…

Денис Подольский, 24 ноября 2018, последний комментарий 14 декабря 2018

Контроль обработки инцидентов

В редакцию портала поступил вопрос: Хотел бы задать вопрос в студию о наболевшем. Ситуация следующая: рабочие группы обрабатывают заявки только через Таски (рабочие задания), ничего другого они не видят, хотя практическая возможность из Таска заглянуть в Инцидент или ЗнО\ЗнИ присутствует. Заказчику мы естественно «продаём» Инциденты и Запросы. Сейчас мне настойчиво «предлагают» отойти от схемы указания в Инц\ЗнО\ЗнИ группы поддержки (поле Группа назначения), потому как может быть несколько одновременно выполняемых Тасков (или ещё пор каким то причинам) да и сами группы работают только с Тасками. Т.е. увидеть в списке\перечне Инцидентов (например) кто сейчас за него отвечает возможности не будет и это…

Вопрос из зала, 3 октября 2018, последний комментарий 12 октября 2018

Как управлять значительными инцидентами и нарушениями безопасности

Своими мыслями на этот счёт поделился Стюарт Рэнс, эксперт в области управления ИТ-услугами. Большинство инцидентов, с которыми имеет дело ИТ, относительно незначительны. Они могут быть важны для пользователей, которых затронули, но в большинстве случаев не представляют реальной угрозы для бизнеса. Команды технической поддержки, с которыми мне доводилось работать, в основном достаточно эффективно устраняют такие инциденты. Они в состоянии довольно быстро определить, что необходимо сделать, и отлично взаимодействуют с затронутыми пользователями. А поскольку таких инцидентов происходит довольно много, они учатся на собственном опыте. Они понимают, что инциденты являются источником информации для планирования мер по совершенствованию, и ведут проактивную работу по выявлению, приоритезации и…

Новостной поток, 23 августа 2018, последний комментарий 29 августа 2018

Сочетание Cynefin и Swarming для лучшего управления инцидентами

Cynefin – интригующий фреймворк, он базируется на теории сложности и принципе, согласно которому разные ситуации требуют существенно разных подходов. Его создатель, Дейв Сноуден (Dave Snowden), кратко описывает это как «осознать сложность, чтобы действовать». Сноуден создал фреймворк в 1999 году, когда работал в IBM, а в 2003 опубликовал широко известную статью «Комплексные акты познания». Он оставил IBM в 2005 году, чтобы основать Cognitive Edge. Cynefin привлекает значительное внимание DevOps-сообщества. Модель также вызывает интерес у ITSM-профессионалов, особенно с учетом грядущей эволюции (или замены) привычных фреймворков, таких как ITIL. Этот всеобщий интерес к Cynefin напоминает аналогичную заинтересованность в Swarming, философии, которая отвергает привычные…

Управление инцидентами в бизнес-процессах компании

В редакцию портала поступил вопрос: Коллеги, всех приветствую. Хотел поднять тему внедрения управления услугами на уровне предприятия (Enterprise Service Management). На тему натолкнула статья Стюарта Рейнса Incident Management Isn’t Just For IT (оригинал optimalservicemanagement…isnt-just-for-it, перевод habrahabr.ru/post/347488/). Кому-нибудь приходилось участвовать в таком преобразовании процессов? С какими трудностями сталкивались? Известны случаи, когда инициатором таких проектов был именно ИТ и ИТ оставалось рулить процессами? На сколько успешно это было?

Вопрос из зала, 26 января 2018, последний комментарий 30 января 2018

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

Управление инцидентами

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