• 21
杀死SaaS?温柔点!
统计 阅读时间大约10分钟(3666字)

2016-08-12 杀死SaaS?温柔点!

一个硬件效果的简单考核就变成了跟全公司人的斗志斗勇

猎云网注:本文转自安在(微信号:AnZer_SH)作者梁伟。他分享了自己所思考的一种打法以及该打法下应展开的做法,而对于SaaS来说,其实可能的打法有千万种,其具体做法自然也会有所不同。以下为文章原文:

1、之前写过一篇《杂谈:SaaS + 安全》(复制搜索,或关注Piz0n查看历史消息可见),限于篇幅没有展开,今天算作一个续篇。纯粹随笔,想到哪里写到哪里,可能会不够规整。

2、我文中所指都是多数情况或普世概念,而非特定行业、特定群体,如果老拿特殊群体说事儿的话,天儿都没法聊,更何况抬扛乎?!

3、我所思考的角度并非纯技术或纯商务角度,可能会引起部分人的不适。

1F SaaS 特性

SaaS 的特性网上一搜一大把,不再赘述。

但,SaaS 可想象的模式太多,所以很难概全,我觉得网上描述的那些特性,主要针对一些刚需SaaS 。

什么样的SaaS 是刚需?

之前我也发过一篇PPT描述我的观点。

有些传统IT架构中不可或缺的服务就是SaaS 的刚需,例如,邮件系统、知识管理、CRM …等等。

这些基本都是企业所必须的,对于大型企业来说,多以自建为主,但是中小型企业为了规避运维带来的烦恼,选择SaaS的概率会更大一些——这也是那些长尾。

另外,就是一些底层的XaaS 也是刚需。

例如很多PaaS和IaaS平台,其原因跟上面非常相近。

但PaaS 和IaaS 不是小公司能玩得起的,未来肯定只是少数掌握着“硬”资源和“硬”实力的厂商所垄断。

2F 安全SaaS特性

安全SaaS ,现在有一些定义为SECaaS,我其实没有太搞清楚SECaaS 所指之核心,所以我这里还是继续称为“安全SaaS”比较稳妥。

安全SaaS 就是指,现在安全厂商以SaaS交付模式为依托,所承载的那些安全能力,比如,基于云的Scanner、WAF ……等等。

安全SaaS 不是刚需,因为安全本身就不是刚需。所以安全上加上个SaaS 依旧改变不了这个事实。

之前聊天也有人跟我说过,安全都立法了还不刚需?——其实,立法这件事恰恰更能说明安全不是刚需。

非刚需是安全SaaS 区别于上面我所说SaaS 的最大特性。

但是,安全SaaS 有几个其他SaaS也有的特性——安全能力的出入口都统一了,安全产生的数据出入口也都统一了,安全的管理也都统一了…

这几个特性在其他SaaS里看起来不是什么,但结合上安全这块“非刚需”,这几个“统一”就很有的看了。

3F 垂直打法

有了两个特性做铺垫,打法其实就比较明朗了。

都说SaaS 是轻销售模式——这个不展开说了。其实安全SaaS 也是轻销售模式。

因为安全非刚需,所以很多需求都是来自顶层设计,而顶层设计的贯彻者多是大企业或集团公司总部有安全职责的部门。

所以,这种非刚需造就的顶层贯彻需求,以及上面说说的几个“统一”特性,就契合了一个安全SaaS 顶层作战计划——纵深垂直打法。

安全SaaS 绝对不适合一个个去死磕,即便你没磕过安全SaaS产品,传统安全产品总磕过吧?

而SaaS的价格特性就是低单价、高总价(因为群体大)、边界效应明显,所以安全SaaS 产品一个个客户去死磕,自寻死路。

以此可见,纵深垂直打法是目前安全SaaS 一条不错的出路。

但我认为,多数销售是不适合“吃透”一个行业的,虽然很多销售都会专注少数几个行业甚至几个客户,然后“吃死”,但并不代表他们能“吃透”。

吃透,是一种对行业及业务的深刻理解和思考,一般销售做不到(但我也见过几个做到的,但仍是少数)。而对售前等有技术基础的人员来说,却对此有着天然的优势。

所以,我所说的“轻销售”可能并不是大家一般所理解的“轻”,而是需要技术与销售能力的深度结合和再造,并非传统的销售套路。

关于纵深垂直大概就说这些,如果还没理解,再默念几个关键字——非刚需、顶层设计、“统一”的能力(不好意思,对此我也只能半遮半掩,不好说的更透了)。

4F 有些没必要谈的“话术”

SaaS 的本质是交付模式的改变。

一方面是用户体验有所不同,另一方面是收费模式的不同(其实这也算是另一种体验)。

但这些话,实在不适合在安全SaaS 产品的介绍中出现。

首先,安全不适合谈体验——毕竟,很多用户对传统安全产品尚无体验,在新交付模式下的安全的“体验”实在没什么价值。

其次,安全是一种难以量化的能力,为什么现在搞羊毛党的产品容易赚钱?因为他们有量化标准——减少业务损失XX万元。

但现在多数安全产品或服务,还是缺乏此类量化指标,这种时候谈价格优势或付费模式,缺乏对比依据,反而容易把SaaS交付模式拉回到与传统交付模式去对比,这样并不是什么好事。

另外,关于安全的体验,多说一句。

根本上来说,界面上的体验并不等于能力上的体验。

之前我做过很多售前工作,也有用户会跟我说谁谁家的界面漂亮、人机交互好,但是该扫的扫不出来,依然是然并卵。

所以,体验这种事,还是要分层次、分角度的去看,我这里所说的体验,明显不是界面问题。

5F “分赃”模式已死

安全SaaS因为要铺好大一片用户,所以很多人会建立类似传统渠道一样的合作伙伴来制定一种“分赃”模式,以促进产品推广。

但,这种模式仅限于外部竞争不多且不强的情况下使用,否则,其劣势远大于优势:

多竞品环境下,“分赃”模式直接导致价格战,这种价格战跟传统价格战没什么区别,但是会多一些参与者,而多出来的参与者可能把事情搞的更加混乱;

“分赃”模式其本意是促进野蛮生长,也就是说,在无竞争环境中,放血出来让大家野蛮生长,让我的SaaS产品到处生根。所以,一般分赃方不会去关注你的什么垂直纵深策略,而只是以“吸血”为主要目的。而在有竞争的环境下,这种模式本身就可能造成合作方有多种选择,而左右摇摆,甚至直接影响产品在当地的策略;

“分赃”模式只适合无策略打法。接上一条,可能有人会有疑问,为什么该模式只能野蛮生长?不能贯彻策略吗?在我看来,绝对无法贯彻!本来纵深垂直的打法就是上下冲突很多的一种打法,再加上分赃方多是来自外部合作方,贯彻策略上再出现理解上的差异,分分钟玩死自己。

所以,综上。在已经无法野蛮生长的今天,任何与此模式有关或类似打法,都会受挫——至于挫成什么样,需要观测的维度太多,不好评价。

6F 试用与服务

如果按照之前我所说的打法、说法、做法都贯彻了,还能走到这一步,应该说很有看头了——当然也不排除,只是商务关系造就的无意义的试用而已。

不过,到了这一步也来到了最危险的一步,毕竟,很多产品的最差体验就是来自试用。

这里,先从试用周期说起:我其实一直不喜欢长周期试用。

什么样的周期算长?超过10天,都算长了。

当然,我也能理解为什么当前普遍使用都是30天起步,甚至有90天试用的产品,反正大家都懂,就不多说了。

长周期的坏处很多:

话说的多,漏的就多。产品也一样,用的越长,毛病就越多,即便产品十全十美,用久了都会感觉到不爽。就跟男人结婚之后都想换老婆一样;

当然,有人可能会说,用户对产品的使用频度并不高。那就更惨了,人家都不经常用,你给那么长试用周期干嘛?

给用户廉价感,当然,这并不是一两家推行长周期试用就能造成的结果;

竞争信息泄露,这种问题很普遍,而且很多时候泄露并不是用户故意或竞争对手有意制造的,只能说,时间长了提供了太多机会;

而对于SaaS来说,可能还有更多的恶果(主要针对没有私有或混合硬件形态的SaaS):

SaaS相对传统产品来说更透明,如果没有一个“粘着点”仅仅粘住用户的话,可能很快就忘了有这么个试用产品了;

SaaS因为没有具体硬件形态,所以一般是一个账号的形态存在,再加上长时间没人搭理的话,给用户感觉会比传统产品更廉价;

我能想到的好处也不是没有,但除了与对手在此项上扯平之外,实在也没什么更突出的地方了。

再说试用阶段的服务问题。

从原始的SaaS模式来看,服务是非常重要的一部分,从好听的方面来说,有着响应快、专家集中…等等优势,但从真实世界里发生的故事来看,SaaS作为“强服务、弱产品”形态的交付,在试用阶段如果仅仅让其以“产品”形式存在的话,本身就是一个不好的开头——这其实也是现在安全SaaS普遍存在的问题,当大家都强调SaaS中最后一个“S(Service)”的时候,缺失最多的恰恰也是这个“S”。

而另一方面,由于云的特性,很多试用用户使用的资源和正式的合同用户使用的资源是分开的。

而划分出来的试用资源往往是质量不高的非优质资源(例如,带宽比正式用户少、硬件比正式用户差等),一类资源的投入就代表了一个企业对此类资源上的用户的态度,那么,运维人员自然也不会对此类用户过分关注。运维人员所谈及的往往就是“付费用户优先”,虽然本质上没错,但如果以“纵深垂直打法”为前提的话,对试用用户的轻视所带来的恶果可能会更大——所以需要一个折中做法,就是从组织划分上,试用资源的维护和正式合同资源的维护应该是分开的:一组人负责试用用户,一组人负责正式用户,两组人可以不定期按需调换人员。

主要原因是,由于两组人面向的产品阶段不同,因此,用户的态度、问题和解决方式也不一样。

更为重要的一个层面则是,售前和售后的服务体系应该是不一样的,尤其是问题响应过程、以及问题处理的评价体系的差异,所以只有划分为两组人才能实现两套服务体系的独立存在。

7F 自我营销

安全SaaS 有望成为安全的一个入口——当然,其实我对此一直都有所怀疑。

但每次当出现安全事件的时候,其实就是各大SaaS平台的营销最佳机会,但大家能说的却都只有“我们的XX平台已添加此规则,请您尽快登录添加”。

其实我已经不知道这个时代对安全服务的定义是什么样的了,我只知道,在我还被称为服务工程师的时候的准则是——把事情做在前头,把话说在后头。

作为服务交付模式来说,不用过于刻意扭转什么样的印象而去刷存在感。

普遍情况下,用户的惊喜不是来自于“哦,你的规则也上来了?!”,而是来自于“啊?!这个是最新0-day的防护效果报告吗?”。

就好象,我现在不愿意去海底捞的最大原因就是——每当我聊的正high的时候冲上来个满面堆笑的小伙子问我需要什么服务——说实话,您要是没这个眼力件儿干脆老老实实的盯着我什么时候招手就好了,不要假装很懂我的样子。

8F 结尾

说这么多,其实也就是我所思考的一种打法以及该打法下应展开的做法,而对于SaaS来说,其实可能的打法有千万种,其具体做法自然也会有所不同。

但是我觉得有一点应该是不会变的——SaaS 本身因其作为强服务模式的存在,所以对交付方来说,其打法不再是局限于一个硬件盒子的雕琢,而更应注重负责业务各个层面的人员之间的衔接与串联,而自古以来,管好人就是最难的。

毕竟,每个人都有不同的想法。

销售希望尽快签单、售前可能还带点技术情怀、运维希望节省工作、后台则希望bug被巧妙的无视……这样,原来对一个硬件效果的简单考核就变成了跟全公司人的斗智斗勇。

1、猎云网原创文章未经授权转载必究,如需转载请联系官方微信号进行授权。
2、转载时须在文章头部明确注明出处、保留官方微信、作者和原文超链接。如转自猎云网(微信号:lieyunjingxuan
)字样。
3、猎云网报道中所涉及的融资金额均由创业公司提供,仅供参考,猎云网不对真实性背书。
4、联系猎云,请加微信号:jinjilei
相关阅读
推荐阅读
{{item.author_display_name}}
{{item.author_display_name}}
{{item.author_user_occu}}
{{item.author_user_sign}}
×