Инцидент, Холмс! Элементарно, Ватсон!::БИТ 08.2017

Поиск по сайту

bit.samag.ru

Web

Рассылка Subscribe.ru

подписаться письмом

Вход в систему


Запомнить меня
Регистрация Забыли пароль?

О журнале

Ваше мнение

Статьи

Общие тенденции и тренды

Архив

Мероприятия

Календарь мероприятий

сентябрь

2024

показать все

Новости партнеров

05.09.2024

Сообщество цифровых управленцев «я-ИТ-ы» приглашает Вас на всероссийский онлайн, который состоится 12 сентября в 11:00 (мск)!

04.09.2024

Вышла вторая ревизия линейки Рутокен MFA

28.08.2024

«Инфобез со вкусом» от «Газинформсервиса» покажет федеральное телевидение

13.08.2024

Новые возможности СУБД Jatoba – улучшены функции безопасности, удобства и функциональности

показать все

Статьи

13.08.2024

Оптимизация продаж лизинговых услуг с ИИ для ГК Альфа-Лизинг с платформой ValueAI

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

18.04.2024

5 способов повысить безопасность электронной подписи

18.04.2024

Как искусственный интеллект изменит экономику

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

05.04.2024

Мотивируй, не то проиграешь!

показать все

Инцидент, Холмс! Элементарно, Ватсон!

Главная / Архив номеров / 2017 / Выпуск №08 (71) / Инцидент, Холмс! Элементарно, Ватсон!

Рубрика: ИТ-процессы

Марина Аншина, президент Фонда ФОСТАС, председатель правления Российского Союза ИТ‑директоров

Инцидент, Холмс!
Элементарно, Ватсон!

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

Инцидент, Холмс! Элементарно, Ватсон! При этом, обратите внимание, что в детективах обязательно описываются неприглядные стороны человеческой натуры, отвратительные сцены насилия и жестокости, кровь и грязь. А при расследовании инцидентов ИТ мы, не теряя в интриге и увлекательности, имеем дело с компьютерами и программами, которые сформировали инцидент вовсе не по злому умыслу, а потому, что прямолинейно истолковали инструкции человека. Да и тот скорее всего просто не предусмотрел такого развития событий и вовсе не собирался кому-тонавредить. Неужели именно темные стороны детективов привлекают к ним читателей? Я все же склонна думать, что таких меньшинство. Возможно, просто пока не нашелся талантливый романист, способный пересказать увлекательный процесс поиска способов устранения инцидента. Самой что ли взяться…

Все вы хорошо знаете, что в соответствии с ITIL «инцидент – это отклонение от ожидаемого стандарта на предоставление сервиса». То есть инцидент – это не только когда ничего неработает и пора кричать «Караул!», а когда работать-то работает, но не так, как надо, а именно как было обещано. Например, медленная работа программного приложения тоже может быть инцидентом.

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

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

Если ситуация повторяется с завидной регулярностью и не связана, например, с не относящимися к рабочей деятельности намерениями пользователя, то этот инцидент легко может перерасти в проблему

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

Надеюсь, этим кратким вступлением я развеяла представление о процессе управления инцидентами как о чем-то простом и очевидном. Многократно сталкивалась с тем, что когда начинаешь о чем-то задумываться или волей обстоятельств попадаешь в необходимость разбираться в чем-то новом, но вроде общеизвестном, то все кажется настолько ясным, чтовпору вскрикнуть: «Элементарно, Ватсон!» Но, как только погружаешься в эту казавшуюся такой незамысловатой тему, выясняется масса подробностей, которые раньше были скрыты плотной завесой незнания.

Так же происходит с процессом управления инцидентами, с которым хоть раз да столкнулся любой из нас в быту? Например, когда получал несоразмерный счет за телекоммуни-кационные услуги или неожиданно пропадало электричество, или в зимнюю пору вдруг переставали греть батареи. И мы со вполне понятным и простительным возмущением добивались от поставщика соответствующих услуг устранения этих неприятностей, совершенно справедливо не задумываясь, как он это будет делать. А теперь вот приходится задуматься.

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

Довольно часто разрешение инцидента связано с тем, что мы исхитрились обойти эти обстоятельства. И после разрешения инцидента уже в относительно спокойном режиме, впроцессе управления проблемами, займемся их устранением. Но об этом мы, как я и обещала, поговорим в следующей статье.

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

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

Рисунок 1. Диаграмма swim lane для процесса управления инцидентами

Тем, кто еще проникся пользой подобного представления процессов, горячо его порекомендую, поскольку тут сразу видно, кто что делает. И не надо разбираться в хитросплетениях блок-схемы, чтобы увидеть, что же именно тебе предстоит выполнить. Кстати, многие заказчики нежно любят swim lane и предпочитают их любому другому изображению процессов.

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

Обычно каждая следующая линия квалифицированнее и, соответственно, дороже, чем предыдущая. И чем на более отдаленной от регистрации линии разрешен инцидент, тембольше времени ушло на его разрешение, и, значит, мы потратили больше ресурсов и одновременно увеличили риск нарушения SLA.

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

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

Существует упрямая статистика, согласно которой при правильной организации работы до 80% инцидентов решаются сразу на первой линии поддержки, что, как понимаете, весьма полезно для ИТ и ИТ-подразделения в частности. Какими бы фантастическими ни казались вам эти цифры, уверяю вас, что, по крайней мере исходя из моего личного опыта внедрения процесса управления инцидентами, они вполне достижимы. И каждый раз это было сродни волшебству, производящему глубокое впечатление на заинтересованных лиц, допущенных к его лицезрению.

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

Наверное, было бы нечестно уйти в сторону и оставить бедного руководителя наедине с инцидентом в столь тяжелой ситуации, которая может грозить ему и многими карами, имногими бедами. Что может сделать руководитель? Он может привлечь специалистов, которые не числятся в штатной структуре управления инцидентами. Например, я в такой ситуации однажды была вынуждена привлечь своего бывшего коллегу, который, я знала, справится с инцидентом.

На помощь руководителю может прийти и такой способ, как краудсорсинг – т.е. обращение к толпе пользователей интернета через социальные сети или через сайт, или другим способом, что тоже иногда помогает – и еще как. Ведь тут не просто «одна голова хорошо, а две лучше», тут в расследование вступает великое множество голов. Руководитель может изыскать дополнительные ресурсы, такие как деньги для обращения в Скорую службу помощи, или в конце концов предложить совсем нестандартный способ.

Ни телефон, ни личное обращение нельзя исключать из возможностей для получения помощи. Если и стоит заставлять пользователя регистрировать инцидент через форму в интернете, то делать это надо мягко, я бы даже сказала, нежно

Однако вертикальной эскалацией не стоит злоупотреблять. Во-первых, она еще больше удорожает поддержку, а во-вторых, загружает и так сильно загруженные и к тому же дорогостоящие ресурсы командования, которых, с высокой долей вероятности, может просто не хватить.

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

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

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

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

Поступление инцидента и его регистрация происходят на первой линии поддержки, роль которой все чаще выполняет call-центр. При внедрении автоматизированной системы Service Desk или Help Desk возникает заманчивое желание заставить всех пользователей самостоятельно формировать свои заявки на устранение инцидента в этой системе.

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

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

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

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

Расстановка приоритетов, которой также занимается первая линия поддержки, тоже дело очень сложное, а в случае инцидентов еще и очень ответственное. Потому что отприоритета зависит, сколько у нас есть времени на его разрешение. Для сокращения субъективизма в таком важном деле приоритет обычно формируют на основе более определенных характеристик. Например, срочности и масштаба влияния.

Первое определяется временем, к которому инцидент должен быть устранен, чтобы не нанести серьезный вред компании. Второй – охватом инцидента. Ведь бывают инциденты, парализующие работу всех сотрудников, а бывают – только одного. Тут еще очень важно, кто этот одинокий страдалец. А ну как генеральный директор! Для этого при регистрации инцидента в соответствии с ITIL проставляется тип пользователя – супер или не супер. В первом случае приоритет инцидента автоматически повышается.

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

Знаете ли вы среднее время работы оператора call-центра в организациях, предоставляющих такую услугу? Четыре-пять месяцев – больше люди просто не выдерживают

Функции call-центра все чаще отдают на аутсорсинг. Во многих случаях это оказывается эффективным, однако требует определенной предварительной работы и серьезного последующего контроля. Любые интерфейсы, что программные, что организационные, требуют затрат и повышают риски. Так и в этом случае.

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

Поэтому у вас, как обычно, есть два варианта: либо развивать соответствующие компетенции у себя, либо выбирать аутсорсера. Конечно, для выбора, отдавать или не отдавать нааутсорсинг call-центр, надо проанализировать существенный объем информации, не ограничивающийся стоимостью сотрудников. И помнить, что вам придется очень точно определить сценарии взаимодействия первой линии с пользователем для правильной регистрации инцидента.

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

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

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

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

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

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

снижает стоимость обслуживания;
сокращает риски нарушения SLA;
повышает удовлетворенность поль-зователей;
мотивирует первую линию.

Однако если на первой линии ничего не получилось, инцидент отправляется в путешествие по следующим линиям. Это путешествие ограничено временем, установленным в SLA, поэтому при приближении к угрожающему сроку инцидент попадает к руководителю, который берет ответственность за его разрешение на себя и использует для этого все свои права и полномочия.

Этим руководителем может быть либо линейный руководитель всего подразделения, осуществляющего поддержку пользователей, либо владелец процесса управления инцидентами. Теория, да и практика, процессного управления определяет лицо, ответственное за выполнение процесса, как менеджера или владельца этого процесса. Он несет ответственность заего выполнение в соответствии с регламентом и за непрерывное улучшение качества процесса, которое позволяет это качество не ухудшить.

Еще один парадокс сервисного обслуживания состоит в том, что если ничего не предпринимать, то даже идеально спроектированный процесс со временем начнет ухудшаться. Тут как в процессе собственного развития: если ничего не делать, не подниматься вверх, то неожиданно обнаружишь, что непоправимо отстал и падаешь вниз.

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

Кстати, иногда этот менеджер даже не подозревает, что на него возложена столь почетная обязанность, и просто ничего не предпринимает в этом направлении. И качество процессов, в том числе управления инцидентами, неуклонно ухудшается.

Если инцидент не был разрешен на первой линии, то он переходит или назначается специалистам следующей линии поддержки. Такое назначение может происходить по-разному: отполной автоматизации на основании проведенной классификации до передачи руководителю подразделения, который сам назначает исполнителя. Между этими крайними точками возможны любые варианты.

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

Можете ли вы спать спокойно? Увы, нет. Вам надо постоянно анализировать, насколько хорошо выполняется процесс, и изыскивать средства для его улучшения

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

Например, если вилка регулярно оказывается вынутой из розетки и пользователь по утрам не может включить компьютер, то это повод сформировать проблему и выяснить причину. Может выясниться, что уборщица именно так понимает свои обязанности, и с ней надо провести разъяснительную работу.

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

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

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

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

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

Предположим, что вы спроектировали процесс управления инцидентами, обучили специалистов всех линий поддержки, мотивировали их на терпение, выдержку и понимание вработе с пользователями. Можете ли вы спать спокойно? Увы, нет. Вам надо постоянно анализировать, насколько хорошо выполняется процесс, и изыскивать средства для егоулучшения. Ведь ничто не стоит на месте: меняется компания, меняются пользователи, меняются средства, которые доступны для организации процесса.

Поэтому важную составляющую процесса управления инцидентами занимает его постоянный анализ, который, конечно, проще всего организовать с помощью соответствующей программной системы.

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

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

Конечно, основными показателями процесса служат отчеты по выполнению SLA для инцидентов различного приоритета.

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

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

И особенно важно, чтобы жалоба не попала на рассмотрение к тому же исполнителю, о котором в ней идет речь. А то ему придется, как барону Мюнхгаузену, самому себя вытаскивать из болота некачественного обслуживания. А это никому еще не удавалось.

Процесс управления инцидентами относится к тем процессам, которые непосредственно соединяют пользователя и службу ИТ. Именно от него в основном зависит то, каквоспринимают ИТ в организации. Это визитная карточка вашего обслуживания. Он служит и мерилом, и средством обучения обеих сторон. А за кадром остаются многие не менее важные процессы, в частности, управление проблемами, о котором мы поговорим в следующей статье.

В начало⇑

Комментарии отсутствуют

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