Как российские облачные сервисы для бизнеса тормозят собственный рынок +25


В момент создания, 4 года назад, наша компания понимала свое предназначение: мы упрощаем малому бизнесу использование SaaS. И хотя изначальная бизнес-модель была выбрана неверно, все это время мы находились в перманентном поиске собственной ниши. Мы застали всплеск облачных сервисов в России, видели спад и видим начинающийся второй подъем. Специфика нашего бизнеса в объединении SaaS-продуктов. И мы видим, как наши передовые SaaS-компании вставляют палки в колеса собственному рынку.

Разработчики SaaS упорно пытаются продавать ценностные продукты как массовые


SaaS не определяет подход к построению бизнеса, а характеризует способ доставки программного обеспечения. То, что к SaaS относятся как однозначные аппы (например, Google Keep), так и сложные продукты (например, Salesforce Sales Cloud), создает некоторую путаницу. Когда SaaS стал рассматриваться в России как перспективный бизнес, укоренились две противоречивые идеи. С одной стороны, SaaS стал синонимом продукта для массовых продаж, с другой стороны, создаваемые продукты ориентировались исключительно на бизнес.

Примером для подражания считалась компания 37signals (ныне – Basecamp). В штате было 18 сотрудников, а продуктом компании – сервисом по управлению проектами – пользовались 2 миллиона клиентов. Идеальный SaaS: большое количество клиентов дает большую выручку, эффект масштаба позволяет экономить на инфраструктуре и специалистах. Этот впечатляющий пример вдохновил разработчиков концентрироваться на продукте и максимально избегать дорогой офлайн-деятельности. Выбранный подход подтверждали также Evernote, Dropbox и Gmail, которые выросли именно как массовые продукты.

При этом основатели создавали B2B-сервисы исходя из двух тезисов:
  1. ни частные лица, ни бизнес пока не привыкли к SaaS, но у последних хотя бы есть деньги;
  2. российскому бизнесу непременно нужен инструмент по автоматизации рабочих процессов.

Второй тезис подкреплялся опытом работы в ИТ-аутсорсинге, где процессные подходы западных компаний становились откровением (и вместе с тем ответом на вопрос, почему «у них там» чистые тротуары и все улыбаются).

Получается, что разработчики создавали сервисы, организующие бизнес-процессы компании, а значит, претендующие на изменение сложившихся устоев, но при этом стремились исключить офлайн-деятельность. Сложный программный продукт для бизнеса — это ценностное предложение, которое помимо сложных продаж подразумевает и сложное внедрение, и продавать его как массовый продукт — некорректно. Эта мысль до сих пор остается на заднем плане. Разработчики ждут от клиентов быстрых выводов, превратив свои сайты в подобия целевых страниц (например, «Мегаплан»), а их телефонные операторы до сих пор отрицают необходимость внедрения (например, «МойСклад»).

Когда клиентов побуждают принять импульсивное решение, которое существенно повлияет на жизнь компании, у них возникает закономерный ступор. Чтобы понять его причины, нужно мыслить шире и усомниться в истинности изначальных тезисов. Устраняли ступор оптимизацией продаж и маркетинга, концентрируя на этом усилия. Нутром чуя необходимость офлайн-работы с клиентами, «Мегаплан» взрастил отдел телефонных продаж. Изобретались разные ухищрения с подпиской: «Эльба» заменила месячный период на годовой — чтобы ценили и «подсаживались», «Деловая среда» подписывала клиентов посредством незаметных пунктов в анкетах на банковские услуги. Упрощалась функциональность регистрации и оплаты. Применялись мощные механизмы вроде автоматически оптимизируемой контекстной рекламы, ретаргетинга и A/B-тестирования. Сегодня в моде «живосайты» и «колбекхантеры», которые отлавливают скучающих и слабовольных. Базы данных старейших сервисов вроде «Битрикс24» и «Мегаплана» содержат миллионы неактивных клиентов, и это те клиенты, чьи надежды не оправдались.

Интересно, что глубокое изучение методов продаж трансформировалось у некоторых основателей в миссионерское самосознание: «Бизнесмены не покупают мою CRM, потому что не умеют продавать и делать бизнес», — заключают они и начинают самозабвенно «обучать птиц летать». Бизнесмены были, есть и будут, и отсутствие интереса к CRM является индикатором того, что для их бизнеса есть кое-что поважнее.

Сегодня, подключаясь к wi-fi, тяжело не вляпаться в чью-нибудь воронку продаж. Сценарии регистрации и оплаты в сервисах предельно оптимизированы. Эти шаги занимают не более 4 минут. Затем клиент, потыкавшись в системе, с высокой степенью вероятности становится мертвым лидом.

Сложный программный продукт для бизнеса — это ценностное предложение, которое помимо сложных продаж подразумевает и сложное внедрение, и продавать его как массовый продукт — некорректно.


Разработчики SaaS угнетают интеграторов и не оставляют им места в мировоззрении клиентов.


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

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

Но есть некоторые особенности в том, как создатели сервисов строят свой партнерский бизнес:
  1. Разработчики сервисов преподносят свой продукт клиентам как готовое решение, не требующее внедрения, и этим вводят клиентов в заблуждение. В мировоззрении клиентов нет никаких интеграторов. И хотя мы видим раздел «Партнеры» почти на каждом сайте, и там можно оставлять заявки, компании – разработчики сервисов не дают клиентам однозначного сигнала, что эти партнеры нужны.
  2. Первым делом разработчики сервисов пытаются продать подписку от себя. Иными словами, конкурируют с теми, кто согласился вместо них делать сложную и дорогую офлайн-работу. Эти SaaS-компании похожи на молодых менеджеров, которые мечутся между желанием делегировать полномочия и боязнью потерять власть, в итоге завязывают вопросы на себя и тормозят общий процесс.
  3. Даже если разработчики сервисов осознаЮт роль партнеров, они исключают существование интеграторов как класса, подразумевая, что их партнеры — только их партнеры. Это уводит клиентов от мысли, что интеграторы могли бы подбирать клиентам оптимальные сервисы и выступать собственно интеграторами сервисов между собой.

Таким образом, SaaS-компании понимают стратегию «win-win» так, что оба «win» должны принадлежать им. Партнерам отводится роль верных псов, которым, если повезет, иногда падает заявка с хозяйского стола. И эта не совсем этически верная стратегия сегодня является нормой.

Создатели сервисов конкурируют с теми, кто согласился вместо них делать сложную и дорогую оффлайн-работу.


Разработчики SaaS не считают интеграцию основной пользовательской функциональностью


Я занимался интеграцией сервисов последние 8 лет. Сначала для компании Sesame Communications, где мы поддерживали интеграцию с 22 системами, называемыми Practice Management System (сокращенно PMS). В кулуарах ходила грустная шутка: «Все проблемы от PMS» — эти системы обычно обновлялись без предупреждений, поэтому ошибки часто обнаруживались самим клиентом (хуже некуда!). Затем в Startpack мы интегрировали почти двадцать российских SaaS-продуктов и сделали для себя некоторые открытия.

Начнем с того, что наличие API в большинстве случаев обусловлено заботой об архитектуре, это позволяет вынести бизнес-логику в отдельный слой, а сверху приторачивать любой пользовательский интерфейс — веб, мобильное приложение, автоматические тесты. Технари делают API прежде всего для себя (и просто потому, что это прикольно). О клиентах речи не идет.

Когда встречаются две группы технарей, в 10 случаях из 10 между ними возникает неприязнь. Феномен был описан еще в 1961 году социологом Музафером Шерифом (Muzafer Sherif), который выяснил, что для возникновения вражды достаточно разделить людей по отдельным помещениям и каждой группе дать свое гордое название. Ошибка руководителей SaaS-компаний в том, что подобные трения игнорируются, а иногда даже поощряются. Результатом становится бизнес-процесс, лишенный ответственных лиц, а исследование багов начинается со слов «Опять эти негодяи...». Клиент, столкнувшись с нетривиальной ошибкой интеграции, скорее всего, не найдет того, кто будет сопровождать его.

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

Кроме того, когда у сервиса появляется API, компания радуется, что теперь сложные задачи решаются размахиванием спецификацией в воздухе. Разработчики расстраиваются, когда API не совпадает с чужим, и крайне неохотно подстраиваются под «тех негодяев» (которые «настолько тупые, что используют SOAP, а не REST»). Поэтому, когда клиент просит нестандартное решение вроде интеграции со СКУД, менеджер «решает вопрос» отправкой спецификации, что не дает клиенту (производителю мебели, например) ничего, кроме противоречивых чувств. Совет обратиться к интегратору воспринимается с недоверием, ведь разработчики сделали все, чтобы интеграторов в мировоззрении клиента не было.

Несмотря на стремление сервисов к интеграционной расширяемости посредством маркетплейсов («Битрикс24») и специальных разделов (amoCRM), в целом связи между сервисами не рассматриваются как полноценные пользовательские сценарии, требующие оптимизации, ответственных лиц и поддержки. В этой сфере могла бы бурлить жизнь, рождая разнообразие экосистем и удовлетворяя любой ощутимый спрос, но сервисы пренебрегают этим пластом пользовательских потребностей.

Совет обратиться к интегратору воспринимается компанией-пользователем с недоверием, ведь разработчики сделали все, чтобы интеграторов в мировоззрении клиента не было.


Разработчики SaaS игнорируют основной страх клиентов


Каждый день я общаюсь с кем-то из пользователей нашего сервиса по подбору облачных приложений. Подавляющее большинство историй сводится к двум типам:
  1. «Мы узнали о продукте таком-то, заплатили деньги, но не разобрались в нем и бросили»;
  2. «Я руководитель, уже месяц откладываю решение по SaaS-продукту, потому что боюсь прогадать».

Поговорим о втором типе. Если в IaaS и PaaS вопрос резервного копирования и миграции никого не беспокоит — образы систем и дампы легко сохраняются, копируются и разворачиваются в другом месте, в SaaS этот вопрос является основным опасением. В отчете компании «Мегаплан» «Потенциал рынка SaaS/B2B в России» (2013 г.), респонденты, понимающие ценность онлайн-сервисов, называли следующие причины неиспользования SaaS: 27 % — страх потерять данные, 26 % — страх потерять доступ. 53 % закономерного недоверия, которые трактуются разработчиками как «непросвещенность», «предрассудки» и «заблуждения»!

Будем откровенными: когда клиент подписывается на SaaS для бизнеса, это не то же, что платить за Интернет. Он приобретает актив, требующий вложений в виде оплаты подписки и временных затрат на изучение и внедрение. Вложения должны окупать себя, дивиденды должны расти, риск потери вложений должен быть минимальным. В переводе на житейский облачный язык, клиент готов подписаться, если уверен, что сервис принесет пользу, что польза будет максимальна (сервис станет флагманом) и что компания-разработчик не закроется. И если вклады в банке хоть как-то защищаются государством, здесь никаких гарантий никто не дает.

Предприниматели не дураки. Выбирая сервис, они интуитивно оценивают его как актив. Их не впечатляет тарабарщина о RAID и дата-центре уровня Tier III. В глубине души они хотят получить ответ на вопрос: «Я подсажу на ваш сервис свою фирму, а что будет, если ваша компания закроется?» В терминах актива характеристикой ликвидности является возможность быстро и без потерь найти замену.

И тут SaaS-компаниям ответить нечего. Нельзя быстро и без потерь скопировать проект из системы «ПланФикс», например, в WireCRM, нельзя просто так перенести бухгалтерию из «МоегоДела» в «Небо». Более того, SaaS-компании исподтишка считают это частью своей стратегии: мол, не мы такие, это SaaS такой. Freemium-модели Evernote и Google «Подсаживайся бесплатно, плати, когда уже не сможешь слезть» — идеал, к которому разработчики сервисов стремятся в различных вариациях. Единственный ответ на опасения клиента «У нас все надежно» означает попросту, что ликвидность актива нулевая.

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


Как перестать тормозить рынок


Разработчики SaaS противопоставляют себя принятой в корпоративном секторе вертикали «вендор — системный интегратор — заказчик». В одном из интервью Александр Прозоров (на тот момент – директор по работе с партнерами компании «Мегаплан») даже подчеркивает, что в SaaS в таком явном виде отсутствует конфликт интересов между системным интегратором и заказчиком, полагая, что SaaS – это не просто разовое использование некоторого сервиса, а основанное на долгосрочном сотрудничестве взаимодействие между поставщиком и потребителем. На практике мы видим прямо противоположное.

Давайте посмотрим на структуру туристического бизнеса в России. Туроператор создает массовый продукт, а персональный подход к клиенту находит турагент. Туроператор решает технические задачи по созданию продукта, использует эффект массы, оптимизирует издержки. Турагент помогает клиенту выбрать подходящий продукт, берет на себя заботы по оформлению, сопровождает, снимает страхи и сомнения.

Туроператоры с уважением относятся к турагентам, называя их «наше все», они не конкурируют с ними и не внушают клиенту мысль, что тур хорош сам по себе и турагент не нужен. До 2010 г. невозможно было купить тур на сайте оператора, и даже сейчас прямая покупка тура у оператора не дает финансовых преимуществ. Туроператоры не подминают агентства под себя, они с уважением относятся к возможности выбирать любой оптимальный тур. Это дает рынку необходимое разнообразие, заполняет пустующие ниши, снимает недоверие.

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

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

Клиенты-новаторы уже попробовали существующие сервисы. Впечатлительные клиенты, отловленные массированным маркетингом, уже заплатили деньги. Настает время прагматиков. Наши бизнесмены доверяют людям. Бизнесменам нужны долгосрочные отношения с ответственными лицами, с теми, кто умеет и любит работать с клиентом офлайн, для кого слово «сервис» не пустой звук. И этим новым драйвером станут интеграторы. Чем быстрее разработчики SaaS это поймут, тем быстрее настанет новый облачный ренессанс в России.

Все описанные проблемы SaaS могли бы решить интеграторы, если бы SaaS-компании относились к ним так, как туроператоры относятся к турагентам.


Опубликовано в журнале В Облаке.РФ №3

Спикер: Алексей Федоров, генеральный директор компании Startpack

Третий номер журнала «В Облаке.РФ» уже доступен для бесплатного скачивания на мобильные устройства в магазинах AppStore и Google Play.




К сожалению, не доступен сервер mySQL