谈谈对 aPaas 的理解
13901
2020-12-30 16:43    文章来源:孙轲
文章摘要:saas 进入我国近 10 年,从 14 年的第一波投资热潮到,今年的投资热点,他有什么变化呢?而 aPaas 又扮演一个什么角色呢?对于有些人冠以「简单的玩具」,那 aPaas 到底是不是这么回事呢?

saas 进入我国近 10 年,从 14 年的第一波投资热潮到,今年的投资热点,他有什么变化呢?而 aPaas 又扮演一个什么角色呢?对于有些人冠以「简单的玩具」,那 aPaas 到底是不是这么回事呢?

1. aPaas 的是什么?

1.基本定义

aPaaS 全称是application Platform as a Service ,即应用程序平台即服务。他的特点有两个

1.  提供高度抽象的组件和开发环境,让用户在「极短」的时间内就可完成应用的设计、开发、测试、分发。而且可以根据用户随时更新迭代。

2.  由于操作简单,平台封装了大量技术难点,非技术用户可独立完成整套开发流程。

这两大特点可极大的提高 中低复杂度 的系统的开发效率,并且大幅降低开发成本。据我们平台不完全统计,开发时间可缩短到传统系统开发的 十分之一,成本可低至五分之一。

2.基础组件

aPaas 系统一般包括:表单引擎,流程引擎,BI引擎这三架马车。

·       表单引擎,是承载用户业务数据的载体,通过拖拽的方式构建自己的业务表。

·       流程引擎,可让表单按照既定规则的流转起来,需要提供了常见的填写、审批、抄送、分支、跳转等节点类型。

·       BI引擎,根据已沉淀的业务数据,用户可根据既定的维度和指标,快速生成可视化报表。

一个完整的 aPaas 系统搭建流程是,先通过表单来设计表单字段,然后根据报表数据重新优化业务表单,最终形成设计-改进-再设计的正向循环。

2. 对企业的价值是什么?

我们用一家创业公司举例,创业时需要购买 CRM 来管控销售,随着业务发展,解决售后效率问题就需要采购售后系统,在往后员工越来越多,可能需要上一个 OA 系统。这样的情况就导致一个创业 3~4 年的公司内部拥有 4 套不同的管理系统。而系统之间数据很难互通,最终形成数据孤岛,而员工往往需要在多个系统里面切换。

数据孤岛根源是在于传统的 saas 软件,无法根据用户的需求,快速的链接到新的场景中,究其原因是软件架构一旦成型,能难低成本的对于数据模型进行扩展,而这种扩展往往已有的架构侵入性巨大。 所以大家可以看到,CRM 系统添加一个售后模块,需要半年的时间才能稳定运行。 而这些成本最终成本就会转嫁到每一位客户身上。

对于国内复杂的企业协同环境,可以说每一家的企业都有自己的个性化的需求,这就导致了传统 saas 软件很难匹配好非标需求。

而 aPaas 的出现就是解决有限的开发成本与无限的个性化需求的矛盾。 

在企业不同的阶段,可以逐步给用户去上系统,创业初期,先上一个 CRM , 后面要上售后系统时, 把 CRM 的客户信息,轻松链接进来。而这些工作只需要 1天左右。企业在整个 aPaas 平台上面,很容易做到,跨应用关联、按需聚合等操作。这样的效率在传统的 saas 软件是无法想象的。

为了快速交付,aPaas 厂商大都会构建一套自己的模板体系,根据不同的行业、场景,沉淀出多规格的标准应用。 在具体落地时,实施根据用户的场景和需求,快速裁剪拼接模板,很短的时间内完成系统交付。这是不是有点类似于拼积木?而对企业,即提高了交付效率,又降低了使用成本,实现双赢。

3. aPaas 是不是玩具?

很多人理解 aPaas 只能做很多简单的需求,比如做 ERP 就无法实现。诚然,每一类系统是有自身的上下限。 据我们的实施经验,aPaas 的系统落地一般不超过 2 周,超过两周的应用实施会很艰难,何况 ERP 的实施在几十上百万,而 aPaas 的客单价不会超过 5 万,硬是要这么比,那不就是耍流氓么。

aPaas 是不是玩具,那需要看 aPaas 他的本质是什么?

我认为 aPaas 的本质是数据表的可视化操作(拖拽形成表单),生成 SQL 语句的可视化(数据工厂、聚合表、报表等)。它极大的降低了数据表和 SQL 的使用门槛。非 IT 技术人员,可以无需学习复杂的建表的操作,就可以生成超过 200 行的 SQL 语句(据我们后台统计)这种复杂程度,对于普通的程序员也不是一件简单的事。 

另外,常见的 aPaas 平台,功能尚未完善,也是导致玩具论的一个主要原因。用2个点来 简单说明。

1.缺少实时公式计算,表单除了收集数据这个标配功能外,而在日常使用中,往往需要进行公式计算,自动的实现类似于 VLookup 、SUM 等函数操作。来想一下如果一个无法根据其他表进行汇总,无法提供丰富的函数,需要借助流程等额外的实现数据计算,那岂不是开历史的倒车。

2.无法实现数据预计算。例如在进销存场景中,最好的计算库存方式是,在调用时实时进行聚合操作「入库-出库」,而不是在出库或者入库的时候通过流程自动的对总库存进行加减,一旦流转出现异常,库存必然会出现错误。

这两点在使用时是普需的,所以功能缺失势必会让大家对aPaas 的能力产生怀疑。另外 aPaas 属于 saas 范畴,而 saas 的本质就是基于客户的续费,不断地共创迭代产品。我的观点是,「技术总归是要服务于人,符合人的需求才是正道。这与技术的难度没有关系。」

本文更多的从技术的方向进行阐述 aPaas 。作者在 aPaas 从业 3 年 ,深知国内的 aPaas 有很长路的要走。不管从产品的技术积累还是场景适配上,都需要进行大量的迭代。而我坚信 aPaas 未来式光明的,他用另外的一种交互方式来实现人与系统的链接。 利益相关 aPaas 厂商。

作者:速融云创始人——孙轲


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)信息科技有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)信息科技有限公司将追究其相关法律责任。

评论