Как эффективно и правильно перейти на SaaS ?
Автор
Александр Рагель
Один из плюсов модели SaaS – существенная часть работ делается за вас. Иначе говоря, программное обеспечение системы безопасности и прочие элементы SaaS-системы устанавливаются и настраиваются поставщиком услуг и сдаются в готовом для использования виде
Один из плюсов модели SaaS – существенная часть работ делается за вас. Иначе говоря, программное обеспечение системы безопасности и прочие элементы SaaS-системы устанавливаются и настраиваются поставщиком услуг и сдаются в готовом для использования виде.
Многие MSP (managed services provider) предлагают широкую помощь при миграции на их облака. Часть сотрудников выделяется в специальные «консьерж-команды», которые и ведут клиента по этому пути, делая переезд в облако практически безболезненным. Выгоды для потребителя услуги очевидны: не надо приобретать железо и лицензии, не надо устанавливать программное обеспечение и конфигурировать систему под себя. Несмотря на это, было бы неверно считать, что переход на SaaS не требует от клиента никаких усилий. Компаниям по-прежнему необходимо определять структуру их бизнес-процессов, оценивать изменения, связанные с использованием новой модели, и готовить сотрудников к работе с новой системой. Первое, что предстоит сделать еще до сравнительного анализа и сопоставления текущих on-premise-мощностей с тем, что может предложить MSP, – однозначно дефинировать свои работающие бизнес-процессы.
Использование новых технологий или ПО может элементарно сбивать с толку сотрудников, приводя к задержкам в адаптации бизнес-процессов к реалиям новой модели. Упущения на этом этапе приводят к плачевным последствиям. Несколько лет назад широкий резонанс получила миграция Jaguar Land Rover на Google Apps. После «развода» с Ford компания была вынуждена поменять платформу (миграция проходила с традиционной корпоративной связки Microsoft Exchange Server + Outlook на SaaS в лице Google Apps). Проработка, очевидно, оказалась недостаточной, переезд в облако оказался крайне тяжел и вызвал массовое разочарование сотрудников, не принявших новинку, спущенную менеджментом.
Реальный запуск SaaS-системы – довольно оперативный процесс в сравнении с тем, сколько времени уйдет на проработку обоснования для переезда и понимание выгод от SaaS. Добросовестное выполнение «домашней работы» на стадии планирования обеспечит контролируемый на всех этапах переход и даст столь нужную предсказуемость его результатов.
Всесторонняя оценка SaaS-модели
Корпоративный сектор опирается сегодня на две основные модели: on-premise (внутренняя модель) и SaaS. На стадии выработки стратегии определение долгосрочных преимуществ той или иной модели имеет решающее значение: всестороннее сопоставление плюсов и минусов с каждой стороны даст правильное понимание, что именно будет наиболее полезно компании в средне- и долгосрочной перспективе.
Многие MSP, как западные, так и отечественные, часто прибегают к риторике, называя переход в облако чуть ли не спасением от всех бед, несущим непременно благотворное влияние на показатели компании. MSP, строящие бизнес не на сиюминутной выгоде и четко понимающие концепцию и тренд cloud computing, стремятся избегать такого подхода. Обманутые ожидания и разочарование услугой со стороны клиента – это удар по лояльности к MSP (а ведь воспитание лояльной аудитории – прямой интерес MSP). Поэтому, когда провайдер понимает невозможность выполнения всех запросов клиента, не нужно гнаться за финансовой выгодой – потеря клиента через месяц-два обернется куда более серьезными репутационными потерями.
Адекватная оценка своей целевой аудитории помогает всем. Например, если провайдер преимущественно оперирует аккаунтами до 50 пользователей, то аккаунт в 1000 неизбежно рано или поздно вызовет проблемы, которые могут закончиться взаимным разочарованием и уходом клиента.
Со стороны заказчика наиболее очевидный критерий оценки SaaS-модели – затраты. Наверняка большинство компаний предпочтет модель с меньшими объемом предварительных затрат. Но столь серьезное решение не должно строиться только на этом. Не менее важны следующие аспекты:
- Гибкость, предоставляемая каждой моделью. On-premise-реализация обычно открывает гораздо больше возможностей для кастомизации, но предварительные затраты на нее существеннее.
- Риски каждой модели. Модель SaaS может нести большие риски для корпоративной безопасности, так как данные передаются в сети Интернет и хранятся в ЦОД MSP.
- Лицензирование. Сколько пользователей могут одновременно использовать то или иное приложение по SaaS и как изменится оплата при увеличении числа пользователей?
- Сколько дискового пространства предоставляет MSP и сколько взимается за дополнительное место?
- Предоставляется ли техническая поддержка со стороны MSP? Бесплатна ли она и соответствует ли бизнес требованиям? Находится ли техническая поддержка в стране оказания услуги или она отдана на аутсорсинг? (В США многие MSP выставляют в качестве конкурентного преимущества US based support.)
Необходимо помнить и о дополнительных затратах, неочевидных на первый взгляд: стоимости ИТ-штата, занимающегося поддержкой on-premise-инфраструктуры, расходах на тренинги для работников при выборе SaaS-модели.
Сравнив модели по описанным критериям, компания гораздо четче увидит, какая из них предпочтительнее. Последние две характеристики необходимы для учета: какой путь отступления существует (тяжело ли будет вернуться обратно при возникновении проблем) и насколько крепка репутация MSP (давно ли провайдер представлен на рынке)?.
Согласование договора
Итак, компания только что обосновала переход на SaaS, и стратегия перехода утверждена менеджментом. Следующим шагом станет согласование договора с MSP. Часть SaaS-провайдеров не предоставляют клиентам составленные должным образом соглашения по сервисному обслуживанию (SLA). Причины прозаичны: нежелание брать дополнительную ответственность, возлагаемую SLA. Вместо высоко детализированной SLA куда чаще предлагаются формулировки, показывающие намерения «прилагать максимальные усилия для качественного оказания услуг», что не дает заказчику ровным счетом никаких гарантий и легко может использоваться провайдером в своих целях. Для защиты своих бизнес-интересов и четкого понимания, на что расходуются деньги компании, заказчик услуг должен требовать от MSP такого уровня SLA, который отвечает задачам бизнеса и позволит их исполнять без потерь.
Многие MSP используют SLA как психологическую и маркетинговую уловку, заявляя аптайм 99,999%, а то и все 100%. Чаще всего это означает либо заведомую неправду, либо провайдер в договоре прописывает особые условия, допускающие проведение работ в нужное ему время, которые не включаются в калькуляцию времени доступности сервиса.
Транспарентность в отношениях между пользователем услуг и провайдером чрезвычайно важна, и к ней нужно стремиться. Ее отсутствие может ярко проявиться во время перебоев сервиса – недостаточное информирование о реальной тяжести проблемы и сроках ее решения вызывает быструю потерю лояльности клиента. Провайдерам крайне важно понимать преимущества открытого подхода – проблемы бывают у всех, но не все на них одинаково реагируют. Предоставление клиентам обстоятельного RFO (reason for outage) повышает их доверие к MSP и репутацию провайдера в целом.
Отсутствие скрытых платежей за использование сервиса, отсутствие лимита на число пользователей, основа, на которой предоставляется техническая поддержка, – все это должно быть занесено в договор.
Наконец, заказчику важно понимать, как осуществляется аварийное восстановление и как выстроена безопасность у провайдера (есть ли системы резервного копирования, несет ли MSP ответственность за несанкционированный доступ к пользовательским данным).
Все эти факторы важно учитывать при обсуждении договора с SaaS-провайдером, и в случае несоответствия ожидаемого и предоставляемого уровня услуги необходимо либо добиваться нужных поправок, либо искать другого MSP.
Структурирование процессов
После внедрения SaaS-решения компании понадобится команда ИТ-профессионалов для управления и поддержания новой модели. Определение ролей в этой команде до этапа фактического внедрения помогает достичь большей эффективности и лучше формализовать последующие шаги.
Внедрение SaaS-модели не занимает много времени, но наличие хорошо продуманного графика и структурной схемы построения работ всегда помогает. Определение наиболее важных этапов работ и четких сроков по ним делает переход на новую модель прозрачным и предсказуемым.
Убедитесь, что данные будут максимально защищены в ЦОД провайдера: идеальный вариант – географически разнесенные ЦОД. Разделение ролей для административного доступа в новую систему – важная функция, исполнение которой остается на клиенте.
Переводя бизнес в облако, следует помнить и об организации системы технической поддержки. Оперативная поддержка в рамках SaaS-модели в большинстве случаев осуществляется MSP, но зачастую приходится иметь дело с «допиливанием» специфичного ПО, для чего привлекаются либо имеющиеся специалисты, либо нанимаются новые.
Ошибка, которую легко совершить и сложно исправить, – думать о переходе в облако как панацее и избавителе от вышеперечисленных затрат. Провайдеры проведут установку обновлений на систему, выполнят задачи по обеспечению ее бесперебойного функционирования, но вопросы кастомизации нетиповых решений и поддержка их в состоянии работоспособности останутся в зоне ответственности клиента.
При выборе MSP нельзя забывать и о том, что SaaS – модель новая, этот рынок еще в стадии формирования: поглощения на нем происходят регулярно и число стабильных игроков, действующих действительно долго, невелико. Чтобы обезопасить себя от рисков, которые несет формирующийся рынок, необходимо иметь запасной вариант.
О чем нужно помнить при переходе на SaaS
При переходе на SaaS бизнес должен принимать во внимание и учитывать огромное количество факторов. Вот десять самых главных из них.
1. Однозначно трактуйте причины перехода на SaaS
Не так важно, что стало причиной перехода на SaaS-модель. Главное – она должна быть конкретна для бизнеса. Мотивом перехода может быть повышение эффективности своей работы за счет избавления от управления своей ИТ-инфраструктурой и следующей за этим возможности полнее сфокусироваться на бизнес-процессах. А можно улучшить совместную работу географически распределенных офисов. Что бы ни было причиной – ее нужно четко понимать.
2. Как это сделать
Компания приняла решение. Первый шаг – создание детального плана действий, который учтет и опишет все этапы внедрения, покажет, за счет каких ресурсов это будет сделано, выяснит, полностью ли соответствует MSP предъявляемым к решению требованиям.
3. Вечером SLA – утром договор
SLA – важный документ, именно он однозначно определяет ответственность MSP за неисполнение обязательств. Понимая, за что платятся деньги, компания избегает проблем с обманутыми ожиданиями в будущем. Только после получения полностью устраивающего компанию SLA следует переходить к дальнейшим шагам.
4. Поправки к договору не должны быть только в интересах MSP
MSP может располагаться в любой точке земного шара, а потому возможны разночтения в интерпретации некоторых формулировок. Предположим, что российская компания переехала в американское облако. Первое, о чем нужно помнить, – разница часовых поясов. Последствия этого иногда неочевидны, но кто предупрежден, тот вооружен: понятие business hours в большинстве случаев коррелирует с той временной зоной, где находится ЦОД MSP. И гарантированная доступность сервиса будет приходиться на часы, когда российский пользователь услуги спит. Работая в американском MSP, я неоднократно сталкивался с клиентами, которые не учитывали этот фактор.
Понятие business hours может отличаться не только по временной зоне, но и по интерпретации конкретного временного промежутка. Провайдер, например, может интерпретировать понятие как «с 9 до 18 часов», что для бизнеса, который оперирует форматом «24×7», неприемлемо. Дефиниция подобных вещей необходима. Их игнорирование может оказаться фатальным для бизнеса.
.
5. Требования к технической поддержке
Уровень ИТ-профессионалов, которые будут поддерживать решение, необходимо рассматривать в следующем контексте:
- Хватит ли навыков существующих работников или придется нанимать профессионалов с более широкими профильными знаниями?
- Каковы могут быть затраты на новых работников?
- Каковы требования к технической квалификации тех, кто поддерживает систему, со стороны MSP?
- Требуется ИТ-гений или будет достаточно людей с обычными знаниями?
Уровень технической поддержки, нужной бизнесу, зависит от уровня технической поддержки, предоставляемой провайдером. Если со стороны последнего речь идет только о предоставлении сервиса и базовой документации, бизнес будет вынужден создавать ИТ-команду для поддержания требуемого уровня сервиса.
6. Действия по возмещению ущерба
Компания уже обсудила ответственность MSP за неисполнение SLA – теперь время уточнить условия и порядок возмещения ущерба. Автоматизирован ли процесс? Если нет, что именно требуется от клиента? Эти шаги важны, поскольку многие MSP ограничивают срок, в течение которого можно требовать компенсации после инцидента.
7. Убедитесь, что сотрудники обучены
Внедрение SaaS-модели на стороне MSP – прямолинейный процесс, при видимой легкости которого можно упустить вопрос обучения сотрудников работе с новой системой. Обучение необходимо как на этапе внедрения, так и после него, это обеспечит быстрое начало продуктивного использования системы.
8. Планируйте «стратегию выхода»
Легко ли будет компании сменить провайдера? Вернуться на on-premise-модель?
Что станет с данными, хранящимися в ЦОД провайдера? Как обеспечивается их получение от провайдера?
Некоторые провайдеры максимально усложняют «развод». Мне знакомы случаи, когда западные MSP оценивали предоставление данных уходящему клиенту в размере нескольких среднемесячных платежей. Все эти моменты необходимо просчитывать на этапе перехода к тому или иному MSP.
9. Парк компьютеров уменьшится
Переход на модель SaaS предполагает уменьшение парка компьютеров. Это справедливо и в отношении лицензий, которые использовались на них. В долгосрочной перспективе освобождение от затрат на железо и лицензии сулит бизнесу выгоды. Снижение затрат произойдет как за счет отсутствия закупок новых серверов и лицензий, так и за счет отсутствия необходимости администрировать этот парк и тратить на него электроэнергию.
10. Сколько это будет стоить
При традиционной on-premise-модели компания платит единовременно за серверы и лицензии в зависимости от того, сколько пользователей будут использовать систему.
С SaaS-моделью вопрос платежей менее однозначен. Возможен вариант фиксированной ежемесячной оплаты или платы только за фактическое использование ресурсов MSP. Возможно, придется иметь дело с лицензированием или выходом за предоставленную дисковую квоту, – просчитывать эти предполагаемые затраты необходимо.
При планировании перехода на SaaS-модель только детальный учет всех факторов и их анализ позволят реально оценить, приведет ли предпринятый шаг к снижению затрат.
(Продолжение следует)
Опубликовано 28.08.2011