Кажется, что процесс управления инцидентами – одна их немногих глав ITSM, в которой с точки зрения теории, да и практики не осталось пробелов. Было приятно удивиться, что некоторые вопросы организации столь знакомого процесса не имеют у меня готовых ответов. Может быть, они найдутся у тех, кто читает эти строки.

Итак, процесс обеспечивает своевременность решения инцидентов. Инциденты регистрируются, решаются, закрываются. Не успели вовремя – просрочка и штраф группе поддержки, задержавшей решение (иногда всем группам пропорционально вкладу). Справедливо? Безусловно.

Но что если инцидент не может быть устранен силами ИТ-подразделения и требует доработки ПО на стороне подрядчика? Книжный ответ простой: ИТ-подразделение несет ответственность и за своих подрядчиков, которые являются такими же компонентами услуги как серверы, сети, СХД, сопровождение которых осуществляется внутренними силами. Учитывая опыт работы во внешнем сервис-провайдере, такой ответ меня всегда удовлетворял и казался предельно логичным. Ведь внешний сервис-провайдер самостоятельно выбирает подрядчиков. Почему заказчика должно волновать, с чем именно связан сбой, если сервис-провайдер несет ответственность за конечную услугу?

Дела обстоят иначе у внутреннего ИТ-подразделения: некоторые подрядчики (особенно вендоры ПО) могут быть «навязаны» руководством компании. Корректно ли штрафовать за нарушение нормативов группы поддержки ИТ-подразделения, когда инцидент требует доработки на стороне такого подрядчика? Можно определить в SLA особые обстоятельства, по которым увеличивать нормативы, скажем, до нескольких недель. Вроде бы решение. Однако нередко контракт с вендором предполагает фиксированное количество часов на доработки в месяц. Очередью доработок ПО управляют бизнес-подразделения, и легко представить картину, в которой незначительный дефект, связанный с инцидентом, будет бесконечно вытесняться более приоритетными заданиями, которые требуются для проведения важных бизнес-изменений. 

Получается, что если гарантировать хоть какие-либо сроки затруднительно, нужно предусмотреть механизмы, которые без угрозы штрафа ни в чем не повинных групп поддержки за просрочку все же обеспечат скорейшее решение инцидента, от которого – не будем забывать – страдает пользователь.

Одним из таких механизмов может быть остановка таймера. Как только диагностика инцидента показывает, что без доработки ПО не обойтись, инцидент переводится в специальный статус и ждет решения связанного изменения. После того, как изменение закрыто, работа по инциденту возобновляется, хотя, вероятнее всего, останется получить только подтверждение пользователя. Плюсы: пользователь имеет возможность понятным образом отслеживать статус по доработке; в случае неудачного решения может вернуть инцидент в работу; как время работы над инцидентом учитывается только тот период, когда мяч на стороне внутренних групп поддержки. Минусы: «бэклог» таких особых инцидентов в крупных компаниях может со временем достигать сотен записей. И вообще такой балласт, который будет переходить из периода в период и мозолить глаза менеджеру, может довольно странно смотреться в процессе, жизненный цикл объектов которого, как правило, исчисляется часами, иногда, днями.

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

Оба варианта мне кажутся допустимыми при условии:

1. Помощи пользователю здесь и сейчас. Все знают хрестоматийный пример с переключением рабочей станции на другой принтер – в этом сценарии инцидент с обходным решением может быть закрыт как решенный. Но что если инцидент связан с неверным расчетом значений в отчете по причине некорректно заложенной логики – обходного решения может не быть как такового. Неплохо бы не оставлять пользователя с этой ошибкой наедине на несколько недель, и оказать посильную помощь перед переводом в статус «доработка» или применением особого кода закрытия.
2. Информирования пользователя по ходу выполнения доработки.
3. Наличия дополнительных контролей за инцидентами, требующими доработок. И перевод в статус «доработка» с остановкой таймера, и применение специального кода закрытия дают большое пространство для злоупотреблений со стороны групп поддержки, стремящихся избежать штрафов за просрочку. Легитимность использования любого из механизмов требуется регулярно проверять.

Но может быть есть и другие варианты?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую