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