APaaS使用模块化方法来构建各种企业应用程序。这是否意味着客户可以使用APaaS替代现成的企业应用套件?而启效APaaS平台如何代替现在的企业系统呢?
这个问题没有标准答案。就像有些家庭想买标准化的板式家具一样,也有人想完全根据自己的需求定制。企业的应用实现手段很大程度上取决于自身的IT应用能力和治理需求。
作为一个相对较新的企业软件类别,APaaS总是有一个发展和完善的过程。其对标准化应用产品的替代能力也由弱到强。
APaaS非常适合构建连接孤立的部门应用程序。这些应用程序解决了一个单一的问题,不需要与任何其他应用程序集成,并且使用相对较少的用户组。例如,制造业中的设备抽查,订单汇总由业务部门执行,项目部围绕其具体需求构建项目管理应用。这些应用可以在零代码/低代码的应用平台上搭建,非常方便,难度也不是很大。即使是没有接受过软件行业培训的业务人员也可以独立完成。
比如制造业的ERP往往需要扩展到工单和运单,CRM系统需要从一些营销活动中获取销售线索,但是整套ERP/CRM产品并不包含这个模块,或者其中包含的模块无法满足企业的需求。围绕单个应用进行扩展并不难,只要解决数据集成问题即可。即使数据集成困难,使用常规的导入导出在很多情况下也能解决问题。
应用深度的第三个层次涉及密集的集成工作,即解决不同应用系统之间的数据传输问题。例如,企业既有MAS(营销自动化系统),也有SFA(销售自动化系统),但它们是分开的产品。一个完整的APaaS可以在这两个应用之间搭建数据桥梁,也可以同时保留数据,方便跨境业务分析报告。能走到这一步的企业大多已经有很多现有的应用系统,一下子全部推翻是不现实的。因此,在应用APaaS的同时,必须解决数据集成的问题。数据集成有很多解决方案。除了前面提到的文件交换集成模式,目前普遍的做法是采用标准化的Restful API,这是消息集成方案的一种规范。幸运的是,大多数SaaS产品现在都提供这种接口。
最后,让我们客观一点。APaaS有能力替代应用产品,但不能也不需要替代所有应用产品。它包括几种情况:
1)一些特殊的专有系统在模式下不是典型的关系数据库应用程序。比如酒店业的PMS可能涉及复杂的动态房价计算;餐饮行业的收银系统,需要精致的软硬件集成。
2)对于一些非常标准化的应用,市场上有足够好的产品支持。购买应用程序的成本甚至低于构建和维护APaaS应用程序的成本。