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

Необходимые составляющие управления инцидентами

Индийский ITSM-эксперт Киран Паббатхи (Kiran Kumar Pabbathi) поделился собственными лучшими практиками процесса управления инцидентами. В структуре описания процесса, которую он предлагает, несколько разделов: Причины важности управления инцидентами (они же задачи, они же цели). Что находится в охвате процесса Что остается вне охвата процесса Матрица ролей и обязанностей RACI Обязательные составляющие успешного управления инцидентами, такие как: Отдельная процедура для значительных инцидентов Документация: планы, политика и формат отчетов Обновляемая база знаний и база известных ошибок Обязательный обзор и разбор полетов по значительным инцидентам, и регулярный анализ всех остальных Ясное понимание всеми участниками процесса целевых уровней услуг, включая услуги внешних подрядчиков Список контактных данных ключевого персонала…

Новостной поток, 9 июля 2013, последний комментарий 10 июля 2013

Задачка: сложности с календарями

Давайте рассмотрим простую и довольно распространенную ситуацию. Допустим, Вы пообещали пользователям, что определенные виды обращений будут решаться/выполняться за 4 часа по времени рабочего дня пользователя. Предложение простое и понятное пользователям и ИТ-специалистам. Но как все усложняется, если организация живет в нескольких часовых поясах. Например: День 1. Пользователь из Владивостока в 11 утра по своему времени обратился в поддержку, первая линия решила, что надо назначить это обращение группе ИТ-специалистов в Москве. Но в это время в Москве еще 3-00 и ИТ-специалисты еще не начали свою работу. Придя в 9 утра по московскому времени на работу, ИТ-специалисты провели диагностику, выявили причину и отправили обращение ИТ-специалистам Владивостока для применения локального решения. Допустим, у них на…

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

Наконец-то: новые экзамены ITIL 2011 на русском языке

Долгожданные новости поступают из компании APMG, официального (на текущий момент) распорядителя экзаменационной линейки ITIL. В конце апреля все экзаменационные институты получили извещение о готовности перевода ряда экзаменов на различные мировые языки. В частности, говорится в нем о русифицированных ITIL Intermediate RCV и OSA. 28 мая 2013 года будут опубликованы пробные, а еще чуть позже экзаменационным институтам предложено продавать настоящие экзамены на нашем родном языке. Сроки локализации остальных экзаменов ITIL пока не разглашаются. Мы будем держать вас в курсе развития событий и с удовольствием поможем подготовиться к экзаменам на литературном русском языке.

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

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

Вопрос из зала, 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

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

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

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