Предлагаемые поставщиками и «тщательно проработанные» контракты далеко не прозрачны. Источник: computerwoche.de |
Облачным сервисам все еще не достает зрелости. Как подчеркнула Алекса Бона, вице-президент Gartner, на конференции Gartner IT Leadership Trends 2012, главный показатель этого – контракты, пока направленные исключительно на соблюдение интересов провайдеров, и ничего не предусматривающих для защиты пользователя.
Конференция в Москве, состоявшаяся в конце мая, собрала весьма значительную аудиторию. Охваченные темы включали изменение роли ИТ-руководителя, влияние современных тенденций на ИТ-деятельность, а также возможности ИТ по трансформации бизнеса. Но наибольшее оживление вызвало одно из выступлений Бона, фокусирующей свою работу на тематике управления ИТ-активами. Оно было посвящено оптимизации контрактов с поставщиками облачных сервисов.
Не секрет, что с вендорами традиционных ИТ-продуктов можно вести переговоры, кастомизируя их предложения. А смысл облачных сервисов, по крайней мере, с точки зрения провайдера, заключается именно в стандартизации услуг с целью их удешевления. Считается, что попытка перестроить контракт ломает бизнес-модель провайдеров – именно этим они объясняют жесткость своих позиций.
Тем не менее, переговоры с провайдером вести можно и нужно. Разумеется, к ним следует тщательно готовиться – и ИТ-директору, и отделу закупок, и юристам компании.
Алекса Бона: большинство облачных контрактов пока направлено исключительно на соблюдение интересов провайдеров |
Дело в том, что большинство контрактов содержит массу подвохов. Во-первых, платить только за реально потребленные услуги – а это один из главных рекламных слоганов – обычно невозможно: по умолчанию речь идет об оплате максимально возможного объема услуг, предусмотренного соглашением. Другим подводным камнем является декларируемая быстрота внедрения и гибкость. Но иногда реакции провайдера приходится ждать очень долго, особенно при необходимости изменения условий действующего контракта.
Отдельную угрозу представляет ситуация, когда провайдеры идут напрямую к бизнес-пользователям, противопоставляя себя ИТ-департаментам, медлительностью которых многие недовольны. В результате скоропалительных решений контракт заключается без изучения и каких-либо переговоров, и компании втягиваются в соглашения на невыгодных условиях. Согласно проведенным исследованиям, в среднем контракты, заключенные в обход ИТ-департамента, оказываются на 30% дороже. Более того, зачастую они заключаются менеджерами, не имеющими понятия об аббревиатуре SLA.
Еще одним крупным риском является приобретение избыточного набора сервисов, получившее шутливое название Shelfware-as-a-Service (термин Shelfware – «ПО, положенное на полку» — применяется к традиционным программным продуктам, приобретенным, но по каким-либо причинам не используемым). Вендоры будут подталкивать к этому разными маркетинговыми приемами, но идти у них на поводу не стоит: стоимость владения в итоге окажется печальной.
Следует внимательно изучать контракты: иногда они содержат кабальные условия. Например, ими может не предусматриваться снижение объема потребления (а значит, и возможностей для сокращения издержек). Часть платежей может быть фиксированной, и не зависеть от потребления услуг.
Зачастую клиенты входят в контракт с малыми объемами сервисов, рассчитывая впоследствии расширить использование и получить более выгодные условия. Однако если не оговорить цены в самом начале, снижения их за объем приобретаемых услуг провайдер не даст.
Наконец, многие сделки заключаются с помощью хитрости: желая продать сервис, вендор делает значительную скидку. Но через некоторое время действие скидки заканчивается, и заказчик раскошеливается «по полной».
Предлагаемые поставщиками и «тщательно проработанные» контракты далеко не прозрачны, в них не прописаны ключевые условия. Например, показатель доступности оказывается не зафиксированным на бумаге, а указанным на сайте. В результате он может изменяться – разумеется, обычно в сторону уменьшения. В этом случае интернет-страницу правильнее распечатать и приложить к контракту. Кроме того, контракты могут не включать показатели по времени аварийного восстановления, а доступность сервисов обычно измеряется в ЦОД провайдера и не имеет ничего общего с реальной доступностью с учетом каналов связи.
Также стоит отметить, что в целом облачные проекты обладают массой скрытых расходов. Наиболее распространенные из них связаны с минимальным набором сервисов, включенных в контракт. Многие из клиентов считают, что обслуживание и поддержка включены в контракт, однако обычно включенными оказываются лишь базовые сервисы. Дополнительная плата за обслуживание категории premium может составлять до 50% стоимости аренды. Примерно та же ситуация складывается с объемом хранимых данных: бесплатным бывает лишь очень ограниченный объем. За дополнительный же объем взимается оплата, существенно превышающая среднерыночную.
Отдельной проблемой является качество обслуживания. Большинство контрактов составляются так, что клиент должен сам сообщать о проблемах, а провайдер – лишь рассматривать заявления. Между тем, у провайдера есть все возможности для самостоятельного отслеживания сервисов. Более того, как поставщик услуг, он должен сам обеспечить готовность оборудования и выполнение заявленных условий.
Как призывает Бона, следует требовать штрафов за нарушения обязательств, которые никогда не содержатся в контрактах по умолчанию, и права расторжения контракта при нарушении уровня обслуживания. Компенсация в виде некоторого времени бесплатного пользования услугами видится весьма сомнительным вариантом. Не факт, что в случае серьезных нарушений останется желание ими пользоваться. Скажем, если допущена утечка данных, есть ли польза от бесплатного продления подписки на год?
Важно помнить, что одними из важнейших преимуществ облаков являются именно быстрота и дешевизна внедрения, а также простота миграции. Если действия провайдера влияют на эти показатели, смысл облачного проекта оказывается под большим вопросом. В этом случае важно иметь «План Б» и быть готовым покинуть стол переговоров, если условия и риски неприемлемы.