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

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

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

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

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

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

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

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

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

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

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

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

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

Как ускорить решение инцидентов на 40%?

Мы все время от времени сетуем на то, что, при всей своей разумности и логичности, ITSM страдает нехваткой числовых подтверждений пользы. Поэтому достижения, которые выражены в цифрах, всегда вызывают интерес. На днях один из наших заказчиков поделился с нами своим достижением: за полгода ему удалось сократить среднее время решения инцидентов на 40%. Достойный результат, не правда ли? Основа решения – организация такого способа обращения за техподдержкой, при котором существенно сокращается время на сбор информации по инциденту и на его маршрутизацию до нужной группы. Технически это было реализовано посредством некоторой программы, которая должна была постепенно вытеснить такие способы обращения в Service…

Дмитрий Исайченко, 25 января 2015, последний комментарий 27 января 2015

Как измерить портал самообслуживания

Директор по обучению и сертификации HDI, Rick Joslin в своей заметке «What is LZS?» рассказывал о метрике LZS (Инциденты, решаемые на 0 уровне – Level Zero Solvable), которая показывает долю инцидентов, решённых службой поддержки, которые могли бы быть решены пользователями самостоятельно с использованием портала самообслуживания. Предположим, вы запускаете такой портал. Известно, что если пользователи не могут решить свой вопрос с помощью портала самообслуживания, они вряд ли обратятся к нему снова. Метрика LZS помогает спрогнозировать эффективность портала самообслуживания с точки зрения пользователя, снизить риски неприятия и повысить вероятность повторного использования. После запуска портала, анализ инцидентов входящих в LZS, помогает выявлять возможности…

Вопрос из зала: KPI для параллельных работ

После выхода нашей книги "ITSM. Руководство по измерению", читатель Сергей, внимательно её изучающий, задаёт вопрос: Реализуем метрики согласно вашей замечательной книги Сейчас застопрорились на метрике TPI в рамках РГ (стр.39-42 книги формулы 8-10) Рассмотрим ситуацию в рамках выполнения обращения привлечены в рабочие группы. Они работают параллельно. Пусть обращение хочу хорошую погоду (не придирайтесь — это пример) SLA (T) по обращению 8 часов 1 рабочая группа задача убрать снег 2 Рабочая группа разогнать облака 1 Рабочая группа справилась в срок и все сделала за 2 часа 2 Рабочая группа справилась за 12 часов и нарушила срок Для РГ2 TPI = 0 А…

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

Checklist: 7 шагов по работе с major-инцидентами

Тема major-инцидентов уже поднималась на нашем портале, и неоднократно. Однако после недавней встречи с одним из заказчиков я решил вернуться к ней еще раз. Теперь в виде короткого чек-листа, который можно использовать для проверки дизайна и исполнения процессов управления инцидентами и непрерывностью. Итак: О возникновении major-инцидента в первую очередь, как правило, узнают профильные специалисты – сетевые инженеры, администраторы СУБД и прикладных систем. Нужно позаботиться о том, чтобы информация о major-инцидентах как можно быстрее достигла первой линии поддержки. Эта информация должна включать в себя: описание инцидента (что и когда произошло, когда ожидается решение) чтобы первая линия имела ответы на…

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

Запросы на обслуживание – кто кого обслуживает?

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

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

Реальные примеры описаний процессов: управление инцидентами

Мы подготовили еще один список документов, находящихся в открытом доступе, и полезных для самостоятельной организации процессов. Ранее мы уже говорили о процессах управления изменениями, управления уровнем услуг. На этот раз речь о процессе управления инцидентами. Многие организации уже не первый год имеют дело с этим процессом, поэтому вдвойне интересно посмотреть "а как другие решают проблемы, с которыми столкнулись мы". Возможно, вы найдете интересные для себя решения в приведенных ниже документах. Описание процесса управления инцидентами Harvard University. Интересный экземпляр, с документе проработаны не только процедурные вопросы, но и политики, CSF, KPI. Описание процесса управления major инцидентами Harvard University. Не менее любопытный документ,…

Новостной поток, 23 ноября 2014, последний комментарий 10 февраля 2017

Кто такие VIP-ы и как их поддерживать?

Канадский эксперт и ITSM-консультант Райан Оджильви в своем блоге обсуждает вопрос VIP-поддержки и пытается понять, а нужно ли вообще выделять VIP-пользователей, как это делать и как же для них организовывать поддержку. Первое, на что обращает внимание Райан, это то, по какому принципу мы набираем людей в категорию VIP: Выбор может быть очень субъективным. Вполне возможно, что вы считаете VIP-ами всех сотрудников, начиная с какой-то определенной должности. Но всегда ли их запросы важнее, чем у других сотрудников, выполняющих ежедневные задачи бинеса. В некоторых случаях вы можете столкнуться с руководителем высшего звена, который скорее желал бы увидеть особый акцент сотрудников ИТ на влияющих…

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

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

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

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