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

ITSM. Руководство по измерению

Каждый год мы с друзьями вместо похода в баню выпускаем книжки по управлению ИТ. Некоторые – смешные, некоторые – серьёзные. Некоторые мы пишем сами, некоторые – переводные. Но все – полезные (во всяком случае, мы очень стараемся). В этом году книга будет серьёзной, и написали мы её сами. Она называется «ITSM. Руководство по измерению» и, как следует из названия, посвящена вопросам измерения процессов ITSM, а также оценки деятельности специалистов, подразделений и руководителей, вовлечённых в исполнение этих процессов. В книге три главы. В первой мы обсуждаем базовые понятия и методику формирования структурированной системы оценки, основанной на измерении. Во второй, применяя данную…

Дмитрий Исайченко, 30 сентября 2014, последний комментарий 29 декабря 2019

Давка в очереди – как быть?

Виталий задал вопрос на нашей странице в Facebook: Посоветуйте, пожалуйста, как поступить? Есть несколько трудоемких заявок которые поступили практически в один момент (например, установка операционной системы или что-то похожее). У них у всех крайний срок в соответствии с SLA определен в течение 8 рабочих часов. Ситуация такова, что даже задействовав весь персонал, мы не укладываемся в крайний срок как минимум у нескольких заявок. Как должна быть организована работа в таком случае? Товарищи-практики управления инцидентами, поделитесь опытом решения подобных коллизий?

Вопрос из зала, 6 августа 2014, последний комментарий 10 августа 2014

Инциденты и проблемы – два названия для трех объектов?

Роб Ингланд, известный так же как IT Skeptic, завел в своем блоге интересную дискуссию . По его мнению, дебаты вокруг определений инцидента и проблемы никогда не закончатся, потому что их уже много лет подпитывает фундаментальный вопрос: у нас есть два процесса, которые пытаются выполнить три работы. Когда услуга нарушена, говорит Роб, мы имеем дело с тремя задачами в поддерже: 1) Общение с пользователями, с группами и персонально. Помогаем им, применяя обходные решения, чтобы вернуть возможность работать. 2) Восстановление услуги в нормальный режим работы. Иногда для этого нам может потребоваться только перезагрузка.. или перекомпиляция …или восстановление из архива. 3) Устранение причины сбоя. Это может быть неисправность, ошибка, неудачный патч, неправильная конфигурация, дезинформация, отсутствие обучения ……

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

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

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

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

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