SaaS标准化和定制化的博弈(saas标准化和定制化的博弈论文)

编辑导语:对SaaS企业服务来说,“标准化”可以理解为“领域 群体 环境 业务目标”之下的平均的可接受的作业规范和条件。本篇文章梳理了SaaS产品中解决个性化、加固标准化的方法,帮助产品更好地发展,一起来看。

一、怎么理解“标准化”?

标准化是个相对性的概念。针对SaaS企业服务来说,“标准化”可以理解为“领域 群体 环境 业务目标”之下的平均的可接受的作业规范和条件。

这些规范和条件包括组织架构、人员角色、操作流程、数据储备、作业效率等。

倘若把“领域”从鞋业换到房地产行业,“群体”从山寨作坊换到品牌厂商,那么规范和条件自然就不同。

站在SaaS产品角度,产品的标准化,依赖于行业标准化。这些标准化要素可以分为两类:业务标准化和客户标准化。

1. 业务标准化

业务标准化程度,存在进程和地区上差异性。

宏观层面,国际标准化组织ISO(International Organization for Standardization)负责当今世界上绝大部分领域的标准化活动,内容涉及信息技术、交通运输、农业、保健和环境等,每个工作机构都有自己的工作计划,该计划列出需要制订的标准项目(试验方法、术语、规格、性能要求等),ISO已经发布了17000多个国际标准

相对宏观层面而言,微观层面的标准化更加接近客户需求本身,对产品规划的意义更大。

比如客户企业内部的SOP类的文件和制度、区域性企业之间的“效仿”等,都能更直接地有助于标准化的形成。

国内企业之间的行业标准化程度低的原因之一,是发展的快的企业组织变革频繁,而效仿者很难保持同样的节奏。

通过行业标准峰会或委员会等组织,有助于行业圈的规范化和共同提升,但这是一项存在“愿志愿者困境(The Volunteer’s Dilemma)”的行为。

因为一旦标准推行成功,受益的是大家,但推动者的付出与其收益之间不成比例。因此靠一定的“奉献”精神支撑。

标准化程度低,导致需求本身在大环境下稳定性就不好。加上契约精神缺失,甲方到上线前还要求改这改那,需求风险太不可控。

2. 客户标准化

客户标准化主要体现在不同企业的发展时间、企业规模、管理风格、企业效益、信息化、数字化程度要求的不同,必然导致公司成员的工作习惯、整体素质、培训能力、管理制度等方面的参差不齐。

企业作为SaaS产品的客户,有着不同的规范偏好;企业的成员作为SaaS产品的用户的时候,自然就产生了个体之间的差异。所提出的诉求自然有所差异。

二、加固产品标准化

如何让标准化产品笃定持久,是SaaS产品的理想之一。

回到源头,需求从哪里来,就重新回归到哪里去。

笔者过去的工作经验中,提炼出如下几种加固标准化需求和产品的方式。

1. 产品共建与业务共建

尤其是垂直行业的SaaS服务商,单靠拜访客户、接听回访电话是远远不够。甚至只会收集到一些干扰视线的伪需求。

要更加深入理解客户的场景,方法之一是与客户共生,比如孵化客户:以合作的模式与部分客户一并开展业务,互利互惠,形成利益共同体。不仅在产品上实现共建,而且在业务上一起成长。

作为服务商,以实践为契机,以盈利的二次分配为造血、以痛点为需求源、以契约关系锻炼供需逻辑,将收费、场景、价值,拉近了进行打造。

2. 与标杆客户战略合作

如何将标杆客户和SaaS产品绑定在一起,共同把这艘SaaS大船开好,而不是浅表层面的租用软件关系呢?

其中一本办法就是寻求战略合作。

曾经做过一个平安的项目:SaaS服务方帮助平安的某片区打造600家本地标杆前置仓库,平安方帮助推广自己的客户五年内使用这套SaaS软件,并提供融资合作。

这样的好处是绑定利益共同体,增加抗风险的能力;另一方面可以让客户更加深入地提供产品顾问作用。

3. 单点突破

多年之后,大家所熟知的瑞士军刀,通常是下图这种多功能的:

SaaS标准化和定制化的博弈(saas标准化和定制化的博弈论文)

但谁想到这是多年迭代后的结果,真正的瑞士军刀其实很单纯,就是下图这种直男,它定位明确(坚硬耐用)。

SaaS标准化和定制化的博弈(saas标准化和定制化的博弈论文)

也就是这种单一的功能产品,是他在多个国家的军队和民间广受好评,并成为多个国家采购的军刀。后来才衍生出多中用途的多功能军刀。

类比于SaaS产品,也可以借鉴这种单点突破的经验。

一方面,单点突破,是产品找到突破口的最短路线,有助于快速构建基本产品体系,优先抢占需求单一的中小客户,完成SaaS产品生命周期的起步阶段。

另一方面,单点功能一定是非做不可的,不太可能出现差异化,能被广大用户接受,所以一定是标准需求范畴的内容。

三、识别个性化需求

1. 个性化需求主要有这几种常见的特征

(1)不切合实际

举一个例子,有客户用惯了本地版的系统,换成SaaS版之后,仍要求一次加载2000条列表数据。

因为SaaS是B/S架构的,数据都存储在云端服务器上,每一条数据都是通过网络请求后获取的。

很难和C/S结构下本地数据的访问量和速度相提并论。所以大量的数据,很容易造成浏览器负荷超载而直接崩掉。

那么怎么办呢?

笔者的观点是不直接做,而是重新回归到他这个诉求的原点:展示2000条打算干什么?解决什么诉求……然后重新给他新的解决办法。

比如他要对比,那么是否可以提供导出功能;他要计算,那么是否可以直接就算好输出结果。

(2)ROI

一般人家的正常公司,不看ROI都是耍流氓。除非家里有钱,就是要占着茅坑不让任何人拉屎的那种公司除外。

“没有实现不了的需求”这句话虽然不严谨,但是有时候产研不能为了试探技术的底线而不计代价做需求。

比如不能无限在这种小概率事件上投入过多成本。不仅包括当前开发和维护的成本,还包括产品日后的建设性受到不可预测的局限。

(3)违背产品的价值定位和理念

案例:某商户新开发自己的App,但是没有后台,希望直接搭接服务商的中台,管理他们的后台。

理论上这是能实现的。但是即使给钱也不能做。因为一旦接了就意味着要兼顾两侧的业务,这将会导致整个产品中台定位的坍塌。

(4)通用性差

个别客户的、地区差异性的、时间阶段性的需求,往往不能长期通用。

所以在调研需求的时候,横向要调研更多客户,纵向要考虑时间等因素是否会导致需求不持久。

2. 可接受的个性化场景

常见的可接受的个性化场景包括但不限于数据、界面、功能的个性化。

(1)数据个性化服务

在SaaS软件中,需要提供数据个性化定制的功能来满足不同租户的数据需求。

(2)界面个性化

不同的客户来自不同行业,不可能使用同一个系统LOGO以及系统名字。因此,在SaaS应用中,有必要解决界面个性化问题。

(3)功能个性化

客户来自各行各业,有着不同的业务需求,系统的功能要与每一个客户的需求相符是一件基本不可能的事情。

因此,SaaS软件需要提供功能个性化定制的功能。

四、个性化需求的处理

个性化需求的处理永远是与标准化对立统一进行处理的。对企业服务商来说

  • 上策:标准版解决了差异需求;
  • 中策:在保证标准的同时,用其余方式解决用户的特异诉求;
  • 下策:定制和标准二者保全一个。

常见的具体办法如下:

1. 直接拒绝

每一个不合理的需求本身都有可能导致底层架构的不兼容,引入诸多风险因素。

如果产品只是走马观花地应付眼前的需求,最终会让这个产品越走越艰难。

直接拒绝是一种“断舍离”的做法,可能会失去一两个客户。

但从好的方面看,也是过滤非价值用户,以及市场份额把握的手段。

2. 为用户的个性需求定制开发

为客户的个性需求,另行提供产品或团队来解决,或者将该客户进行项目化独立开发。

比如在与一个大客户的合作过程中,由于其独特的业务模式和记账方式,导致无法与通用版的相匹配。通用版的客户根本用不到他的功能。

最终的解决办法是就将该客户的产品转化为私有云部署,独立开发。

3. 配置

配置说起来简单,但是也不是好办法。对大部分客户而言还是增加了操作复杂度,对开发更是增加了多倍工作量。

最理想的SaaS产品是开箱即用的,而不是增加前置的配置工作。

配置包括套餐配置、数据配置、功能配置等,将会在专门章节具体介绍。

4. 灰度发布

在处理一个医药门店场景时遇到这样的案例:

正常的流程是顾客可以通过线上B2C下快递单,总部会从远处的仓库把货物邮寄到客户手里。

但是异常的场景式有客户希望邮寄到附近的门店中,而不是顾客家里。并提供了如下理由:

  • 有些药品放在驿站,或者园区的快递专柜,担心温度等条件影响;
  • 药店希望与客户有更多接触,以便增加线下的温度;
  • 物流公司减少菜鸟驿站你的看管费用;
  • 提出诉求的顾客可能更顺路、更顺手。

于是逻辑就变为:

顾客下单——>选择到店自提——>系统获取门店地址作为收货信息——>仓库接单发货——>邮寄到门店——>店员接收通知顾客到店自提。

这种功能具有小众化,并且暗含了一些风险,比如系统获取到的门店的收货信息中电话是店员维护的,万一他不在店怎么办,门店保存的时候没有专门的设备万一纰漏怎么办等。

这时候如果客户执意要做,从产品角度来讲,可以提供灰度的功能。若客户能将其形成一种模式,那么就可以扩大化,并且从功能上做到更多的适配和支持。

5. 冷处理

如果你作为一个房屋设计师,智能居室的触控位点设计在那几个位置呢?

SaaS标准化和定制化的博弈(saas标准化和定制化的博弈论文)

如图所示。如果在交付之前就标准化一刀切设置,那么会发现这并不一定是用户习惯的?

在工作一段时间之后才发现这种情况下让用户DIY更合适。或者干脆改用不局限位置的声控、红外感应等。

同样做产品也是这样,在没有足够样本的情况下,很难一步到位,只能委屈求全做一些临时过渡功能。

那么这就提示我们,某些需求可以冷处理一下,不要着急着做。即使要做也不要深做,做好统一重构的思想准备。

6. PaaS化

走到PaaS服务能力的公司毕竟是少数。这依赖于足够的技术能力和资源,以及对高价值、高频接口和应用的拿捏。

典型的例子是Saleforece,如图所示,是艾瑞咨询提供的资料,其按照“共性需求解耦化、通用能力平台化”的思路,将分通用的部分从主体产品中解耦下来,以aPaaS的形式将其积木化。

SaaS标准化和定制化的博弈(saas标准化和定制化的博弈论文)

并将通用的API以iPaaS的方式提供给外部。整合产业链上下游厂商等不断丰富生态,显著提升客户粘性,不断抬高公司营收与估值天花板。

其好处如图所示,包括但不限于如下:

SaaS标准化和定制化的博弈(saas标准化和定制化的博弈论文)

  • 客户需求:定制需求被满足。
  • 边际效益:得到整体化的解决方案生态闭环,而非彼此独立的CRM、ERP、 OA孤岛。
  • 第三方共赢:ISV开发商被开放API吸引,合作共赢。
  • 服务商效益:增强其影响力与话语权,延长自身的服务链条。构建护城河!

总结

以上,个性化和标准化需求是相对的,并贯穿于任何产品研发的始终。

通常情况下,服务商会先将明确的部分标准化,然后满足部分客户的个性化需求,再逐步将这部分个性化需求标准化……如此一个循环过程。

另一方面,笔者认为合理的个性化需求更符合企业发展的现状。

此外,只有重视客户的每一个诉求,才有机会掌握市场动向。

总之,标准化与个性化的博弈,考察的是产品经理或高层长处着眼,短处着手的能力。

在整个过程中应当掌握一定原则,以价值为导向,不让产品锁死服务。

#专栏作家#

唧唧歪歪PM,公众号:唧唧歪歪PM(ID:jjyypm)。《后端产品经理宝典》作者,药学硕士转行互联网产品多年;熟悉跨境电商业务,医药领域;擅长大型后台体系,社交APP。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2023年3月20日 上午9:36
下一篇 2023年3月20日 上午9:46

相关推荐