В момент создания, 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.

Комментарии (21)


  1. gavBTR
    15.09.2015 20:32
    +8

    Аааааааааааааа!!!

    — Здравствуйте, а у вас есть готовые конфигурации под разные бизнесы?
    — Бла бла бла, нет!
    — Так а почему нет то, неужели я первый с просьбой автоматизации своего сервиса обратился?
    — Бла бла бла, нет смысла в конфигурациях, потому что вам проще самим сделать. Тем более тех поддержка у нас бесплатная. Вы нам только напиши, что хотите.
    — Да я не хочу разбираться, придумывать с нуля все бизнес процессы, покажите мне готовую конфигурацию, а я её уже под себя переделаю. И если понравится — куплю…
    — У нас конфигураций нет, но вы можете купить нашу версию, всего лишь за 2000 руб в месяц и мы вам поможем её переделать под себя. Тем более у нас много видеосеминаров и бла бла бла

    Я вот как потенциальный клиент вообще этого не понимаю. Оплатил за фреш офис, барышня позвонила недельку вам все понравилось, почему не работаете, что не устраивает, посмотрите наше обучающее видео… Ааааааа! У меня акк висят в мегаплане, в лптрекере, битрикс24 кое как пытаемся внидрить и вот теперь в фреше…

    Я знаю, что мне нужна нормально настроенная CRM и я готов купить уже готовое решение, пусть кривое, путь не для моего сервисного центра, а для сервиса по ремонту стиральных машинок, но уже готовое…

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

    Я понимаю, сапожник без сапог, но в рамках моего бизнеса так и получается, работаем по старинке с таблицами, календарём и записью разговоров на андроиде в гугл облако… и 1с тьфу… Потому что руки не доходят что то интегрировать актуальное.

    А так бы хотелось:
    — Алексей, вот примеры конфигураций. Вот стоимость внедрения. Вот контакты наших коллег интеграторов. Вам как удобней платить? Счет или нал? Если за наличку, то можно кредит оформить. Вам в каком банке удобно?

    рай…


    1. alex_ant
      15.09.2015 20:51

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


      1. agalitski
        15.09.2015 21:39

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


        1. alex_ant
          15.09.2015 22:01

          То, что эти решения есть, не говорит о том, что они самодостаточны и полностью удовлетворяют потребности любого представителя направления. Не говоря уже о том, что свой стихийный «зоопарк» сервисов уже есть почти у каждой компании (например, что-нибудь из: Gmail, Whatsapp, Dropbox). Этот «зоопарк» добавляет своего разнообразия, и порождает желание объединить всё или найти целостную замену.


          1. heathen
            16.09.2015 11:07
            +2

            Извините, но это такой же обман, как и мнение о том, что никому не нужна индивидуальная подстройка.

            Да, каждый пользователь индивидуален, но помимо продукта продаются ещё и оптимальные бизнес-процессы. Это вечная проблема: адаптировать ПО под существующий процесс или менять процесс под ПО. Часто правильнее последнее: если процесс описан бизнес-аналитиком и предназначен именно для той области деятельности, в которой работает пользователь. Да, внедрять нужно всё равно, но внедрение в маленьком бизнесе — салоне красоты, сервисном центре, автомастерской — и в крупной компании — не одно и то же. Маленький бизнес хочет быстро решить свою типовую задачу, попутно разделив затраты на бизнес-консультанта, разработку бизнес-процесса и его автоматизацию с десятками и сотнями других таких же бизнесов. И он не будет вкладывать свою годовую прибыль в это.

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

            Ну, и возможностей таких никто не представляет. Я очень долго искал продукт для автоматизации такой же деятельности, как у комментатора выше. Единственное, что нашёл: Рарус: Управление сервисный центром. Естественно, не СааС, естественно, под 1С. Увы. Причём и тут не всё гладко, само собой. А задачи ведь элементарны.


            1. agalitski
              16.09.2015 12:49

              Комментарий я писал именно про салон красоты (моей жены), а не про сервисный центр. Стоит типовое решение, всё устраивает, ничего менять не надо. альтернатив — множество. Разделили затраты с тысячами таких же бизнесов.

              С моей компанией по восстановлению данных всё как в статье — никакие типовые решения не понравились (мы сильно заморачиваемся над оптимизацией бизнес-процессов и они не типовые), saas доверия нет, интеграторы не впечатлили. Поэтому самописная 1с с постоянными изменениями, поиски идеальной CRM, интеграций и тп.


            1. alex_ant
              16.09.2015 12:59

              Объясню откуда сложилось такое моё утверждение. Пару лет мы пытались продавать наборы интегрированных облачных приложений, но их ни кто не покупал. Мы думали, если мы покроем основные потребности и бизнес процессы — к нам потянутся. Когда не потянулись, мы очень плотно пообщались с отвалившимися клиентами. Оказалось, что более весомую роль в этих делах играют две вещи: 1) дело вкуса, 2) исторически складывающиеся традиции использовать те или иные сервисы. При этом, присутствует непрерывный дрейф. Компания начинает использовать Dropbox для обмена документами, через полгода кто-то активный сманивает всех в Evernote. Через год директору кажется, что луче Google Drive ничего нет. Так продолжается непрерывно.

              Теоретически, я с вами согласен и понимаю вас. На практике, случайность играет весомую роль. Будет ли компания использовать SaaS-продукт в большей степени зависит от того, впишется ли его интерфейс в мировоззрение лидеров мнения в компании (синестезия), чем от того, сколько денег это позволит сэкономить. Вот такой вот парадокс.


              1. heathen
                16.09.2015 14:39

                Написал вам громадный комментарий и, само собой, всё удалил, когда браузер случайно на предыдущую страницу вернулся. К сожалению, ещё получаса у меня нет, чтобы восстановить написанное; а жаль, тема интересная :(


                1. alex_ant
                  16.09.2015 16:42

                  Можем поговорить по скайпу (alexey-fedorov), я хотел бы понять.


                  1. heathen
                    17.09.2015 11:03
                    +4

                    Давайте пока тут, если вы не против. Потом можно и в скайп, если нужно будет :) Я надеюсь, что кто-то ещё подключится к разговору.

                    Мне кажется, что примеры, которые вы привели — это всё-таки в некоторой степени «свистелки»: обмен файлами, мессенджер, почтовый IMAP-клиент. Как только появляется сервис, в котором необходима история, прыгать «от цветка к цветку» становиться сложнее. С ужасом вспоминаю старые времена, когда приходилось периодически в архив переносить старые базы 1С и начинать новые; руководители старались максимально отодвинуть этот процесс, потому что даже миграция справочников и остатков была очень нетривиальной операцией, а есть ведь ещё и история по «живым» проектам, счетам, оплатам… Попробовал бы руководитель менять каждые полгода систему учёта продаж или бухгалтерскую — быстро бы у него это желание исчезло.

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

                    У нас бизнесы ведутся так, что за голову иногда хватаешься. Приведу два примера.

                    Первый — старый, начала двухтысячных. Я её услышал от бизнес-консультанта, у которого был на семинаре по мерчандайзингу, в Москве. Так вот, он рассказал, что приехал как-то вечером на автомойку. Большие светящиеся буквы «Круглосуточно». При это всё закрыто на клюшку. Нашёл он где-то там дверцу, заходит, а внутри стоит мужик, видимо, хозяин с большой пачкой денег, считает. На вопрос «почему закрыто?» тот помахал деньгами и сказал «Мне на сегодня хватит». Понимаете? К нему приехал клиент, продвижение услуги, как круглосуточной, но «ему хватит», поэтому клиент может идти в… гм… погулять.
                    И второй пример, пары дней давности, самый что ни на есть центр Екатеринбурга, центрее особо некуда. Некоторое время назад у авто началось биение руля на скорости, на ТО сказали, что с подвеской всё хорошо, но износ резины неравномерный, поэтому первая рекомендация — перебалансировать колёса. А недалеко от моего дома есть сервис. Решил я туда по дороге заехать. Внутри стоят две машины, клиенты тусуются в комнате для гостей, и никого. Через минуты 3-5 я таки нашёл какого-то рабочего, который занимался одной из машин, задал вопрос о стоимости. Тот бросил работу, пошёл в другую комнату, на калькуляторе что-то там посчитал, назвал цену, сказал, что по времени 15-20 минут, что можно заехать после машины, которая сейчас выедет, и снова занялся авто, с которым работал. Машина соседняя действительно выехала через минуту, но на её место сразу же заехала другая — она стояла недалеко, когда я подъехал, т.е. очевидно, что была очередь. На меня никто не обратил никакого внимания, подошёл ещё один молодой парень-рабочий, первый второму сказал, что вот ему (показывая на меня) нужна перебалансировка, а что нужно тому, кто заехал, он не знает. Ко мне никто не обратился. Никто не извинился, не попросил ещё подождать. Не сказал, сколько времени нужно подождать. Я постоял ещё 2-3 минуты, ожидая, что мне хоть что-то объяснят, потом развернулся, сел в машину и уехал. А ведь это не гараж-шараш-контора какая-то, это одна из нескольких мастерских местной небольшой сети, расположенная недалеко от администрации области.

                    К сожалению, уровень управленческой грамотности у многих предпринимателей очень низок. Они в рамках своего опыта действуют. Они, возможно, прекрасно умеют разговаривать и продавать. Но в чём преимущество грамотно выстроенного эффективного бизнес-процесса, они не знают. Более того, они и не узнают, потому что у них: а) нет стимула что-то менять, потому что клиент и так идёт, б) нет денег, чтобы нанять хорошего бизнес-консультанта, особенно в условиях кризиса, когда клиент внезапно кончился, и в) нет уверенности, что даже если они потратят какие-то деньги, это что-то даст, а деньги не канут в лету.
                    Поэтому, по уму, нужно бы продавать таким компаниям не автоматизацию — это, кстати, не только ведь SaaS касается. Нужно продавать таким организациям бизнес-услугу, в которую будет входить и автоматизация. И если компания средняя либо небольшая, но с деньгами, то им можно продать полноценный бизнес-консалтинг, если у компании нет столько денег или, что важно, у компании типовая услуга, можно продать им заранее выстроенный бизнес-процесс с автоматизацией и услуги антикризисного менеджера для внедрения. Но первична будет не автоматизация, а именно описанный процесс, и внедрять нужно будет именно процесс. И этот процесс должен быть максимально ясно документирован. А внешней менеджер будет свободен от внутренних социальных обязательств (всё-таки небольшие компании часто имеют коллективы с большим количеством неформальных связей), и сможет обеспечить внедрение.
                    Но — как всегда, но, — руководитель должен быть готов. Он должен понимать необходимость и понимать, что ему это принесёт. Т.е. должны быть описаны индикаторы, по которым будет оцениваться эффективность изменений, как конечные, так и промежуточные, и сценарий при провале внедрения. Ну, и если оплата будет «по результату» — это станет весомым аргументом в пользу продажи. Конечно, тут тоже море подводных камней, но в одном комментарии очень сложно подробно продумать.

                    То, что я написал — это, в общем, довольно азбучные истины. Беда в том, что мало кто задумывается на эту тему. Люди слышат слово «бизнес-процесс», и у них автоматически падает планка на глаза и уши: это что-то из разряда крупных корпораций типа Микрософт или Газпром, а нам не надо, мы тут на 100 000 рублей в месяц хорошо если продаём своих услуг, это дорого, не нужно, и вообще некогда в ваши игрульки играть, нам дело нужно делать.

                    Ну, и по факту, это мало имеет отношения именно к SaaS. :) Но я считаю, что автоматизация — должна автоматизировать какие-то вещи, которые до этого уже работали, чтобы они стали ещё эффективнее. Утрированно, конечно (например, процесс может быть заточен на автоматизацию и без неё не будет работать вообще), но для обобщения на скорую руку пойдёт. Возвращаясь к SaaS, я бы очень рекомендовал разработчикам платформ потратить время на внятное описание процессов, которые автоматизируются с помощью их софта. В том числе в виде диаграмм. С ключевыми показателями по каждому процессу. В общем, разработчикам офлайновых платформ я бы рекомендовал сделать то же самое.
                    В целом я считаю, что в некоторых случаях можно обойтись без внешнего внедрения, если будет доступна документация и описание, причём, возможно, даже в свободном доступе. Тут нет единственной правды: кто-то сможет своими силами справиться, а кто-то — нет. Вторым вы нужны, первым — нет, они не будут тратить на это деньги. Единственное, для вторых вы тоже нужны, если вы делаете интеграцию между различными сервисами. Мне, к примеру, не очень понятно, на что рассчитывают разработчики складских систем учёта и систем учёта продаж без мало того, что экспорта в бухгалтерский софт, но и без поддержки, скажем, ГТД. Или, что ещё смешнее, с тем же «Моим складом» столкнулся: невозможно нормально импортировать уже имеющийся прайс-лист, в котором есть как товары, так и услуги. Там в принципе нет такой возможности. Такое ощущение, что люди ориентируются только на новые бизнесы, а старые им не интересны вообще.

                    Но лично мне кажется, что обмен файлами и мессенджеры — это вторично. Это инструмент, который должен решать конкретную задачу. А обмен файлами — даже если это супер-пупер важная документация по мегадорогим проектам — всего лишь маленький кусочек процесса продажи или производства конкретного бизнес-продукта. Неужели директора и правда волнует, с помощью Dropbox'а или Google Drive его менеджеры будут обмениваться версиями договора? Нет, его волнует, чтобы был найден потенциальный клиент, который захотел бы купить продукт, ему был бы отправлен договор, согласова


                    1. alex_ant
                      17.09.2015 20:56
                      +1

                      Спасибо за вашу статью! :)

                      Вы ушли в философию, и я позволю себе уйти туда же. Вы, как те основатели-миссионеры, решили, что вокруг все плохо работают, а если бы работали хорошо, то SaaS немедленно стал бы востребован и спас бы всех. Я думал так же, когда мы разрабатывали систему, объединяющую разрозненные онлайн-сервисы в один. Пётр Диденко тогда сказал мне при встрече: «Открой отчёт „Опора России“ и ты не увидишь там в первой десятке проблем бизнеса проблему „разрозненность сервисов“». Вся эта умозрительная автоматизация хороша в теории. Нет никакого плохого бизнеса, бизнес такой, поскольку так сформировался эволюционно, и он оптимальный для наших условий, как оптимальны бобры в своей экологической нише. И то что реальность не вписывается в чаяния разработчиков, придумавших примитивную UML-модель мира, не говорит о том, что проблема в бизнесе, это просто разработчики придумали «прокрустово ложе» и удивляются почему в него никто не лезет.

                      Я не оправдываю автомойщика, но он определённо или пострадал от этого случая или не пострадал. Оба варианта имеют право на существование и не более. Уровень грамотности наших предпринимателей именно такого уровня, какого им нужно его иметь, чтобы быть предпринимателями. И я больше скажу, чем меньше систем, тем лучше, поскольку они закрепощают предпринимателей. Не мне вам рассказывать об Agile и о том, почему customer development сегодня побеждает MBA.

                      Все эти индикаторы и измерение каждого чиха — это шум, бирюльки в которые играют технари. Если дядя Гена может продать фуру арбузов с срубить полляма даже не зная слова «конверсия» — он молодец! Он знает гораздо больше о жизни, чем тот, кто полгода в коворкинге читает талмуд «Стартап: руководство основателя»и гордится тем, что не опаздывает на встречи.

                      Я считаю, что автоматизация никому ничего не должна. :) Автоматизация это следствие, а не цель. Когда у предпринимателей есть цель чего-то достичь, они просто выбирают наиболее подходящий способ. Вы предлагаете снабжать их документацией, наверное, полагая, что наши предприниматели живут очень скучной жизнью, и обожает заниматься всякой хренью не по делу — днями напролёт оптимизировать бизнес-процессы. А я всего лишь предлагаю дать им возможность платить деньги тем, кто сделает за них нетипичные для них вещи (внедрит, настроит процессы, интегрирует), после чего они смогут наслаждаться результатом.


          1. Cancel
            17.09.2015 10:23

            Есть куча мелких бизнесов, которые именно за счёт мелкости могут сравнительно легко перестроить бизнес-процессы.


      1. risik
        17.09.2015 18:51

        Позволю себе привести одну цитату:

        В программном обеспечении SAP и других систем планирования ресурсов, появившихся вслед за ним ...(пропущено) Хотя изначально можно было создавать отдельные уникальные элементы системы планирования ресурсов для конкретной отрасли или компании, внешние консультанты при выполнении заказов обычно «подгоняли» стандартные программы к потребностям отдельных потребителей на основе использования стандартизованных средств изменения конфигурации. Таким образом, любая ценная модификация могла быть скопирована другими компаниями. К концу 1990-х годов стало ясно, что масштабная «подгонка» редко стоила затраченных усилий. Компании все чаще предпочитали готовую базовую конфигурацию, понимая, что изменение комплексных программ потребует значительных затрат времени и денег, но не приведет к значимой дифференциации

        // Николас Дж. Карр. Блеск и нищета информационных технологий.
        (выделение жирным — мое)

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


        1. alex_ant
          18.09.2015 08:14

          Тут вся соль в слове «подгонка». Здесь подгонка это разработка уникального ПО или ковыряние в настройках существующего ПО? Подозреваю, что первое, и тогда нет никаких противоречий. Я могу за путём долгого ковыряния в настройках JIRA подогнать её под абсолютно любой бизнес, и это не будет столь же трудоёмко, как разработать свой, с нуля заточенный продукт.

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


  1. Andruhon
    16.09.2015 12:52

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


    1. alex_ant
      16.09.2015 13:02

      Могут. И даже есть такие. И много. :) Но пока в массовом сознании клиентов таких сервисных компаний нет.


  1. overmind0
    16.09.2015 20:12

    Восхитительная статья, большое спасибо! И развеялся, и пользу извлёк.


  1. sunnybear
    17.09.2015 13:58

    А теперь покажите мне интеграторов SaaS в России. Больше трех человек, желательно. И сами ответьте на вопрос: почему SaaS в России продают себя сами, а не через интеграторов.

    Б24 через партнеров очень туго идет, потому что непонятно, как это продавать.


    1. alex_ant
      17.09.2015 15:52

      Как и писалось, самоопределение интегратов в «облачные интеграторы» не произошло. Вот тут как раз больше трёх интеграторов, которые готоы заниматься облаками: startpack.ru/integrators Список будет расти.

      Б24 туго идёт потому, что Б24 конкурирует со своими партнёрами, а культура делать сервис, а не по-быстрому продать лицензию и срулить, пока не развита. Но спрос уже есть, первый комментарий ясно показывает боль, решения только пока не очевидны.


    1. MaximZakharenko
      17.09.2015 16:00

      «Информатика и сервис» из Питера специализируется на постановке бизнес-процессов на платформе Битрикс24 (продажи, хелпдеск...). Кстати, они очень часто вместо Б24 используют Б.Корпортал (коробку разворачивают на IaaSе в облаке), потому что интеграция нужна и функционала в коробке больше. Для конечного клиента получается всё равно облако настроенное.


  1. VGusev2007
    21.09.2015 23:20

    Прекрасная статья! Но я так и не понял, в итоге, как интеграторы, могли бы помочь избежать «вендор лока», при использовании SaaS. По-моему — никак. Внедрить — да. Избежать лока — никак… Или я что-то не понял? В статье вроде как говорится, что чудесные вендоры, придут, и всё сразу станет как нужно… Но до конца сути не раскрыто.