Comments 10
Вот не могу понять: неужели вся Россия просто мечтает выгрузить свои данные (читай — информацию, приносящую доход!) дяде в «облако» (у кого как, обычно «дяде на сервер(а)»), попадая при этом от него в полную зависимость?
И не только в смысле денег и условий, но и сохранности данных, возможных маски-шоу у дяди в офисе/ДЦ, да просто в смысле возможного изменения линии развития дядиного сервиса.
И еще, подскажите, неужели аргумент «вы всегда будете работать с самой свежей версией продукта, т.к. мы его постоянно обновляем» вообще актуален? К ПО юзеры привыкают, если я посажу складовщика на SaaS-версию ПО складского учета, а у той интерфейс будет меняться, так я не благодарность услышу, а проблемы потенциально получу с учетом, если человек не разберется.
Согласен, что оффлайновые альтернативы не всегда лучше SaaS. Но это уже удел любого ПО в любой компании, его нужно как-то получить (купить, написать/заказать свое), внедрить, подстроить бизнес-процессы к тому, что после внедрения получили, и жить. Но «свое» — оно и есть «свое», а SaaS — он хорош для очень ограниченной категории юзеров, но не для всех же. Но написанное под себя ПО (в России это чаще всего читай как «внедрение 1с и написание конфигураций под задачи») позволяет строить дело дальше как сами хотим, а не как облачным SaaS-овцам покажется завтра более удобным развивать сервис.
Ну и плюс модели оплаты… Платить за юзера раз в месяц/год не всегда радует.
И не только в смысле денег и условий, но и сохранности данных, возможных маски-шоу у дяди в офисе/ДЦ, да просто в смысле возможного изменения линии развития дядиного сервиса.
И еще, подскажите, неужели аргумент «вы всегда будете работать с самой свежей версией продукта, т.к. мы его постоянно обновляем» вообще актуален? К ПО юзеры привыкают, если я посажу складовщика на SaaS-версию ПО складского учета, а у той интерфейс будет меняться, так я не благодарность услышу, а проблемы потенциально получу с учетом, если человек не разберется.
Согласен, что оффлайновые альтернативы не всегда лучше SaaS. Но это уже удел любого ПО в любой компании, его нужно как-то получить (купить, написать/заказать свое), внедрить, подстроить бизнес-процессы к тому, что после внедрения получили, и жить. Но «свое» — оно и есть «свое», а SaaS — он хорош для очень ограниченной категории юзеров, но не для всех же. Но написанное под себя ПО (в России это чаще всего читай как «внедрение 1с и написание конфигураций под задачи») позволяет строить дело дальше как сами хотим, а не как облачным SaaS-овцам покажется завтра более удобным развивать сервис.
Ну и плюс модели оплаты… Платить за юзера раз в месяц/год не всегда радует.
Это как переход от оффлайн почтового клиента на web почту. Нужно время, осознание и доверие. Это очень (больше :) подходит для нормально организованного общества с нормальным уровнем образования и соответствующим уровнем прогресса.
Главный плюс подобных решений, все-таки, возможность доступа к системе из любой точки через web интерфейс. Ну и, конечно, быстрый апгрейд и исправление ошибок.
Главный плюс подобных решений, все-таки, возможность доступа к системе из любой точки через web интерфейс. Ну и, конечно, быстрый апгрейд и исправление ошибок.
> быстрый апгрейд
Вот-вот, именно об этом недостатке я выше и писал, Вы же видели? :)
> Нужно время, осознание и доверие
Не вижу к тому оснований. Маленький стартап у большой корпорации чем доверие заслужит? Не говоря уже о всяких ужастиках, вроде гос-структур и их (часто — внезапных) действий, вроде опасностей, характерных для самого интернета (DDOS на сервера облака, MitM и прочее, что может омрачить и сделать невозможной работу)? Не праздным является вопрос бекапа и безопасности хранения — я не могу взять бекап из облака, чтобы записать на кассету(ы) и положить в сейф в соляной шахте, а даже если и могу, то обратно уже не залью.
Данные стоят обычно сильно выше абонентской платы за любой SaaS. Готовы ли сервисы компенсировать их стоимость + упущенную выгоду в случае каких-то неприятностей?
В общем, есть серьезные вопросы. Ответов обычно, кроме «у нас все сделано по уму», особо не дается…
Вот-вот, именно об этом недостатке я выше и писал, Вы же видели? :)
> Нужно время, осознание и доверие
Не вижу к тому оснований. Маленький стартап у большой корпорации чем доверие заслужит? Не говоря уже о всяких ужастиках, вроде гос-структур и их (часто — внезапных) действий, вроде опасностей, характерных для самого интернета (DDOS на сервера облака, MitM и прочее, что может омрачить и сделать невозможной работу)? Не праздным является вопрос бекапа и безопасности хранения — я не могу взять бекап из облака, чтобы записать на кассету(ы) и положить в сейф в соляной шахте, а даже если и могу, то обратно уже не залью.
Данные стоят обычно сильно выше абонентской платы за любой SaaS. Готовы ли сервисы компенсировать их стоимость + упущенную выгоду в случае каких-то неприятностей?
В общем, есть серьезные вопросы. Ответов обычно, кроме «у нас все сделано по уму», особо не дается…
> Нужно время, осознание и доверие
Не вижу к тому оснований. Маленький стартап у большой корпорации чем доверие заслужит? Не говоря уже о всяких ужастиках, вроде гос-структур и их (часто — внезапных) действий, вроде опасностей, характерных для самого интернета (DDOS на сервера облака, MitM и прочее, что может омрачить и сделать невозможной работу)? Не праздным является вопрос бекапа и безопасности хранения — я не могу взять бекап из облака, чтобы записать на кассету(ы) и положить в сейф в соляной шахте, а даже если и могу, то обратно уже не залью.
>>
1. Мы например работаем с партнерской сетью, точней, умеем с ней работать. Depo, Ай-Теко, IBS. С Ай-Теко сделали совместный продукт, например для банков У всех интеграторов хорошие отношения с большими компаниями и госами — так и живем.
2. С технологическими проблемами интернета справляемся а ) или своими силами б) или размещением инталляции у тех же партнеров + я вообще с технологической точки зрения проблем не вижу. Мы по своему SLA гарантируем апдейты и работоспособность 99,9 процентов. Ни в одном бесплатном сервисе такого нет и мы считаем это нашим бессомненым преимуществом. Если не устраивает наше SLA или есть недоверие к новому продукту — вэлкам к партнерам и работайте по их SLA. Т.е сохранность данных прописывается договором и можно отпустить проблему.
3. Согласен, что данные наше все, не согласен, что мы не умеем их хранить и не согласен, что живем только отговорками.
Если у вас есть задача (не почта, т.к. я представляю именно ее), а по миграции в облако, давайте обсудим и я подключу лучших экспертов облачного рынка к решению задачи.
Данные стоят обычно сильно выше абонентской платы за любой SaaS. Готовы ли сервисы компенсировать их стоимость + упущенную выгоду в случае каких-то неприятностей?
В общем, есть серьезные вопросы. Ответов обычно, кроме «у нас все сделано по уму», особо не дается…
Не вижу к тому оснований. Маленький стартап у большой корпорации чем доверие заслужит? Не говоря уже о всяких ужастиках, вроде гос-структур и их (часто — внезапных) действий, вроде опасностей, характерных для самого интернета (DDOS на сервера облака, MitM и прочее, что может омрачить и сделать невозможной работу)? Не праздным является вопрос бекапа и безопасности хранения — я не могу взять бекап из облака, чтобы записать на кассету(ы) и положить в сейф в соляной шахте, а даже если и могу, то обратно уже не залью.
>>
1. Мы например работаем с партнерской сетью, точней, умеем с ней работать. Depo, Ай-Теко, IBS. С Ай-Теко сделали совместный продукт, например для банков У всех интеграторов хорошие отношения с большими компаниями и госами — так и живем.
2. С технологическими проблемами интернета справляемся а ) или своими силами б) или размещением инталляции у тех же партнеров + я вообще с технологической точки зрения проблем не вижу. Мы по своему SLA гарантируем апдейты и работоспособность 99,9 процентов. Ни в одном бесплатном сервисе такого нет и мы считаем это нашим бессомненым преимуществом. Если не устраивает наше SLA или есть недоверие к новому продукту — вэлкам к партнерам и работайте по их SLA. Т.е сохранность данных прописывается договором и можно отпустить проблему.
3. Согласен, что данные наше все, не согласен, что мы не умеем их хранить и не согласен, что живем только отговорками.
Если у вас есть задача (не почта, т.к. я представляю именно ее), а по миграции в облако, давайте обсудим и я подключу лучших экспертов облачного рынка к решению задачи.
Данные стоят обычно сильно выше абонентской платы за любой SaaS. Готовы ли сервисы компенсировать их стоимость + упущенную выгоду в случае каких-то неприятностей?
В общем, есть серьезные вопросы. Ответов обычно, кроме «у нас все сделано по уму», особо не дается…
В до Android-ых предложениях мобильного рынка основной проблемой при смене телефона было привыкнуть к интерфейсу. Кто часто менял телефоны, тот знает, что надо 2 недели, чтобы привыкнуть. Примерно то же происходит с софтом. Ощущение же, что теперь почтовый сервис стоит не у тебя под столом, а в ЦОДе — это тоже проходит — мы же ни когда не задумываемся о том, что у GOOGLE 2 000 000 серверов и они даже не ремонтируются, а заменяются «поколениями».
Если серьезно, то SaaS всегда проще в исполнении и не перегрузки в функциональности там нет или интерфейсы гораздо понятней, чем в классических системах. Ну и воля руководства играет не последнюю роль конечно — переезжать в облако или «тащить все свое с собой».
Если серьезно, то SaaS всегда проще в исполнении и не перегрузки в функциональности там нет или интерфейсы гораздо понятней, чем в классических системах. Ну и воля руководства играет не последнюю роль конечно — переезжать в облако или «тащить все свое с собой».
Cпасибо за интересные вопросы и буду отвечать за «всю компанию»
1. На счет всей России говорить пока рано, но количество пользователей у SaaS сервисов доказывает, что люди морально готовы отдавать данные. Некоторые хотят отдавать, но не в российские ЦОД. Я лично знаю уже кейсы использования банками облаков и решений Sales Forse, через специальные шлюзы IBM. Приложение — оценка рисков выдачи кредитов, т.е. содержащие персональные данные. Для тех кто боится есть несколько вариантов, поставки но так же браузерных. Последнее не SaaS в чистом виде, но тем не менее.
2. Обычно разработчики арендуют ЦОД или делают на Azure — у них нет своих ЦОДов и там где они арендуют все вполне прилично — ЦОДам можно доверять.Что касается стратегии развития, то прелесть SaaS в том, что можно отказаться от использования сервиса за 5 минут — выгрузить данные и уйти к другому разработчику — бизнес при миграции ни чего не теряет и миграция безболезненна.
Плюс, мы, например, уже умеем в разных «изоляциях» (клиенты в SaaS решении). Производить разные доработки и, если клиент не захочет обновляться, то мы и не будем его обновлять.
3. Обычно изменения происходят так. Собирается мнение пользователей и долго-долго принимается решение, что же сделать из списка просьб пользователей на 10 листах. Делается что-то одно из 10. Т.е. я к чему — не бывает ситуаций, когда вы открываете приложение и там совершенно другой интрефейс. Если доработки происходят, то они незначительны в каждой иттерации, не меняют функционал и сопровождаются подробным мануалом про изменения или обычно — дополнения возможностей.
4. Тема «особенностей бизнеса» всегда болезненна. Если говорить про простые сервисы, то то пользователю придется использовать софт «как есть». Если мы говорим про 1С, то партнер сделает те же самые доработки на своей стороне. 1С уже года 2 как построило свой ЦОД и постепенно вошло в тему облаков. Т.е. если для бизнеса критичны изменения, то они примерно так же и будут происходить в облаке.
5. Ну как же при SaaS идет смена замена CAPEX на OPEX — разве это не важно для бизнеса? Если сравнивать софт+железо, то бизнес получает «рассрочку» лет на 5.
1. На счет всей России говорить пока рано, но количество пользователей у SaaS сервисов доказывает, что люди морально готовы отдавать данные. Некоторые хотят отдавать, но не в российские ЦОД. Я лично знаю уже кейсы использования банками облаков и решений Sales Forse, через специальные шлюзы IBM. Приложение — оценка рисков выдачи кредитов, т.е. содержащие персональные данные. Для тех кто боится есть несколько вариантов, поставки но так же браузерных. Последнее не SaaS в чистом виде, но тем не менее.
2. Обычно разработчики арендуют ЦОД или делают на Azure — у них нет своих ЦОДов и там где они арендуют все вполне прилично — ЦОДам можно доверять.Что касается стратегии развития, то прелесть SaaS в том, что можно отказаться от использования сервиса за 5 минут — выгрузить данные и уйти к другому разработчику — бизнес при миграции ни чего не теряет и миграция безболезненна.
Плюс, мы, например, уже умеем в разных «изоляциях» (клиенты в SaaS решении). Производить разные доработки и, если клиент не захочет обновляться, то мы и не будем его обновлять.
3. Обычно изменения происходят так. Собирается мнение пользователей и долго-долго принимается решение, что же сделать из списка просьб пользователей на 10 листах. Делается что-то одно из 10. Т.е. я к чему — не бывает ситуаций, когда вы открываете приложение и там совершенно другой интрефейс. Если доработки происходят, то они незначительны в каждой иттерации, не меняют функционал и сопровождаются подробным мануалом про изменения или обычно — дополнения возможностей.
4. Тема «особенностей бизнеса» всегда болезненна. Если говорить про простые сервисы, то то пользователю придется использовать софт «как есть». Если мы говорим про 1С, то партнер сделает те же самые доработки на своей стороне. 1С уже года 2 как построило свой ЦОД и постепенно вошло в тему облаков. Т.е. если для бизнеса критичны изменения, то они примерно так же и будут происходить в облаке.
5. Ну как же при SaaS идет смена замена CAPEX на OPEX — разве это не важно для бизнеса? Если сравнивать софт+железо, то бизнес получает «рассрочку» лет на 5.
Для SMB это никогда не было проблемой.
я сделаю отдельную статью, про то как правильно выбрать облачного провайдера на примере нашего партнера и приложения Quickme.
Неудобно смотреть ответы, когда постоянно приходится подниматься наверх к формулировкам вопросов.
Sign up to leave a comment.
Как создавать и зарабатывать на SaaS (Часть 2 / бесценный опыт российских ISV)