Каталог услуг и SLA: первый год с формализованными договорами

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

Откуда взялась идея

Последние года два-три ITIL в России перестал быть только академическим текстом. Крупные заказчики - банки, телеком, страховые - стали требовать SLA в договорах уже не как дань формальности, а с реальным намерением штрафовать за нарушения. Средний бизнес потянулся следом: раз большие так делают, значит так правильно.

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

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

Что сделали

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

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

Запрос на обслуживание - предсказуемые задачи: создать пользователя, установить ПО, выдать доступ. Нет деградации сервиса, есть ожидание. Параметр один: время выполнения от момента оформления запроса.

Запрос на изменение - всё, что меняет инфраструктуру: новый сервер, перенос сервиса, обновление конфигурации с риском. Здесь SLA не на скорость реакции, а на процесс: оценка, согласование, окно для внедрения, откат.

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

Как внедряли

Новые клиенты получили новые договора сразу. С существующими было сложнее: никто не любит, когда меняют правила посреди игры. Мы объясняли, что ничего не ухудшаем - просто фиксируем то, что и так делали. Большинство восприняли нормально. Один клиент попросил переговоры - провели, скорректировали пару параметров.

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

Что получилось

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

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

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

Где сейчас

Каталог и SLA-параметры уже у всех клиентов. Учёт обращений ведётся. Отчёты по выполнению SLA мы начали отправлять клиентам ежемесячно - это их удивило в хорошем смысле: раньше никто так не делал.

Следующий шаг, который обсуждаем, - сделать отчёт автоматическим и более детальным. Пока считаем руками, что занимает время и создаёт риск ошибки. Но это уже отдельная задача.