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

ITIL: восьмой процесс, третья попытка…

В начале июня наш финский друг Aale Roos получил из itSMF довольно традиционный опрос о внедрении процессов ITIL – если судить по таким опросам, основные процессы ITIL должны были быть внедрены у всех, давно и не однажды. Это ироническое по сути замечание навело Аале на мысль провести свой собственный опрос (мы с вами помним, что Аале, в далеком прошлом статистик, любит и умеет проводить опросы) среди финских компаний об их опыте построения процессов ITIL. Подробные результаты можно найти на сайте компании Аале, а я приведу здесь два любопытных результата: Во-первых, большинство респондентов вспомнили более одного ITIL-проекта, в среднем – три…

Роман Журавлёв, 4 июля 2014, последний комментарий 8 июля 2014

Мифы о портале самообслуживания

Не так давно на глаза попался пресс-релиз отчета Gartner “Addressing IT Self-Service Myths and Realities for Successful Implementations.” Пресс-релиз, как и отчет, не самой первой свежести (2010 год), но сути это не меняет. Авторы упоминают 4 мифа об организации порталов самообслуживания: Миф 1: Порталы самообслуживания снижают затраты на предоставление ИТ-сервисов. Реальность: Снижается только загрузка первой линии. Действительно, если функциональне возможности портала будут ограничиваться традиционным списком: самостоятельная регистрация обращений пользователя просмотр статусов зарегистрированных обращений получение информации из базы знаний (FAQ) выполнение простых операций без участия ИТ-специалистов (например, сброс пароля) то мы сократим только время, которое тратят специалисты первой линии на регистрацию обращений пользователей, ответы на вопросы “А…

Евгений Шилов, 22 июня 2014, последний комментарий 24 июня 2014

Обработка нестандартных запросов на обслуживание

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

Вопрос из зала, 6 июня 2014, последний комментарий 19 июня 2014

ITMF2014: оцениваем процессы и размышляем над уроками

5 июня на XI форуме по управлению ИТ (ITMF2014) среди прочих интересных выступлений был проведен кейс-тренинг по оценке процессов. Участникам была предложена такая ситуация: В связи со сменой владельцев в торговой компании проводится комплексная оценка действующих практик управления. В частности, новые руководители компании хотят получить оценку процессов управления ИТ. Вообще-то, руководство интересуют: соответствие практик управления ИТ целям и приоритетам бизнеса; уровень ИТ-рисков; эффективность (рациональность) деятельности по управлению ИТ; соответствие практик управления ИТ рекомендациям и требованиям отраслевых сводов знаний и стандартов. Но с учётом ограничений по времени и стоимости оценки, а также ввиду отсутствия формализованных целей и приоритетов бизнеса, да и…

Роман Журавлёв, 6 июня 2014, последний комментарий 3 августа 2015

Зомби, гидры, вампиры и прочие пользователи

И без того забавный сайт ZenDesk, посвящённый одноименному продукту для сервис-деска, пополнился на днях статьёй со сборником лучших практик борьбы с упырями, мумиями, зомби и прочими «сложными» клиентами служб поддержки. За местами смешными метафорами кроются действительно прикладные рекомендации менеджеру сервис-деска, не привязанные (почти) к конкретному инструменту автоматизации.

Новостной поток, 25 апреля 2014, последний комментарий 25 апреля 2014

Эстафета в управлении инцидентами

Про футбол я уже как-то писал, на этот раз тема тоже спортивная, но про эстафету. На днях были со Степаном Хрулевым у заказчика и нам рассказали грустную историю из всеми любимого процесса управления инцидентами. Процесс построен силами специалистов заказчика. Все как обычно: есть первая и вторая линия, есть нормативы на сроки обработки обращений. И как обычно случаются ситуации, когда одна группа затянула диагностику, посмотрела в последний момент и поняв, что это не ее, передала дальше. Вторая группа, получив обращение в последний момент, не успела выполнить вовремя, получила ярлык “просрочено” в обращении и грустит на тему “где в этом мире справедливость?”….

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

Мобильные участники процессов

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

Евгений Шилов, 18 марта 2014, последний комментарий 21 марта 2014

Major / Critical Incident Management: важная темная область

На прошедшем в начале этой недели курсе мы с его участниками обсуждали инциденты, для которых не очень хорошо работают привычные процедуры, описанные в книжках. Участники называли такие инциденты "критическими", я по привычке "значительными". Что мы в ходе этого обсуждения выяснили: Во-первых, годное определение значительного инцидента не так-то просто найти в литературе. Например, словарь ITIL говорит, что Major Incident – The highest category of impact for an incident. A major incident results in significant disruption to the business.(Значительный инцидент – Наивысшая категория влияния, применяемая инцидента. Значительный инцидент вызывает существенные потери для бизнеса.) Если Critical или Major – действительно лишь значение параметра "Impact", то не…

Роман Журавлёв, 28 февраля 2014, последний комментарий 24 апреля 2015

Измерение процессов. Incident Management. Часть 3

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

Дмитрий Исайченко, 11 января 2014, последний комментарий 7 марта 2014

Маршрутизация обращений пользователей

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

Евгений Шилов, 7 декабря 2013, последний комментарий 3 февраля 2014

О моем инциденте замолвите слово…

Слушатели на последнем тренинге рассказали о том, как решен у них вопрос эскалации инцидентов в профильные группы ИТ. Напомню вкратце, что проблема заключается в том, чтобы с одной стороны, сервис-деску не приходилось слишком много знать о доступности и возможностях 2 и 3 линий, чтобы отдавать инцидент прямо в руки самому «правильному» эксперту, а с другой – чтобы инцидент не застаивался «без глазу», не будучи назначен кому-то конкретному. Итак, в этой компании каждый специалист второй и третьей линии сам берет на себя ответственность за те инциденты, которые связаны с его областью знаний (уже это само по себе очень круто, так как…

Константин Нарыжный, 1 декабря 2013, последний комментарий 11 декабря 2013

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

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

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