APaaS应用平台能取代现成的企业应用吗？

文/明道云创始人任向晖

 

 

APaaS使用模块化的方式来搭建各种企业应用，这是否意味着客户能够利用APaaS来取代现成的企业应用套件呢？

 

这个问题并没有标准答案。就像有的家庭希望购买标准化的板材家具，有的则希望完全按需定制。一个企业的应用实现手段很大程度取决于企业自身的IT应用能力和治理要求。

 

APaaS作为相对较新的企业软件品类，能力总有一个发展和完善的过程。它对标准化应用产品的替代能力也是从弱到强的。

 

一开始，APaaS会非常适合构建一些孤立的部门级应用。这些应用解决单一的问题，不需要和任何其他应用进行集成，使用的用户群体也相对较小。比如在制造业当中的设备点检、某个业务部门要进行的订单汇总、项目部围绕自己的具体需求搭建项目管理应用。这些应用通过零代码/低代码的方式在应用平台上构建会非常便捷，难度也不会很高，即使没有受过软件行业训练的业务人员也能够自主完成。

 

第二级会涉及到一个现有系统的延伸需求。比如制造业的ERP经常需要延伸到工单和运单，CRM系统需要从某些营销活动中获取销售线索，但是成套的ERP/CRM产品中并不包含这个模块，或者包含的模块不能满足企业的需要。围绕单一应用进行扩展的难度也不高，只要解决数据集成问题即可。即使数据集成很困难（比如原有产品没有API接口），使用定期的导入和导出在很多时候也能解决问题。我们美国同行Outsystems在用例介绍的第一个就是SAP Extensions.

 

第三级应用深度就涉及到比较密集的集成工作，它要解决在不同应用系统之间流转数据的问题。比如，企业既有MAS（营销自动化系统），又有SFA（销售自动化系统），但是两者是割裂的产品。完整能力的APaaS能够在这两个应用之间建立数据桥梁，还能够同时留存数据以便于跨边界形成业务分析报表。能够走到这一步的企业，大多已经有了很多既有的应用系统，想要一时间完全推翻重来是不现实的。所以应用APaaS的同时，必须解决数据集成问题。数据集成的解决方案有很多种。除了前面提到的文件交换集成模式以外，目前比较通行的做法是通过标准化的Restful API，这是消息集成方案的一个规范。好在，现在大多数SaaS产品都提供这一接口方式。

 

第四级，用APaaS定制构建一个完整的应用。而且这个应用一定是该企业比较核心的业务系统。比较常见的包括CRM，ERP和PMS（项目管理）。当然，哪个系统更核心则完全取决于企业所在的行业和自己的运营模式。我们在实际案例当中看到几乎每个门类都可能成为某企业的重点应用，它一般都是管理企业主要价值创造活动的职能。

 

第五级，也是APaaS使用深度最高的一种，那就是利用它的灵活性构建相对完整业务流程的数字化系统。从营销、销售、运营、服务到管理会计。只要实施者掌握或者建立了科学的数据模型，用APaaS做个自己用的全家桶并非不可企及。它带来的好处除了快和省以外，更重要的是数据的贯通，消除了购买不同应用造成的数据孤岛问题。当然，一个复杂业务的全流程系统一定不会简单，没有足够的架构经验是很难轻易成功的。对于成熟企业，实施这个方案还有很多技术层面以外的问题要克服，比如迁移迭代计划，质量控制和员工配合等。

 

 

下图大致勾勒了应用平台和应用产品之间的关系，以及以上描述的五个应用深度层次。

 

 

 

 

 

最后，还是要客观说明一点，APaaS对于应用产品有取代的能力，但绝不能，也不需要取代所有的应用产品。它包括若干种情况：

 

1）一些特别专有的系统，模式上并非典型的关系数据库应用。比如酒店行业的PMS，就可能涉及到复杂的动态房价计算；餐饮行业的收银系统，要求精致的软硬件一体化。

 

2）一些非常标准化的应用，市场上已经有足够多和足够好的产品支持。买一个应用的成本甚至都低于搭建和维护APaaS应用的情况。

 

3）已经实施了高级的系统级应用产品，而且这些产品本身已经具备高颗粒度的自定义能力。比如微软的Dynamics产品线，Odoo开源产品，Oracle的APEX，Salesforce的Lighting等。因为APaaS本身的能力和这些产品的自定义能力性质是一致的，只是应用平台将这种高颗粒度自定义能力做得更极致一些。

近期文章推荐：

32个企业软件门类名称和释义

陈果说低代码快要烂大街了，我却想成为最烂的那个

信息架构和零代码应用搭建