Приведем пять типовых разделов для разработки или корректировки SLA и три нетиповых.
Времена типовых шаблонов договора сервисного сопровождения или предоставления определенных услуг прошли. Используя такие формы, невозможно гибко реагировать на внешние условия или даже внутренние процессы, которые повлекут существенные изменения. А еще серьезнее нужно учитывать взаимосвязанные решения, процессы и даже целые платформы. И здесь для корпоративных подписок и других подобных инструментов необходимо разрабатывать отдельный подход для устойчивости бизнес-процессов, базирующихся на подобных решениях.
Например, корпоративные подписные решения, построенные на базе сервисов Microsoft, сейчас не просто находятся в зоне риска, а скорее становятся самым настоящим риском для тех компаний, которые использующих данные продукты без явных альтернатив. И это только один пример. А если сервисы отраслевые, то и альтернатив не особо много.
Частные и государственные компании уже могли видеть первые тревожные сигналы еще в далеком 2014 году, когда часть сервисов и решений начали запрещать для эксплуатации в России. Но тогда этот процесс был скорее точечным и локальным. Сейчас масштабы изменились. И подход к работе с сервисами должен меняться. Неважно, локальный это подписной сервис или глобальный, но определенные «правила игры» нужно учитывать всегда. Далее приведу пять типовых разделов для разработки или корректировки SLA и три нетиповых.
Типовые разделы
- Структура и показатели услуг (сервисов). Конечно, это самый ключевой и даже базовый пункт для SLA. Но далеко не всегда он реализован оптимально. В данном пункте нужно тщательно учесть не только сами сервисы и основные показатели по ним, но и прописать структуру предоставления сервисов, структуру мониторинга, ответственных с обеих сторон и допуски в показателях, которые могут входить в норму. Лишь в таком формате сервисы будут по-настоящему прозрачно зафиксированы в документе и не вызовут спорных ситуаций (по крайней мере снизят неопределенность).
- Время бесперебойной работы сервиса, которое должно гарантироваться не только в течение года, но и помесячно. При этом необходимо отмечать и время восстановления, и время фиксации возможной деградации сервиса или полное его отсутствие. И здесь, конечно, учитываем финансовую сторону проблем сервиса и ответственность провайдера.
- Скорость и способы оповещения о полной или частичной потери сервиса. Важно учесть несколько вариантов оповещения и не одного ответственного со стороны заказчика, а нескольких. Представьте, что ответственный в договоре только один и у него указана рабочая почта и рабочий телефон, а ситуация происходит, как это часто бывает, за пределами рабочего времени. При этом и процесс мониторинга со стороны провайдера подписки должен быть прописан. В идеале, если провайдер предоставляет какой-либо инструментарий для представителей заказчика со структурой мониторинга и визуальной составляющих данного процесса.
- Показатели временного решения при невозможности восстановления сервиса в регламентируемые сроки по SLA. Здесь важно прописывать детальную структуру формирования временного решения, в каких случаях оно применимо, как повлияет на предоставляемый сервис и как будет учитываться компенсация для заказчика. Был случай в практике, когда временное решение прописывалось в SLA так, что при любом минимальном отклонении по показателям сервис переходил в условно экстремальный режим. При этом потребность была только в 10% случаев, а деградация сервиса происходила каждый раз.
- Структура коммуникаций в рамках SLA в части всех возможных процессов: технических, юридических, финансовых, информационных и прочих. Важно зафиксировать в SLA, какие вопросы в какое время могут решаться и не только в части техподдержки, но и в части юридических аспектов. Контактных данных должно быть много, как бы парадоксально это ни звучало. Если у вас в SLA один телефон горячей линии, то можно не только потерять время и нервы на голосовых меню, но и реальные деньги в рамках простоя бизнес-процессов.
Нетиповые разделы
А теперь о нетиповых пунктах. Я не настаиваю, что они обязательные, но учитывать такую возможность рекомендую.
- Альтернативные варианты предоставления сервисов, например, критически важных, а также показатели при условии, что для провайдера ситуация является форс-мажором. Например, какой-то софт для России принудительно закрыли, и в таком случае...