image

TL; DR 1: миф может быть правдив в одних условиях и ложным в других


TL; DR 2: увидел холивар – присмотрись и увидишь людей, которые не хотят слышать друг друга



Читая очередную статью, написанную предвзятыми людьми на указанную тему, решил выдать свою точку зрения. Может кому полезно будет. Да и мне удобнее давать ссылку на статью вместо того, чтобы много рассказывать.


Мне эта тема близка – мы создаём контакт-центры, предлагая их по обеим моделям, как будет лучше для клиента.


Под SaaS в этой статье имеется в виду модель распространения ПО, когда сервер находится в общем облаке, а пользователи подключаются удалённо, чаще всего через интернет, через web-интерфейс.


Под on-premise в этой статье имеется в виду модель распространения ПО, когда оно устанавливается на сервер клиента, а пользователи подключаются локально, чаще всего используя интерфейс windows-приложения



Часть первая. Мифы



Миф 1.1. SaaS дороже on-premise


Миф 1.2. On-premise дороже SaaS


Продавцы SaaS часто говорят, что старт использования их ПО обходится значительно ниже. Всего-то Х долларов в месяц за пользователя. Намного дешевле, чем ХХХ у on-premise.
Продавцы on-premise умножают цену SaaS на много месяцев и говорят, что их ПО дешевле. Даже графики рисуют. Неправильные.


image

Неправильный график не учитывает, что цена лицензий – ещё не всё. Есть ещё цена работ по настройке. И затрат на обучение. И цена ошибок недообученных сотрудников. Есть цена админа, который обсуживает сервер. Есть цена апгрейда сервера и ремонта сгоревшего БП или HDD. Короче, не получается прямых линий ни там, ни там.


image

В реальности, дешевле или дороже зависит, например, от длительности периода, когда не ожидается больших изменений. Например, когда наш клиент точно знает, сколько человек ему надо и чем они будут заниматься – ему выгоднее on-premise. Если для него контакт-центр – своего рода эксперимент, ему лучше выбрать SaaS. Тем более, сменить одно на другое, если что у нас можно без потери данных.


Так что дешевле? Для одних случаев – одно, для других — другое



Миф 2.1. SaaS безопаснее on-premise


Миф 2.2. On-premise безопаснее SaaS


Наши клиенты делятся на две большие, примерно равные группы. Одни говорят «чтобы мои данные были где-то в интернете? Боже упаси! А вдруг злобные хакеры взломают, украдут или удалят? Нет, пусть они будут на моём сервере, тут, у меня в офисе». Другие: «чтобы мои данные были тут, в офисе? Боже упаси! А вдруг пожар, кража или маски-шоу? Нет, пусть они будут где-то в интернете».


В реальности безопасность – понятие многофакторное, местонахождение сервера – лишь один из многих факторов, говорить что одно безопаснее другого не серьёзно.


Так что безопаснее? Для одних случаев – одно, для других — другое



Миф 3. SaaS плохо кастомизируется


В теории, для on-premise можно дописать в коде то, что надо для конкретного клиента. На практике это приведёт к разрастанию количества версий. Стоимость сопровождение взлетит до небес, и никто старается ничего подобного не делать. Вместо этого подгружается какой-то конфиг и приложение любого вида настроит само себя.


В реальности кастомизируемость зависит от зрелости ПО и от предусмотрительности разработчика. А не от способа распространения.


Так что лучше кастомизируется? В одних случаях – одно, в других — другое



Есть и другие мифы, менее популярные. Но столь же ошибочные. Но пока, для иллюстрации, и этих хватит



Часть вторая. Холивар



Есть такое понятие как «число Мюллера» — количество сущностей, которыми мы можем оперировать. 7+-2. У каждого своё, в стрессе может уменьшаться вплоть до 1.


Если сущностей много, мы начинаем упрощать и обобщать. Вот тут кроется подвох – упрощаем и обобщаем мы каждый на свой лад, а слова используем одни и те же.


Вообще, в любом холиваре видны как минимум одна из двух ошибок. А чаще обе сразу:


1. Разные значения одних и тех же слов


Например, для кого-то в два раза дешевле = лучше. Потому что ему воспользоваться надо всего 1 раз. А другой смотрит, за счёт чего цена такая, и видит, что сделана шняга дендро-фекальным методом, что для него неприемлемо. Для него лучше = дороже, но нормально. Потом они спорят, забыв уточнить, что имеется в виду под «лучше».


2. Не все готовы увидеть в другом человеке ДРУГОГО человека и признать, что у него свои цели и приоритеты


Кому-то важны технические характеристики, а кому-то – удобство в использовании. Реально важнее, в его ситуации неудобно = «меньше денег в месяц заработаю» или «буду раздражительный и рычать на домашних». Ему важно переплатить несколько процентов своего дохода за многие часы хорошего настроения свои, жены и детей. А кто-то сам живёт, ему лишние несколько сотен долларов – важны, а бесить дома некого. Если эти двое не хотят друг друга слышать, то встречайте холивар типа «Mac vs Windows» или что-то подобное.


Кстати, «не хотят друг друга слышать» — очень часто САМАЯ главная причина холивара. К сожалению. Как только захотят, окажется что можно пожать плечами, сказать «ну да, в твоём случае так» и сменить тему.


Замечали такое? Или, наоборот, замечали что-то другое?

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


  1. aram_pakhchanian
    12.05.2019 05:39
    +1

    Когда много лет тому назад в институте мы учили английский, то чтобы выкрутиться, отвечая на вопросы, начинали с “it depends”, чем приводили англичанок в бешенство. Потому что когда ответ на конкретный вопрос звучит как ни о чем, это вызывает ощущение, что тебя дурят.


    1. salkat Автор
      12.05.2019 09:15

      Конечно, Вы правы. Когда клиент меня спрашивает, какой вариант лучше конкретно для него — я ему с аргументами отвечаю, что именно ему стоит предпочесть и почему. Тут же я хотел показать, что нельзя заявлять «этот вариант точно лучше всегда для всех случаев»


  1. vladimirad
    12.05.2019 08:47

    Ребята! Давайте жить дружно!


  1. kirillrst
    12.05.2019 10:53

    А чего холиварить? У бизнеса есть задача зарабатывать деньги в определенных условиях. От этих условий зависит выбор. Приведу критерии:


    1. Конфеденциальность – это отсутствие возможности доступа к данным третьей стороной включая вендора. Если конфеденциальность критична – выбираем on-permise. Обычно это определяется политикой бизнеса, либо требованиями регулятора.
    2. Безопасность – защита от злонамеренных действий третьей стороны. Почти всегда ведор обеспеспечивает лучшую безопасность своего SaaS продукта, чем клиент с on-permise. Если, конечно, у клиета it-команда не круче, чем у вендора.
    3. Цена, в которую обязательно следует включить сопровождение (интеграцию, обновление, обеспечение доступности, проблемы масштабирования). Называется "совокупная стоимость владения" (TCO). Для клиента SaaS TCO всегда ниже, т.к. вендор на себя забирает все эти расходы и экономит на эффекте масштаба. Грубо говоря, на одном сервере может быть много клиентов.
    4. OPEX vs CAPEX – это уже вопрос фин отдела. Кому-то удобнее помесячно платить в случае SaaS, а кому-то один раз. Хотя часто с вендором можно по-разному договориться.

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


    1. kirillrst
      12.05.2019 11:06

      1. Скорость внедрения – для многих критичный фактор. При SaaS в течение дня можно принять решение – подходит или не подходит. Для on-permise могут пройти недели.


  1. HellKaim
    12.05.2019 13:32

    Статья 100% верная во всем.
    Мы сами начинаем всегда с saas и потом уходим на on-permise.
    В нашем случае выгоднее держать все у себя, так как постоянно происходит глубокая интеграция, что сложно (часто) сдлеать с saas. Плюс таким образом мы избавляемся от зависимости от провайдера (канала) — все седят в локалке и даже падение и переключение на другой канал проходят менее болезненно. Лишь часть функций "икает", а не вся работа встает.
    Но у нас свои devops'ы и нам так проще.


    1. HellKaim
      12.05.2019 13:33

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


      1. nApoBo3
        12.05.2019 20:20

        При использовании SaaS требования к каналам связи не ниже. Я бы сказал, для современного бизнеса отказоустойчивые каналы связи уже необходимость они нужны в любом случае.


        1. HellKaim
          12.05.2019 22:10

          Вопрос в том, какую модель угроз вы используете и какой у вас бизнес. Мы считаем, что падение почты и мессенджеров на 30 минут для нас приемлемо.
          Голос у нас через GSM так что это вообще не зависит от канала.