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

Вопрос из зала: такая разная эскалация

Александр спрашивает у нас: Здравствуйте уважаемые Эксперты! Хотелось бы задать такой вопрос. В чём принципиальное отличие функциональной эскалации от иерархической? Очень важно показать иерархическую эскалацию на конкретных примерах. Зарание спасибо за ответ. Подозреваем, что простые ответы Александра не устроят: Иерархическая Эскалация – Информирование или вовлечение руководителей более высокого уровня в ходе эскалации. Функциональная Эскалация – Передача инцидента,проблемы или изменения в техническую группу с более высоким уровнем компетенции в ходе эскалации. Что скажете, коллеги?

Вопрос из зала, 22 апреля 2013, последний комментарий 24 апреля 2013

Перенос сроков

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

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

Service Desk больше не нужен?

Часто считают, что набирающая популярность практика использования личных устройств для работы (BYOD) сильно усложняет жизнь службе поддержки – многообразие устройств не позволяет быстро и эффективно помогать пользователям, очередь инцидентов растет, загрузка сотрудников увеличивается. Получается, что надо штат службы поддержки увеличивать. Аналитик компании Gartner Джарод Грин так не считает: В действительности BYOD приводит к уменьшению количества обращений в Help Desk и последующему сокращению его штата. Данный тренд выражен настолько явно, что Help Desk, всегда считавшийся лицом ИТ-службы, рискует в ближайшие три года потерять актуальность. Этому может поспособствовать введение разумных политик. Организации используют различные уровни поддержки для разных видов устройств, начиная от круглосуточной…

Новостной поток, 5 апреля 2013, последний комментарий 8 апреля 2013

Групповая безответственность

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

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

Вопрос из зала: Перспективы диагностики инцидентов «на лету»

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

Вопрос из зала, 21 марта 2013, последний комментарий 27 марта 2013

Измерение процессов. Incident rate

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

Дмитрий Исайченко, 19 марта 2013, последний комментарий 28 ноября 2014

Вопрос из зала: “многослойная” поддержка

И вновь нам задают интересный вопрос из практики. Наталья спрашивает: Здравствуйте, коллеги! Есть ли какие-то рекомендации или стандарты в отрасли (или хотя бы best practices и ваши наблюдения), которые бы показывали рациональность введения дополнительного уровня поддержки? Сколько процентов кейсов должен закрывать каждый уровень поддержки, чтобы оправдать свое существование? Буду очень благодарна за ваш ответ. Коллеги, ждём ваших ответов в комментариях!

Вопрос из зала, 16 марта 2013, последний комментарий 21 марта 2013

Вторжение, набег, нашествие… Кого воспитывать – пользователей или программы?

Много лет назад, когда я работал в отделе разработки программного обеспечения, мы пытались приспособить кассиров в магазинах к отлову ошибочно зарегистрированного, неверно промаркированного и иным образом некорректно учитываемого товара. Было придумано несколько контролей, призванных обратить внимание кассира на продаваемый товар и инициировать эскалацию, обычно – вызов менеджера или старшего кассира. При сканировании товара, отвечающего заранее установленным условиям, на экран выводилось сообщение вроде "продажа запрещена. позовите администратора" или подобное. Абсолютное большинство кассиров в ответ предпринимало разнообразные усилия, направленные на скорейшее удаление сообщения с глаз долой. Проявлялись чудеса изобретательности и упорства, вплоть до физического выключения кассы. Никто не звал администратора. Прошли годы. …

Роман Журавлёв, 3 марта 2013, последний комментарий 26 сентября 2013

Безальтернативность Service Desk

Много раз обсуждали эту тему с заказчиками – правда ли необходима единая точка контакта по вопросам поддержки пользователей (Service Desk)? А если нет, то при каких условиях от неё можно или даже нужно отказываться? Могу сказать, что за свою карьеру я несколько раз советовал заказчикам воздержаться от организации такой службы, которая стала бы обязательной первой точкой контакта. Основных причин для такой рекомендации я вижу две: нехватка ресурсов для организации SD. Благо потребность в ресурсах в данном случае оценить очень просто (например, используя формулу Эрланга или упрощенные аналоги); наличие отдельных узкоспециализированных групп, которые поддерживают своих пользователей, которые пользуются только соответствующими отдельными…

Дмитрий Исайченко, 25 февраля 2013, последний комментарий 1 сентября 2014

Почему случаются инциденты

Один из авторов ITSMPortal, Robert S. Falkowitz, провел интернет-опрос о причинах инцидентов. Как объясняет Роберт, таким образом он хотел проверить увиденное в одной из публикаций утверждение, что "80% инцидентов являются следствием проводимых изменений". В обзоре результатов опроса Роберт отмечает, что собранные им данные так же недостоверны, как любые другие результаты подобных опросов: Выборка участников нерепрезентативна и невелика Как ни старался автор сделать вопросы максимально простыми, нашлись те, кто их не понял или понял неверно Знания, на которых участники основывают свои ответы, могут быть неверны; при этом сами участники склонны переоценивать свою практику и качество доступной им информации Тем не менее, опрос проведен…

Своевременность реакции на назначение как KPI?

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

Дмитрий Исайченко, 2 февраля 2013, последний комментарий 1 сентября 2014

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

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

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