Фобии IT-аутсорсинга. Фобия третья

Вслед за первыми двумя фобиями, которые мы обсудили в предыдущих заметках, приступаем к Фобии №3:

Аутсорсер действует в рамках времени реакции, прописанном в SLA, и поэтому реагирует на инциденты заведомо медленнее, чем собственная IT-служба, которая решает проблемы "как можно быстрее".

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

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

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

Что вообще значит "низкая скорость реакции"? В тех случаях, когда мне приходилось с такой претензией встречаться, как правило, это касалось срока закрытия инцидента, указанного в SLA. Заказчик на него смотрит и говорит: "Это слишком долго!" Но в SLA указывается максимально допустимое время обработки обращения. Это не означает, что аутсорсер на устранение каждого инцидента будет тратить, к примеру, восемь часов, которые указаны в SLA. Это означает, что такая работа займет не больше восьми часов. Если же этот срок превышен, то исполнитель нарушает SLA и начинает терять деньги при условии, что параметры SLA привязаны к вознаграждению исполнителя.

Как правильно действовать, чтобы время обработки обращений соответствовало потребностям бизнеса? Во-первых, необходима система приоритетов, позволяющая ранжировать пользователей. Следует выделить группу VIP-пользователей, время которых очень дорого. Для обработки обращений, поступающих от VIP-пользователей, в SLA должны быть назначены особые параметры. Из собственного опыта я знаю, что в начале взаимодействия с компанией-аутсорсером заказчик часто не видит целесообразности выделения VIP-пользователей в отдельную категорию. Но потом выясняется, что такие пользователи есть и обрабатывать их заявки нужно в срочном порядке ("Наш финансовый директор не может ждать!"). Можно уменьшить максимальное время обработки VIP-обращений до одного часа и записать этот параметр в SLA. Но это не значит, что остальные заявки должны обрабатываться с той же скоростью - в большинстве случаев это и не требуется.

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

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

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

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

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

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