文/明道云创始人任向晖
在过去的一两年内，零代码应用平台日益受到企业的关注。他们用零代码平台来实现核心业务流程的数字化，一定程度上替代了昂贵的定制开发，也减轻了产品使用集成的负担。但究其本质，他们选用这个新门类的主要理由来自以下四个方面。很多总结都来自于用户自己的表达。
提升开发和部署效率
零代码/低代码平台对企业应用市场的首要价值是提高开发和部署效率。它把传统的DevOps流程充分缩短，它不再需要软件研发人员为构筑一个应用去建立基本的前后台框架，也不必为重复性的数据增删查改环节编写代码，它还去除了编译和应用部署的环节，让开发的应用直接在平台上运行。所有这些设计，让传统企业软件开发的效率提升十倍不止。
因为零代码平台能够快速产出可用原型，因此搭建者和使用者只需要花费很少的时间来进行需求沟通与确认。而在传统软件开发流程中，需求沟通所占的时间成本可能高达三分之一，甚至更多。
从整体上看，使用应用平台搭建应用比使用原生代码开发到底可以提高多少倍的效率呢？根据应用性质和复杂度不同这个系数差距会很大。我们可以列举两个具体场景例子来对比一下。
如果要开发一个个性化，满足特定企业需求的CRM应用，包含产品，研发和测试等基本开发岗位的人数至少为4人（研发通常会需要后端和前端的开发人员），对于熟练的团队，此类项目大概需要1-2个月，我们按照30个工作日计算，那大概需要120个人日。
如果使用应用平台搭建，一个人大约需要5天的时间（假设CRM应用管理从线索到收款的全部流程），也就是5个人日。这个例子大概能够形成24倍的人效差距。
再举一个部门应用例子，比如物流部门要开发一个根据订单和订单产品组合派车的应用，需要将物流单派发给预先签约的物流公司和司机，并跟踪物流从接单到交付的全过程。定制开发大概需要90个人日左右，而使用应用平台搭建大概需要10个人日。这个例子形成了大约9倍的人效差距。
同时还要考虑到原生开发所需要的人员成本一般都要比应用搭建者更高。而且，应用搭建模式下，花费的主要时间依然是在需求分析和系统设计上，真正需要动手完成配置的时间一般少于总时长的三分之一。当然，在原生开发方式下，这个比例也大体如此。
迎合业务快速变化
零代码应用平台门类越来越吸引企业用户，还因为企业总是面临多变的信息化需求。即便花费了很高的成本设计，开发和部署完成的业务系统，随着时间的推移，业务需求会不断发生变更。这种变更让使用者很头痛，如果勉强继续使用原有的系统，业务变化无法在信息系统上体现，如果停下来修改软件，不仅有成本和时间上的负担，有时候干脆就是不实际的。定制开发项目随着交付的结束，可维护性会变得越来越差，即便开发者提供了文档和源码，新接手的团队也很难快速上手。
新办企业在信息化建设早期，往往因繁就简，既没有能力，也没有必要去采购过于复杂的企业级软件，也不会去委托定制开发，而是选用一些相对简单的SaaS应用。如果企业能够顺利地通过初创期，扩大了业务规模，在一个特定的时刻，总是需要重新选型产品或者落实建设方案。这种IT架构升级的痛苦我们在各种规模的企业中都能普遍地看到。
应用平台产品似乎天生就是为了解决这类问题而出现的。它本身没有固有的数据架构，也不带有固定的业务流程，具体的应用搭建完成后才拥有了这些要素。这看起来比具体的应用产品要慢一些，但是它的价值也在于因此获得的灵活性。当业务规模成长以后，企业往往需要更加精细的过程管理，因此需要追加业务对象，增强数据属性。这对于应用平台来说是家常便饭，增加一组数据表，和现有的数据对象实现关联，就像修改一个应用配置一样简单。同样，调整数据字段，修改或者建立新的业务流程都是一样的简单。通过应用平台，用户大幅增加了自我实现的能力，不再依赖繁重的外包开发工作，也不需要自己建立昂贵的软件研发团队，更不会受制于固定的应用软件的局限。
克服数据孤岛问题
在企业信息化工作中，因为孤立的定制开发项目和使用多种应用产品带来的数据孤岛现象是一大痛点。比如，在CRM应用中可能存在销售产品BOM（产品物料清单），而在采购和生产环节中也会存在BOM对象，这些对象可能是完全一致的，也可能不一致但存在相互关联。
为了解决这个问题，企业可以建立独立的主数据中心，将核心业务所需要的共同数据对象通过一个统一的数据平台。近几年流行的数据中台理念大体就是指的这个过程。零代码应用平台本身通过API集成也可以完成这个使命，而且它还提供前中后台一体化的解决方案，也就是用APaaS直接构筑应用，不再需要额外建立数据中台。类似销售产品BOM这样的对象就直接在APaaS平台上作为一个应用组成部分，销售、采购、仓储等业务流程均可直接引用，保证了数据的一致性和实时性。
应用平台天然的开发性让所有使用APaaS管理的应用数据都可以被方便地读写，结合工作流能力，甚至能够自动获得数据更新或者向外部应用系统推送数据。设想一下，如果一家企业完全依赖APaaS产品构筑全流程业务管理系统，当然就完全克服了数据孤岛问题。
业务开发者的参与
由于去除了对代码开发的依赖，应用平台的实际使用者包括IT专业人员和业务人员。即便在少数情况下，会需要软件工程师通过低代码能力解决一些局部复杂问题（比如一个逻辑判断），大部分的应用实现环节都不需要软件编程能力。当然，因为企业应用本身的复杂性，具有IT背景的人员会更加容易上手和掌握零代码工具。而非开发者，或称业务开发者的参与价值，则主要来自他们对业务流程的熟悉。
能够让业务开发者加入到应用实现过程中，不仅是为了降低成本，还因为业务开发者对实现目标的清晰，对需求细节的掌控。他们设计出来的应用往往比技术开发者设计出来的方案更加符合使用场景的现实需求。尤其在制造和工程领域，大量的应用场景是在特定的现场，使用者是不同技能组合的人员，只有熟悉工程制造的人才能知道应用应该如何构筑，才能满足这些终端用户的需求。
在传统原生开发模式下，需求沟通和确认所花费的精力是相当巨大的，用户企业一般也掌握不了专业性软件需求文档的编写技能。编订出来的需求往往要么过于粗略，要么从需求越位到了解决方案。通过零代码平台来实现自主实现，是很多业务开发者的梦想。一旦实现，他们的成就感也很强烈。
我们在接触和观察大量业务开发者的过程中发现，有一定IT素养，对业务流程熟悉的非技术人员，经过一段时间的实践，都能够成为很优秀的应用实现者。甚至，在未来的企业组织中，应用平台的专业使用者和管理者会成为一种全新的专业岗位。
