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

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

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

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

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

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

Новостной поток, 9 февраля 2020

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

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

Артём Мукосеев, 20 января 2020

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

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

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

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

Что говорит о закрытии инцидентов 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, философии, которая отвергает привычные...

Новостной поток, 5 апреля 2018

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

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

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

Service Desk 2018

Довольно часто для молодых ИТ-специалистов, входом в мир информационных технологий служит Service Desk. Сложившийся стереотип о простоте работы на позиции специалиста первой линии поддержки, а также низкого авторитета подразделения в целом, до сих пор ощущается при разговорах с собеседниками. Предлагаю немного разобраться в этом вопросе. Из ITIL® v3 2011 следует, что Service Desk — это функциональное подразделение, состоящее из специального персонала, отвечающего за различные виды обслуживания. Словарь терминов ITIL® на русском языке в редакции от 29 июля 2011 года трактует: Служба поддержки пользователей (Служба Service Desk) – единая точка контакта между поставщиком услуг и пользователями. Типичная служба поддержки пользователей управляет инцидентами, запросами...

Шамиль Бабаев, 24 января 2018, последний комментарий 20 марта 2018

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

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

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