Облачный Service Desk: каковы риски при выборе решения для клиентской поддержки

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

Каковы аргументы против облачной автоматизации служб поддержки и критичны ли они 

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

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

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

В плане потенциала доработок все тоже индивидуально. Ряд облачных Service Desk гибко настраивается под самые разные процессы. Например, для службы поддержки можно реализовать особые сценарии назначения исполнителей по клиентским запросам, этапы согласования задач, выстроить аналитику в нужных бизнесу разрезах. Зачастую со многими такими настройками технические специалисты со стороны бизнес-заказчика справляются своими силами.

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

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

Контраргумент. Опасность потери данных существует, даже если компания разворачивает Service Desk в собственном закрытом контуре. Бывают случаи хакерских атак и утечки информации в организациях, которые и не используют облачные инструменты. Также не исключен «слив» конфиденциальных сведений изнутри недобросовестными сотрудниками. А от аварий с последующей утратой данных не застрахованы и собственные ЦОД любой компаний. 

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

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

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

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

Что учесть в вопросах безопасности при выборе облачного решения 

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

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

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

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

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

Что в итоге

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

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