пятница, Ноябрь 10, 2006
Модель продаж SaaS
Модель продаж SaaS кардинально отличается от подходов вендоров традиционных корпоративных приложений.
Если Вы когда-либо имели дело с продажами ПО корпоративным клиентам, то вероятно знаете, насколько неблагодарное это дело. Отсутствие четких критериев возврата инвестиций, непрозрачная модель принятия решений, высокие риски провала внедрения -- все это вынуждает вендоров и их партнеров тратить огромные суммы на содержание армии дорогостоящих маркетолов, эккаунт-менеджеров и технических специалистов, большую часть своего времени проводящих в роли пресейл-консультантов. В итоге, сами же клиенты оплачивают их тяжкий труд, причем платят они в конечном счете и за работу вендора или интегратора с другими клиентами, не приведшую к контракту с ними.
Типичная модель продаж SaaS -- прямая. Единственный ее канал -- интернет, и никакие посредники, даже сотрудники самого разработчика, в процессе продаж не задействованы, за редким исключением. В отличие от коробочных приложений, Web-приложения можно попробовать не имея для этого ни сервера, ни каких-либо специфических знаний по установке, настройке и администрированию приложения, а также его базы данных, операционной системы и прочих внешних зависимостей. Достаточно иметь Web-браузер, а времени на непосредственную оценку приложения потребуется гораздо меньше, чем на бесконечные переговоры с вендором о том, как все будет прекрасно. В результате процесс продаж SaaS превращается в самообслуживание, а расходы на продажи у SaaS-разработчиков не переменные (не пропорциональны числу новых клиентов), как у традиционных вендоров ПО, а постоянные, как и стоимость разработки.
Скорость принятия решения увеличивается еще и потому, что речь не идет об очередных не всем понятных инвестициях в IT. SaaS требует commitment не больше, чем на год, а чаще всего на месяц. Такая модель оплаты позволяет принципиально новым категориям бюджетодержателей принимать IT-решения. Так, нередко менеджеры небольших групп переводят свои отделы на SaaS пока CIO планирует инсталляцию аналогичного решения на следующий год. Согласование c CIO обходят, так как ресурсы информационной службы не задействуются, а деньги на небольшие ежемесячные отчисления можно найти в "прочих расходах", обходясь также без визы CFO. Таким образом механизм убеждения клиента упрощается донельзя: нравится -- берите, желательно у нас не спрашивая.
Демонстрации, выезды к клиенту, индивидуальные технические и коммерческие предложения уходят в прошлое, а с ними и высокая стоимость индивидуальной поддержки, на которой, собственно, и базируется прибыль вендоров бизнес-приложений. Те, кто работает по-старому, просто увеличивают расходы клиента, который за все это личное внимание (как правило, к своему CIO) в конечном счете заплатит, поделившись этой платой и с самим CIO (порой и не подозревая об этом). Полагаю, что с течением времени желающих будет становится все меньше. Более эффективные модели IT постепенно вытеснят исторически сложившиеся.
Siebel тратит столько денег на продажи, потому что он вынужден убеждать умных людей сделать глупость.Так на проходившем в San Jose в рамках On Demand Summit круглом столе один из участников охарактеризовал неэффективность продаж "коробочных решений" по сравнению с их Web-альтернативами.
Если Вы когда-либо имели дело с продажами ПО корпоративным клиентам, то вероятно знаете, насколько неблагодарное это дело. Отсутствие четких критериев возврата инвестиций, непрозрачная модель принятия решений, высокие риски провала внедрения -- все это вынуждает вендоров и их партнеров тратить огромные суммы на содержание армии дорогостоящих маркетолов, эккаунт-менеджеров и технических специалистов, большую часть своего времени проводящих в роли пресейл-консультантов. В итоге, сами же клиенты оплачивают их тяжкий труд, причем платят они в конечном счете и за работу вендора или интегратора с другими клиентами, не приведшую к контракту с ними.
Типичная модель продаж SaaS -- прямая. Единственный ее канал -- интернет, и никакие посредники, даже сотрудники самого разработчика, в процессе продаж не задействованы, за редким исключением. В отличие от коробочных приложений, Web-приложения можно попробовать не имея для этого ни сервера, ни каких-либо специфических знаний по установке, настройке и администрированию приложения, а также его базы данных, операционной системы и прочих внешних зависимостей. Достаточно иметь Web-браузер, а времени на непосредственную оценку приложения потребуется гораздо меньше, чем на бесконечные переговоры с вендором о том, как все будет прекрасно. В результате процесс продаж SaaS превращается в самообслуживание, а расходы на продажи у SaaS-разработчиков не переменные (не пропорциональны числу новых клиентов), как у традиционных вендоров ПО, а постоянные, как и стоимость разработки.
Скорость принятия решения увеличивается еще и потому, что речь не идет об очередных не всем понятных инвестициях в IT. SaaS требует commitment не больше, чем на год, а чаще всего на месяц. Такая модель оплаты позволяет принципиально новым категориям бюджетодержателей принимать IT-решения. Так, нередко менеджеры небольших групп переводят свои отделы на SaaS пока CIO планирует инсталляцию аналогичного решения на следующий год. Согласование c CIO обходят, так как ресурсы информационной службы не задействуются, а деньги на небольшие ежемесячные отчисления можно найти в "прочих расходах", обходясь также без визы CFO. Таким образом механизм убеждения клиента упрощается донельзя: нравится -- берите, желательно у нас не спрашивая.
Демонстрации, выезды к клиенту, индивидуальные технические и коммерческие предложения уходят в прошлое, а с ними и высокая стоимость индивидуальной поддержки, на которой, собственно, и базируется прибыль вендоров бизнес-приложений. Те, кто работает по-старому, просто увеличивают расходы клиента, который за все это личное внимание (как правило, к своему CIO) в конечном счете заплатит, поделившись этой платой и с самим CIO (порой и не подозревая об этом). Полагаю, что с течением времени желающих будет становится все меньше. Более эффективные модели IT постепенно вытеснят исторически сложившиеся.
technorati tags: saas
Комментарии:
Ссылки на это сообщение:
<< Главная страница
Ох, с какой это стати вендоры откажутся от модели охмурения на рынке покупателя? И когда это SaaS продавался через веб и только через веб?
ИМХО, но вся разница в лучшей чем раньше прозрачности отдачи инвестиций.
Чудес не бывает...
ИМХО, но вся разница в лучшей чем раньше прозрачности отдачи инвестиций.
Чудес не бывает...
Вендоры не откажутся, конечно. Это клиенты должны отказаться.
Сравни по отчетам cost of sales у Salesforce.com (NYSE: CRM) и RightNow (NASDAQ: RNOW) на одного нового клиента и в % от выручки c аналогичными показателями ORCL, SAP, IBM (MSFT не считается).
SaaS можно продавать/покупать не большими рискованными проектами, требующими всесторонний buy-in и кучи бабла up front, а понемногу, что делает его доступным бесправным бизнес-пользователям (минуя IT) и недосягаемым для вендоров SMB. Это не чудеса, а выход на новые рынки, и нет ничего удивительного в том, что это делают новые компании новыми методами (пускай и не только ими, конечно). Старым компаниям в старой модели было комфортнее, а эти рынки по-старому недоступны.
Сравни по отчетам cost of sales у Salesforce.com (NYSE: CRM) и RightNow (NASDAQ: RNOW) на одного нового клиента и в % от выручки c аналогичными показателями ORCL, SAP, IBM (MSFT не считается).
SaaS можно продавать/покупать не большими рискованными проектами, требующими всесторонний buy-in и кучи бабла up front, а понемногу, что делает его доступным бесправным бизнес-пользователям (минуя IT) и недосягаемым для вендоров SMB. Это не чудеса, а выход на новые рынки, и нет ничего удивительного в том, что это делают новые компании новыми методами (пускай и не только ими, конечно). Старым компаниям в старой модели было комфортнее, а эти рынки по-старому недоступны.
Все таки я не стал бы делать выводы на основании существующих данных. Слишком мало игроков, слишком небольшие цифры итд итп. Т.е. на малых цифрах слишком легко получаются артефакты.
И кстати, надо смотреть как считают. Расходы можно попрятать так, что фиг найдешь - на маркетинг, на поддержку итп. Это вообще метод новой экономики - переносить расходы (OSS) и кричать об экономии...
И кстати, надо смотреть как считают. Расходы можно попрятать так, что фиг найдешь - на маркетинг, на поддержку итп. Это вообще метод новой экономики - переносить расходы (OSS) и кричать об экономии...
Я пока делаю не выводы, а прогнозы.
Что же касается зрелости рынка, то он, незаметно для "традиционных айтишников", набрал неплохие обороты. Так, выручка вышеупомянутого Salesforce.com в последнем отчетном квартале составила $118 млн, и RightNow показал вполне достойные $30 млн. Это очень хорошие показатели для фирм, которые не должны были пробиться в условиях жесточайшей конкуренции на рынке CRM.
Для сравнения, в своем последнем отчете (в конце 2005) Siebel показал квартальную выручку $348 млн, из которых только $112 млн приходилось на лицензии. А Oracle, в последнем квартале, в который не попала отчетность PeopleSoft, напродавал всех своих приложений всего на $215 млн.
Что же касается зрелости рынка, то он, незаметно для "традиционных айтишников", набрал неплохие обороты. Так, выручка вышеупомянутого Salesforce.com в последнем отчетном квартале составила $118 млн, и RightNow показал вполне достойные $30 млн. Это очень хорошие показатели для фирм, которые не должны были пробиться в условиях жесточайшей конкуренции на рынке CRM.
Для сравнения, в своем последнем отчете (в конце 2005) Siebel показал квартальную выручку $348 млн, из которых только $112 млн приходилось на лицензии. А Oracle, в последнем квартале, в который не попала отчетность PeopleSoft, напродавал всех своих приложений всего на $215 млн.
Механизм "нравится -- берите, желательно у нас не спрашивая" это мечта любого разработчика!
Но мне, как "традиционному айтишнику", а также как обычному пользователю различных сервисов (в том числе и элементарных блогов) видится в подобной модели много ограничений.
1. SaaS, в подавляющем большинстве, это тонкий клиент. А в браузере работать неудобно. Особенно с текстом. Это подтверждается большим количеством толстых приложений по управлению контентом блогов (как Windows Live Writer, BlogJet)..
2. Приложения, используемые для автоматизации предприятий, должны быть интегрированы друг с другом (частично в эту тему Intel выпускает SuiteTwo). При использовании различных сервисов интеграцию их обеспечить нельзя.
3. Далеко не все фирмы готовы размещать свои приватные данные практически неизвестно где и у кого (ведь вначале постулировалось "желательно у нас не спрашивая"). Причем не только данные клиентов, но и всей внутренней кухни - базы знаний, управление проектами (как текущими так и будущими), логистика, финансы (какая фирма без финансов, а финансы еще хорошо бы подружить с CRM и управлением проектами) и т.д.
4. Возвращаясь к данным клиентов... Мне тут видятся 2 основные проблемы:
4.1. Возможная утечка грозит фирме не только, собственно, потерей данных, но и исками от своих клиентов, т.к. именно фирма, использующая сервис гарантирует клиентам приватность данных, а не IT компания этот сервис предоставляющая.
4.2. С CRM должны дружить большинство остальных модулей, а CRM должна уметь делиться ID-ками, автоматически добавлять данные (парсить email-ы и xml).
Итог: если бы для автоматизации компаний можно было бы применять 100% унифицированные процессы не нужно было бы толп консультантов внедрения ERP систем.
Но мне, как "традиционному айтишнику", а также как обычному пользователю различных сервисов (в том числе и элементарных блогов) видится в подобной модели много ограничений.
1. SaaS, в подавляющем большинстве, это тонкий клиент. А в браузере работать неудобно. Особенно с текстом. Это подтверждается большим количеством толстых приложений по управлению контентом блогов (как Windows Live Writer, BlogJet)..
2. Приложения, используемые для автоматизации предприятий, должны быть интегрированы друг с другом (частично в эту тему Intel выпускает SuiteTwo). При использовании различных сервисов интеграцию их обеспечить нельзя.
3. Далеко не все фирмы готовы размещать свои приватные данные практически неизвестно где и у кого (ведь вначале постулировалось "желательно у нас не спрашивая"). Причем не только данные клиентов, но и всей внутренней кухни - базы знаний, управление проектами (как текущими так и будущими), логистика, финансы (какая фирма без финансов, а финансы еще хорошо бы подружить с CRM и управлением проектами) и т.д.
4. Возвращаясь к данным клиентов... Мне тут видятся 2 основные проблемы:
4.1. Возможная утечка грозит фирме не только, собственно, потерей данных, но и исками от своих клиентов, т.к. именно фирма, использующая сервис гарантирует клиентам приватность данных, а не IT компания этот сервис предоставляющая.
4.2. С CRM должны дружить большинство остальных модулей, а CRM должна уметь делиться ID-ками, автоматически добавлять данные (парсить email-ы и xml).
Итог: если бы для автоматизации компаний можно было бы применять 100% унифицированные процессы не нужно было бы толп консультантов внедрения ERP систем.
Елена, спасибо за хорошие вопросы. С некоторыми я сталкиваюсь в той или иной форме довольно часто, поэтому постараюсь ответить здесь кратко.
Механизм "нравится -- берите, желательно у нас не спрашивая" не означает, что мы не заботимся о клиентах, не стремимся убедить их в нашей состоятельности, не предоставляем гарантий обслуживания и т.п. Просто мы максимально автоматизируем процесс информирования аудитории и конвертации ее в клиентскую базу.
"Неизвестно кому" отдавать деньги за что угодно крайне недальновидно, тем более, если взамен ожидается нечто значащее для бизнеса. Естественно, формирование доверия у клиентов является важной задачей любой коммерческой организации, в том числе занимающейся предоставлением SaaS. Тем не менее, замечу, что вопрос передачи денег на управление банку -- внешней организации -- не встречает бурного сопротивления. Другой пример: электричество, которое вполне можно было бы вырабатывать собственными силами. Однако этого последние 100 лет почти никто не делает.
Что касается ущербности пользовательского интерфейса: 1) браузер служит клиентом любого Web-приложения, коими являются ныне очень многие корпоративные системы, поставляемые как нельзя более традиционно; 2) ключевой особенностью SaaS являются не технологии, а модель поставки, и в применении толстых клиентов никто разработчику не откажет. Наличие таких вещей, как Windows Live Writer и BlogJet только подтверждает востребованность богатого (родного) UI и, следовательно, его жизнеспособность. Кстати, Outlook-подобный десктопный интерфейс для Salesforce.com (InvisibleCRM) делается в России.
Лучший отзыв на анонс SuiteTwo, который я видел -- здесь. Сам SuiteTwo пока комментировать невозможно.
Тема digital identity, как и взаимодействия приложений, нисколько не привязана к SaaS. Эти вопросы настолько же актуальны при построении любой IT-инфраструктуры, где бы ни находились различные ее элементы. Я периодически пишу здесь на эти темы, так что tune in.
Сейчас замечу только, что для SaaS возможно некоторое архитектурное упрощение решения. Оно основано на применении единого экземпляра платформы для множества приложений, в том числе приложений ISV-партнеров и собственных приложений клиентов. Они объединяются общей пользовательской базой, единой информационной моделью, механизмом разграничения доступа и look and feel. В дополнение и Salesforce.com, и NetSuite имеют API для авторизации ваших пользователей через внутренние корпоративные каталоги, а также API для интеграции этих систем с существующими. Но это только начало.
С итогом согласен, хотя он больше похож на отдельный справедливый аргумент. Пока разработчики SaaS выбирают горизонтальные прикладные области, в которых потребность в настройке минимальна. В то же время развиваются технологии кастомизации SaaS. Для устойчивого роста в какой-то момент и сервисных партнеров придется вовлекать гораздо более активно. Но на данный момент есть масса вполне поддающихся унификации (для достаточно широкого контингента клиентов) приложений.
Механизм "нравится -- берите, желательно у нас не спрашивая" не означает, что мы не заботимся о клиентах, не стремимся убедить их в нашей состоятельности, не предоставляем гарантий обслуживания и т.п. Просто мы максимально автоматизируем процесс информирования аудитории и конвертации ее в клиентскую базу.
"Неизвестно кому" отдавать деньги за что угодно крайне недальновидно, тем более, если взамен ожидается нечто значащее для бизнеса. Естественно, формирование доверия у клиентов является важной задачей любой коммерческой организации, в том числе занимающейся предоставлением SaaS. Тем не менее, замечу, что вопрос передачи денег на управление банку -- внешней организации -- не встречает бурного сопротивления. Другой пример: электричество, которое вполне можно было бы вырабатывать собственными силами. Однако этого последние 100 лет почти никто не делает.
Что касается ущербности пользовательского интерфейса: 1) браузер служит клиентом любого Web-приложения, коими являются ныне очень многие корпоративные системы, поставляемые как нельзя более традиционно; 2) ключевой особенностью SaaS являются не технологии, а модель поставки, и в применении толстых клиентов никто разработчику не откажет. Наличие таких вещей, как Windows Live Writer и BlogJet только подтверждает востребованность богатого (родного) UI и, следовательно, его жизнеспособность. Кстати, Outlook-подобный десктопный интерфейс для Salesforce.com (InvisibleCRM) делается в России.
Лучший отзыв на анонс SuiteTwo, который я видел -- здесь. Сам SuiteTwo пока комментировать невозможно.
Тема digital identity, как и взаимодействия приложений, нисколько не привязана к SaaS. Эти вопросы настолько же актуальны при построении любой IT-инфраструктуры, где бы ни находились различные ее элементы. Я периодически пишу здесь на эти темы, так что tune in.
Сейчас замечу только, что для SaaS возможно некоторое архитектурное упрощение решения. Оно основано на применении единого экземпляра платформы для множества приложений, в том числе приложений ISV-партнеров и собственных приложений клиентов. Они объединяются общей пользовательской базой, единой информационной моделью, механизмом разграничения доступа и look and feel. В дополнение и Salesforce.com, и NetSuite имеют API для авторизации ваших пользователей через внутренние корпоративные каталоги, а также API для интеграции этих систем с существующими. Но это только начало.
С итогом согласен, хотя он больше похож на отдельный справедливый аргумент. Пока разработчики SaaS выбирают горизонтальные прикладные области, в которых потребность в настройке минимальна. В то же время развиваются технологии кастомизации SaaS. Для устойчивого роста в какой-то момент и сервисных партнеров придется вовлекать гораздо более активно. Но на данный момент есть масса вполне поддающихся унификации (для достаточно широкого контингента клиентов) приложений.
Вообще-то обычно при проведении пресэйлинговой работы с клиентом говорят не столько даже о возможностях системы, сколько о тех преимуществах, которые получит клиент от ее внедрения и сопутствующих процессов реорганизации предприятия. Подход "а дайте мне кнопочки, я их понажимаю" - это нечто из другой оперы. Программные решения, поддерживающие бизнес-процессы достаточной степени сложности, нельзя оценивать по внешнему виду, и не только потому, что всех возможностей неподготовленный пользователь просто не увидит, но и потому, что сам программный продукт мало что решает - гораздо больше значения имеет то, кто и как внедряет решение, насколько руководство и сотрудники компании готовы к необходимым изменениям и т.д. Возможность понажимать на кнопочки, кстати, пользователю довольно часто дают и при традиционном подходе к продажам, вот только смысл это имеет, по большей мере, для небольших и довольно простых решений (скажем, CRM-решения обычно на порядок проще ERP). Более того, показывать всю функциональность ERP целиком просто противопоказано: клиент испугается всего этого изобилия, и в голове у него останется одна каша и ощущение того, что это слишком сложно.
Между прочим, практика показала, что веб-интерфейс крайне неудобен при работе с большим количеством товара - пользователи высказывают сильное недовольство. Но это так, замечание.
Между прочим, практика показала, что веб-интерфейс крайне неудобен при работе с большим количеством товара - пользователи высказывают сильное недовольство. Но это так, замечание.
И какой же это бардак будет в ИТ фирмы, когда каждый руководитель подразделения начнет юзать те решения, что ему более приглянулись. Я не говорю уж о поддержке каких-то внутренних политик и регламентов. Про секьюрити вообще можно позабыть... А многих клиентов одна мысль о том, что их ресурс будет доступен снаружи, вводит в стопор.
Возможно, для Lige Writer или же BloggerJet это и подойдет, но как снедрять на фирме стандартный (читай, унифицированный) процес исполнения документа. Получается, что надо перестраивать сами процессы на фирме, тогда каким бюджетом это покроется.
А постоянный риск остаться без внутренней инфы (банально канал отвалился) заставит искать какие-то способы дублирования информации...
Возможно, для Lige Writer или же BloggerJet это и подойдет, но как снедрять на фирме стандартный (читай, унифицированный) процес исполнения документа. Получается, что надо перестраивать сами процессы на фирме, тогда каким бюджетом это покроется.
А постоянный риск остаться без внутренней инфы (банально канал отвалился) заставит искать какие-то способы дублирования информации...
Кстати, ну ни как не могу уловить большой разницы между классическим ASP и модным SaaS. Различия только в способе реализации (в смысле, продвижения на рынок)? Так это чистый маркетинг. С технологической точки (ну кроме HTML-интерфейса, а это лишь способ реализации) ни чего нового по сути.
Кстати, тут еще есть одна проблема. Стремительное повышение трафика (за последние годы экспоненциальное), стремительный рост числа вирусов (за последние два года в десятки раз), огромный спам, все это в ближайшее время будет создавать большие проблемы для сетевых ресурсов. Если на SaaS переносятся бизнес-приложения, роботоспособность которых прямым образом влияет на эффективность бизнеса, то хватит двух-трех сбоев или просто проседаний канала, что бы клиент задумался о возможности дальнейшего использования сервиса.
По поводу внедрения. Просто так включить и начать работать можно с Word или Writer, бизнес-приложение требует планирования, миграции, интеграции и т.д., и т.п.
Кстати, тут еще есть одна проблема. Стремительное повышение трафика (за последние годы экспоненциальное), стремительный рост числа вирусов (за последние два года в десятки раз), огромный спам, все это в ближайшее время будет создавать большие проблемы для сетевых ресурсов. Если на SaaS переносятся бизнес-приложения, роботоспособность которых прямым образом влияет на эффективность бизнеса, то хватит двух-трех сбоев или просто проседаний канала, что бы клиент задумался о возможности дальнейшего использования сервиса.
По поводу внедрения. Просто так включить и начать работать можно с Word или Writer, бизнес-приложение требует планирования, миграции, интеграции и т.д., и т.п.
serge, бардак будет, если ИТ сам не возьмется за это дело и не придумает политики, которые распространяются на SaaS.
По поводу различий SaaS и ASP см. здесь: http://iemag.ru/articles/detail.php?ID=5909&phrase_id=1462. Отличия как в технологиях, так и в бизнес-модели.
Отправить комментарий
По поводу различий SaaS и ASP см. здесь: http://iemag.ru/articles/detail.php?ID=5909&phrase_id=1462. Отличия как в технологиях, так и в бизнес-модели.
Ссылки на это сообщение:
<< Главная страница
LinkedIn
vCard
Лента
