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

Решение без переназначений (опрос)

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

Дмитрий Исайченко, 14 июня 2015, последний комментарий 15 июня 2015

Герои в ИТ – повод задуматься

В культуре многих ИТ-организаций существуют ИТ-герои – сотрудники, которые время от время в критические моменты выправляют ситуацию. В подобных организациях инцидент, потребовавший больших усилий на устранение, однотипный элемент в цепи таких же похожих – уже произошедших и возникнущих. Мало кто анализирует произошедший сбой, делает выводы, принимает меры, чтобы предотвратить его появление в будущем. Героями считаются ИТ-специалисты, мастерски решающие проблемы, тушащие внезапные инциденты. Им воздаётся честь и хвала – поскольку результат их работы на виду. При этом в тени остаются те, кто работает проактивно, предотвращая сами предпосылки для развития инцидентов. Или заранее создаёт планы по скорейшему восстановлению работоспособности для случаев, когда…

Новостной поток, 24 апреля 2015, последний комментарий 27 апреля 2015

Все на портал самообслуживания!

Недавно один из клиентов поделился достижением: "теперь у нас около 90% обращений регистрируется пользователями на портале самообслуживания, почта и телефон почти не используются". За счет этого разгрузилась первая линия, сократилось время обработки обращений, т.к. они маршрутизируются на вторую линию или во внешние компании автоматически, а данные, которые поступают от пользователя, содержат достаточно деталей из-за применения специализированных форм для разных типов обращений. Пример действительно интересный, многие к этому стремятся, но вот вопрос: везде ли достижимо такое состояние, какие условия должны быть выполнены и что нужно предпринять для того чтобы это случилось и принесло пользу, а не добавило работы? Начнем с условий, которые…

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

First Time Resolution (FTR) в разбивке по группам

В опубликованной нами книге «ITSM. Руководство по измерению» есть метрика First Time Resolution (FTR) для инцидентов, выраженная формулой 18 (страница 42). Метрика представлена в разрезе по рабочим группам, однако способ расчёта в разрезе по рабочим группам в книге подробно не рассматривается. Недавнее обсуждение показало, что это непростой вопрос, требующий некоторых пояснений. Напомним, что формула для расчета имеет вид: со следующим определением операндов: Sj — количество объектов, возвращённых на доработку в j-тую группу, Nj — общее количество объектов, обработанных за период силами j-той группы. А пояснений, собственно, всего два: по способу учёта возвратов на доработку; по определению операндов Sj и Nj….

Кто последний, тот и…

В редакцию портала поступил вопрос. Альберт, постоянный читатель и комментатор RealITSM, спрашивает: Коллеги, добрый день! Есть вопрос по определению ответственности по просрочкам в обращениях. Суть проблемы в следующем, в Service Desk настроено, что кто последний выполнил обращение, того и заявка в отчёте, но в случае же, если данное обращение просрочено, то просрочка также назначается на последнего исполнителя. На мой взгляд, это несправедливо, поскольку те сотрудники, по чьей вине обращение просрочено, избегают ответственности, передавая её на других исполнителей. Поделитесь, пожалуйста, своими идеями по данному вопросу: кто как решает данный вопрос, какие есть алгоритмы определения ответственности по просроченным обращениям? Редакция портала знает, как…

Вопрос из зала, 31 марта 2015, последний комментарий 11 апреля 2015

Инциденты, проблемы и производительность

Наверняка вам встречалась ситуация, когда конечные пользователи недовольны производительностью приложения, а внутри ИТ происходит перекладывание ответственности за "тормоза". Ответственные за программное обеспечение обвиняют ответственных за оборудование и наоборот или говорят пользователю, что так и должно быть. В чем сложность данной ситуации? 1. Понятие "тормозит" весьма субъективно, для одного пользователя приемлемо подождать 5 минут, для другого – 1 минута ожидания, уже вечность. Операции тоже могут быть разными. Что делать: Зафиксировать, что есть нормальная производительность, то есть, что значит "не тормозит". При этом измерение должно производиться в терминах максимально понятных конечным пользователям, желательно, чтобы пользователи могли самостоятельно повторить операцию и оценить скорость ее выполнения….

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

Вопрос из зала: что делать с взаимосвязанными инцидентами?

Эльдар спрашивает у авторов и читателей нашего портала: Если пользователи начинают плодить заявки относящиеся к одной общей проблеме, будет ли правильным объединять их в одну? Или же правильнее создание отдельной "главной" заявки и работать по ней, а по результатам закрывать заявки полученные от пользователей? Поделитесь опытом, коллеги?

Вопрос из зала, 18 марта 2015, последний комментарий 30 марта 2015

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

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

Дмитрий Исайченко, 13 марта 2015, последний комментарий 18 марта 2015

Автоматическая функциональная эскалация?

Дальше действовать будем мы! Виктор Цой. В недавних обсуждениях с заказчиками опять всплыла тема автоматической функциональной эскалации заявки на следующие линии поддержки при окончании срока, отведённого на обработку на текущей линии. В нашей практике мы такое решение не использовали никогда. Попробую объяснить, почему: прежде всего, автоматическая функциональная эскалация возможно только в схеме с фиксированными маршрутами эскалации (иначе, пока не завершена диагностика на предыдущем шаге, просто неизвестно, куда эскалировать). А это само по себе нечастое явление; далее, если, например, специалист L2 работает с инцидентом, а он, тем временем, автоматически переназначен на L3, то как об этом узнает специалист L2 и бросит начатую…

Дмитрий Исайченко, 7 марта 2015, последний комментарий 10 марта 2015

Система определения приоритетов одной известной компании

В одной компании уже много лет действует такая система определения приоритетов неприятных событий (мы бы называли их инцидентами, наверное): Код Sev-5, самый низший, используется для относительно незначительных проблем, как правило технических. Такие проблемы можно и нужно решать в обычном рабочем порядке. То есть — не очень срочно, но сделать нужно. Код Sev-1, самый высший, присваивается срочным событиям, реакция на которые должна быть безотлагательной: запускаются все возможные системы оповещения ответственных сотрудников, приступить к устранению беды следует немедленно, о проблеме, её последствиях и героическом устранении будет доложено одному из топ-менеджеров компании, который не только выслушает, но и сделает орг.выводы и примет административные…

Олег Скрынник, 11 февраля 2015, последний комментарий 30 марта 2015

Отсутствие выделенных групп поддержки – каковы преимущества?

Многим нашим читателям знакома проблема взаимодействия команд разработки и эксплуатации. Зачастую, задача первых сводится к пропихиванию созданного решения в продуктивную среду, чтобы успеть к дедлайну проекта. Вторые, естественно, сопротивляются, поскольку им с "этим" жить, а "это", к сожалению, не полностью задокументировано, не оттестировано, не всегда совместимо с боевым окружением, не очень-то и производительно и т.д. Проблема решаема – командам эксплуатации нужно подключаться на этапе проектирования, где закладывать эксплуатационые требования, и в ходе разработки следить за претворением их в жизнь. А теперь представьте, что выделенной команды по эксплуатации/поддержке нет. Есть ли в этом смысл, и какие преимущества это может обеспечить? Своим опытом…

Новостной поток, 29 января 2015, последний комментарий 5 февраля 2015

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

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

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