有了这么多套件，为什么还需要 APaaS

文/明道云创始人任向晖

在明道云的业务活动中，比较常见的一个问题是和套件应用的关系。一个有具体应用需求的客户为什么不从市场上购买现成的套件应用，而要选择 APaaS 来构建呢？反过来说似乎也成立，既然一个平台什么应用都能搭建，为什么还要花钱购买不同的应用呢？

这个问题并没有一个简单的唯一答案。每个客户应该从自己的实际情况出发选择一个符合需求特点的方案。所以，我们和套件产品之间的确存在复杂的竞争合作关系。

首先，既然是相互具备替代可能的产品，APaaS 和套件之间必然存在着竞争。有很多应用套件购买和实施的成本高昂，风险巨大，客户转而利用 APaaS 来构建定制的应用；但也可能客户缺乏实现一个复杂应用的足够知识背景，不愿意贸然尝试自主实现，而是选择一个门类内成熟的套件产品。行业内习惯将套件产品称之为“稳态”，而把利用各种技术栈自主实现的方案成为“敏态”。

稳和敏两个字并没有很准确地表达出两种方案之间的特点，更没有说清楚选择的原因。是购买，还是搭建，更多是取决于客户和客户所在市场的特征。

（1）APaaS 适合离散度高的业务需求

客户在不同阶段要解决的数字化问题往往会外化成不同的企业软件门类。比如客户面临复杂的供应链管理任务时会诉求于 SCM 软件门类。但是，软件门类定义只是为了一个营销和沟通上的便利，并不意味着业务活动的标准化。一家制造业工厂的采购管理和一家银行的采购管理模式是完全不同的。所有的软件门类定义都不同程度存在着把问题简单化的弊病。

每家企业要解决的问题都是具体而真实的。我们把市场上所有企业的同类需求分析之后就会发现，不同性质的业务问题之间的离散度大不相同。所谓离散度，就是需求多元化的程度。如果这个市场上所有企业的需求都是一致的，那么毫无疑问他们会选择现成的套件产品，相反，如果市场上每家企业的需求都有所不同，套件的普及应用就会大打折扣。事实上，在很多企业软件门类中，需求离散度都很高。下图大致反映了常见的企业软件门类所对应的需求离散度。越靠左边的离散度越高，越靠右边的标准化程度越高。

这张图谱基本呈现出了 APaaS 方案适用的需求领域。在图谱左侧的这些门类对应的大多是企业核心价值创造流程，它们在行业之间有差异，在同业企业之间也有差异。比如，LIMS（实验室信息管理系统）就是一个典型的例子。虽然实验过程管理是一个泛在的需求，但是不同企业需要完成的实验分类和性质都有巨大的差异。即便是同样一个细分市场，不同厂商的产品组合也不一样。这也难怪，即使是 LIMS 套件，它们自身的可定制能力也是很强的。用 APaaS 方案只是把可定制行进一步放大而已。在图谱的右侧则是相对标准化的业务活动。在价值链理论中，它们被定义为支持性业务活动，比如人力资源和财务管理。不同企业，无论大小和行业，从事这些业务活动的模式和流程都是比较接近的。

有人可能认为像 CRM 和 ERP 这样的门类也是很标准的，没有任何按需定制的必要。这要看你对 CRM 的定义。如果仅仅指销售漏斗管理这个单一的业务活动来看，它的标准化程度的确很高。但企业客户具体的需求往往无法被一个标准化漏斗管理所涵盖。比如，对于工业品销售而言，客户往往需要面对多层次的渠道代理和直接客户要进行复杂的报价，报价单的制作就是一个非常专业的过程。一个标准意义上的 Pipeline 工具不可能满足这样的需求，因此市场上又出现了 CPQ（定制报价）这样的补充软件门类。像 Salesforce 这样从 CRM 套件发展而来的全能厂商也是因为看到了 CRM 需求的离散性，才逐步发展出了自己的 PaaS 能力。国内的 CRM 和 ERP 套件厂商也不例外，它们中有很多都在几年开始布局 PaaS。

所以，判断是应该自主构建还是购买套件的首要因素就是需求内在的离散度。在明道云合作伙伴交付的项目中，处于离散端的问题占绝大多数。

发表在明道云博客上的32个企业软件门类名称和释义 一文中介绍了主要的企业软件门类和利用 APaaS 来满足需求的适配度。

（2）需求越成熟，越适合 APaaS

判断这个问题的第二个因素来自企业对相关数字化需求的成熟度，它是企业业务发展阶段，企业规模和相关行业知识的综合反映。业务发展阶段越靠后，企业规模越大，相关的行业 Know How 越齐备，对应的数字化需求成熟度就越高。成熟度最高的企业所持有的需求和方案往往被称为行业最佳实践。而相反，业务刚刚起步的小型企业则往往没办法对业务需求提出切实的构想，它们的很多业务计划依然有待市场的验证。

对于高成熟度的业务需求，其实更适合用 APaaS 来构建。这听起来可能有悖直觉。但实际上，这是企业数字化市场的常态。小型企业青睐开箱即用的套件，大型企业即使没有 APaaS，也经常诉诸于定制开发。只是在现实中，企业选择 IT 方案有一个渐进过程。虽然按需构建的方案更适合需求成熟度高的企业，但它们也是从小型企业和小规模业务发展起来的，所以，在不同的历史阶段，企业会面临调整数字化方案的需要。

如果没有成本和周期的制约，所有的企业都会选择按需开发自己所需要的管理应用。但是制约是无处不在的，企业不愿意面对开发失败的风险，也可能缺乏应用相关的领域知识。所以，即使是有花费能力的大型企业也经常选择 SAP S4 这样的套件应用，用于满足核心 ERP 需求。

但这是过去。在没有成熟的 APaaS 平台时，所谓的贴身定制意味着高昂的成本和差强人意的质量。那 APaaS 是如何在降低实现成本的同时提高质量的呢？

高质量首先来自平台的组件式设计，应用不需要再对基础的原子操作（例如数据的增删查改）做单元测试，平台确保这些操作的正确性。应用搭建者只需要专注于业务逻辑的设计即可。所谓，一次对，次次对。这就像复杂的建筑工程质量一样，项目工程人员不需要花时间去逐一测试各项建筑材料的安全性，它们由各自的供应商提供质量保证，整个工程项目的进度和质量才有了保障。

质量来源之二来自于 APaaS 应用实现的“简化”。 你可能会觉得很奇怪，定制搭建一个应用怎么会比现成的套件更简单呢？这是因为一家个别的企业搭建的应用，无论它有多么复杂和全面，都不再需要考虑跨行业和跨企业的复用，或者说，这个应用不必具备过高的抽象层次。很多人依然质疑 APaaS 能否用来构建复杂的 ERP 应用。客观地说，ERP 的复杂性来自它产品化的抽象过程和企业实施的具象过程，所以可以复用的 ERP 产品是很复杂的，但降低抽象层次，直接为一家企业实现的 ERP 应用的复杂度并没有到高不可攀的地步。

在 ERP 和 CRM 套件中，为了适应全球企业实践和财务管理需求，有大量的配置策略，覆盖从产品与物料管理模式，生产批次方法，销售定价和折扣模式，采购模型，仓储和物流形式，会计科目和处理方法，人员绩效评价方式，多语言，多币种，等等。这些配置项加总起来是一个巨大的篇幅。套件厂商开发产品时的绝大多数精力和成本都投入在了这些复杂性上，而且实施过程同样因为这样的复杂性而变得格外昂贵。

利用 APaaS 来实现这些需求就没有了这样的义务。它着眼于围绕特定企业的需求，没有复杂的实施配置，直接了当的实现，简化了逻辑，这就是 APaaS 给企业带来轻量化 ERP 实现的原因。

要利用 APaaS 来构建自己的 ERP 是不是适合每家企业呢？答案肯定不是。它需要企业自己对数字化需求有充分的梳理，能够专业地设计数据模型，并且对相关领域的企业软件有充分的应用经验。这些特征就是我们所说的需求成熟度。如果企业自身的需求成熟度不足，那么明道云的专业合作伙伴就可以帮上忙。有了这个前提，企业应该选择 APaaS 构建方案，而不必再舍近求远购买套件后再实施。

（3）用了 APaaS，为什么还需要套件？

再谈谈我们和套件产品之间的合作关系。到目前为止，明道云 HAP 一共签署了30多家产品生态伙伴，主要集中在 BI，物联网，RPA，数字孪生，SCRM，小程序平台，费控等门类。这些产品都和明道云进行预先的集成，数据可以非常方便地和 APaaS 构建的应用互通。

之所以发展这些生态伙伴关系，是因为它们的确是 APaaS 很好的互补品。尽管有着突出的通用性和灵活性，但 APaaS 本身并不能闭环企业数字化的所有需求。在建立数字化系统的过程中，依然需要很多专业领域的工具来处理特殊的任务。比如物联网平台解决了与设备的连接和数据协议转换的问题；BI 解决了异构应用数据汇入和转换的问题；数字孪生解决了物理和空间对象可视化的问题；小程序和 SCRM 等工具解决了与消费者连接的问题。

不过，可以看出，生态合作的软件产品大多数是通用工具和特殊场景的管理应用。很多也是在云计算时代发展出来的新型工具。这类工具和 APaaS 类似，都着眼于提供一类专项能力，而不受限于具体的业务场景。在工具层面之上，由客户自身或者专业实施者来低成本架构解决方案。无论是通过 APaaS 来实现企业应用，还是通过 RPA 来实现业务流程自动化，都是这个思想的反映。这些工具和 APaaS 一起构成了数字化建设的新型材料，和传统的套件应用叠加有着本质的不同。

除了互补的工具产品之外，我们也完全认同管理套件存在的价值。不仅依然会有众多的企业客户选择套件，APaaS 的应用实施也实实在在地从套件的架构中学习到领域知识和实施方法。在我们的业务经验中，凡是已经使用过套件应用的客户，再通过 APaaS 实现个性化应用都要容易得多。至少，软件要完成的业务流程是清晰且得到过验证的。

为此，明道云 HAP 专门建立了“集成中心”，其中预置了上百个中国主流的企业软件和 SaaS 产品的接口配置，用户只需要安装对应的集成，就能够在 APaaS 应用中直接零代码调用该应用的接口。

除了我们主动寻求与套件产品的生态合作以外，也有不少软件产品会主动找到明道云。这些主动寻求合作的软件产品大多数定位在离散度较高的业务领域，在产品持续发展若干年后，较大的客户组织自然会提出诸多个性化或者扩展性的需求。对于一个标准套件来说，迎合这些需求意味着不断提升产品的复杂性，不仅提高开发费用，还对产品的易用性和易实施性带来伤害。这种情况在管理应用市场是非常普遍的。

解决这个矛盾的最好办法依然是管理好自己的产品边界，在充分提供开放接口的前提下，让客户能够通过扩展应用的方式来实现这些延伸需求。而 APaaS 就是解决此类问题最好的工具。在明道云服务的客户中，使用 SAP，金蝶，用友，纷享销客，合思，销售易等套件公司产品的也很多。他们会充分利用现有的套件应用数据来建立扩展应用场景。比如从 ERP 数据中获得产品主数据，用于建立生产计划应用；从销售管理应用中获取客户和订单数据，用于构建履约评价系统；与费用控制应用连接，以向其提供业务编码。当我们看到这么丰富而多元的业务场景时，自然对每一个软件产品所能够承担的任务心怀敬畏。尤其是对于大型企业，如果要将所有的应用需求都压在单一的应用或者工具上时，任何产品都无法承受其复杂性。

但是，并非所有的产品厂商都是这样想的。试图通过全家桶来满足客户需求的想法和行动也比比皆是。我们尊重套件产品存在的现实，并寻求合作关系，但也有套件公司会拒绝合作，转而发展自己的 APaaS。这当然是一个无可厚非的商业决策，但它也把合作的大门关上了。客户也不得不进行非此即彼的选择。好在这两年，因为企业软件公司的盈利压力，选择走全家桶路线的厂商越来越少了。

企业软件产品的复杂性和客户需求的多元性决定了“你中有我，我中有你”的长期局面。在全球市场，都不存在一家独大的厂商，即使像 SAP，Oracle 和 Salesforce，它们之间的产品也都能相互替代。虽然也有少数公司发展出了全系列的产品线，既包括应用，也包括应用平台，甚至还有中间件，但是细分到单一市场，它们都不可能全领风骚，有的在市场上的份额微不足道。

所以，我们非常欢迎套件产品公司和明道云合作，开放 API 接口，在明道云集成中心上架您的应用集成配置。对于需求明确的客户来说，如果有简洁好用的应用，并且不会产生数据孤岛，选择套件的理由依然很充分。这种合作即便不能全面双赢，但起码不是零和的。