夜雨聆风RaaS（Result as a Service，结果即服务）
听起来很理想，企业不再为软件或工具付费，而是直接为最终的业务成果买单
软件提供方根据客户使用成果来收费，成果越大、收费越多
没有成果则不收费，让客户白用
可到了具体执行阶段，往往有不可克服的难题，导致双方无法执行
并且越是大型企业，越是行不通
1、难以量化的效果
就以拓客软件来说，表面上看，是好统计的
软件/服务每带来一个“有效线索”，就支付一定数额的费用给软件/服务供应商
可怎么才是“有效线索”？按利润结果区分？还是按联系人的真实性？按客户的回款还是按合同的大小？
如果按利润结果，有多少是软件的效果？有多少是品牌、产品、销售员工、供货部门的贡献？
如果按联系人的真实性，那最后没成交又怎么算？
一个线索究竟能给公司带来多少利润，实际极难说清
无论从什么角度评估，都有其无法自圆其说的“硬伤”
很难建立一套让双方都信服的评估体系
况且“评估”本身对于大型企业来说，也是一项投入不小的“工程”
如果就“拓客”这项看似简单的场景来说，都很难评估
那创意设计、后勤保障、公司战略等影响因素更多的场景，更无从谈起
不光难以评估，而且软件/服务本身的谈判、交易成本也会很高，难以促成交易
2、不对等的投入产出比
RaaS实际上是一种“对赌”，而非单纯且容易被人接受的“多劳多得”，“质优价高”
对软件方的损失，远远小于对使用方的损失
假如企业因为使用了软件，无法获得客户和利润
对于软件方来说，只会损失众多使用者之一，以及本项目的软件服务投入
但对于使用方企业来说，是会影响其发展存续的
企业方对启用软件项目的投入损失，就暂不去说了
企业在市场上慢了一步、晚了一个节拍，结果很可能生死攸关
像金融、医疗、大基建等领域，更无法承担软件错误造成的巨额损失
这会让企业绝不会去“赌”，赌你的软件能带来正常的利润
只会让企业继续以“工具”的眼光看待软件服务和信息系统
其所承担的风险也仅是“工具”是否顺手所带来的“预期风险”
而不会去图使用“不成功”所带来的“便宜”
3、市场定价的硬逻辑
货物在市场上的价值是如何确定的？
必然是所有供需双方比较出来的结果，对于软件/服务同样也不例外
软件通常是怎么计价的？
目前只有这些才是公认的计价标准：
1）、使用时间（日、周、月、季度、年、2年……）：使用越久付费越多，但单价越低，这很自然
2）、用户数量：用户越多，付费越多，但单价越低，整体呈现正相关、斜率变小的曲线
3）、所开放的模块：功能越多，付费越多，很好理解
4）、投入的人力：即按“人天”报价，定制或接口开发时常用
5）、并发数量：比如网速、面向C端或小B端的平台等，决定的是短时间内同时访问的用户上限，并发越高，对硬件和软件设计要求越高，自然收费越多
可能还有其他的收费模式，但是绝对不会包括“成果的百分比”
假设一家企业，年收入10亿，利润2亿，那它一年要花多少钱在信息系统建设上？
按照工信部2024年统计，平均是营收的1.8%，也就是1800万元/年
事实上，这1800万只有少数企业能达到，传统制造和商贸企业一般只能达到1%-1.5%
也就是1500万元/年以下
如果你是软件提供方，你说按照营收的5%，或按照利润的10%，来收取软件及服务费用
收费将达到5000万元/年，2000万元/年
有没有企业会答应这个条款呢？答案是没有，并且是绝无可能
因为市场没有“傻子”，别人花1500万元/年能做到的事，我却偏要花更多
如果比例设定得和正常价格一样，企业又为什么不用更简单易懂的计价方式呢？
4、数据安全性
RaaS这种模式，必然要把企业经营情况摊开在台面上
也就是必然要让软件供应商了解到企业的真实经营状况，否则无法计费
这对绝大多数企业来说，是绝对无法接受的
企业往往要开放“核心业务数据”，甚至实时数据
这会带来极大的数据泄露和隐私合规风险
目的仅仅是为了和软件供应商“讨价还价”？
安全性风险可能带来的损失，远大于省下的软件/服务费
这让绝大部分企业不会选择RaaS这种模式
以上，注定了RaaS只能应用在成果极易量化、数据不太敏感的特定、少数场景中
无法大面积应用在当下的软件/服务商业环境里
不可能成为“主流”、“稳定”、“多方认可”的商业模式
所以软件/服务供应商，不要再把太多精力花在RaaS设计上了，这行不通
你对RaaS有什么理解和疑问？
欢迎评论区交流
