技术演进往往会推动企业内部职能与协作关系的变化。新技术会消灭一些岗位，也会创造出很多新岗位。大数据技术兴起，产生了数据分析师岗位，云计算技术发展，带来了对运维工程师的需求。同样，应用平台的出现，会让企业内部出现应用搭建师这样的岗位。只不过，这个岗位需要的是数字技术理解和业务流程知识的综合，而不是单项专业技术。因为应用平台能够替代相当比例的原生定制开发，所以它不可避免地会减少对重复性开发工作的需求，从而减少对一般企业应用开发人员的需求。

所需要的技能组合

通过应用平台搭建应用显然不需要软件开发能力，但也不意味着任何人都能够用同样的程度掌握。简单的单表应用创建难度类同于建立一个Excel表格，一般的职场人员都不会有难度，但是要结合自己企业业务需求，构筑一个包含多个业务数据对象，多个工作流程的应用还是需要一些特殊技能的。我们通常把这组技能称之为抽象和逻辑能力。

抽象能力是指从具体现象出发，抽取出规律和模型。在应用平台使用中，抽象能力有助于从纷繁复杂的人、物、事中识别出正确的对象，并给予合理命名和边界，从各种具体的企业管理流程中识别出工作流的形态，并能够用最简单的结构来表达它。举“个例子来说，在建立和销售过程有关的应用时，需要识别出与人有关的对象包括销售人员，客户联系人，和物有关的对象包括产品，产品价目表等，和事有关的对象包括报价，报价明细，订单，订单明细和销售行动等。这些对象构筑在一起，就能够闭环记录和更新在整个销售流程。

逻辑能力则值得一系列和逻辑学有关的知识和经验。在应用构建时，常常需要对属性做细分，那么用户最好能够理解什么叫互斥并穷尽（MECE），在设计工作流的时候，要准确判断分支条件、节点次序，并且要在脑中预想工作流真实运行时的数据形态变化。

与其说，抽象和逻辑能力是一种天性，不如说它更多是后天依靠经验来增强的。尤其在软件领域，一种事务的数据和流程架构大多数不是依靠聪明人每次构想出来的，而是产业通过最佳实践积累出来的。应用APaaS的时候，过往各种管理软件的使用经验，包括对那些软件的界面流程记忆，都能够用来帮助更好地使用应用平台搭建自己的应用。简单说，就是看得多了，也就会了。

零代码相关的岗位

企业不至于产生"零代码应用搭建师"这样的专职岗位。如果是，那其实也有悖于零代码平台所推动的"全民开发者"理念。全民开发当然不意味着企业中每个人都要从事应用创建工作，但是它着眼于降低应用搭建的技术门槛，让非技术人员也能够参与到应用设计和搭建过程中来。所以，可以预期的是，在应用平台品类普及以后，企业的业务职能部门和IT部门在岗位设计和工作内容上都会有一些随之而来的变化。

（1）业务部门可能自己承揽数字化建设的部分责任

其实业务部门一直以来都有自主解决IT问题的诉求。一位承担质量管理的经理当然不愿意内部求人来解决配套的IT问题。一方面因为业务不等人，另一方面，要在内部沟通业务需求和流程本身也是一件特别费神的事情。IT部门通常排满了各种业务系统开发和迭代需求，在决定优先度和实现方式的时候，常常公说公有理，婆说婆有理，很多时候不得不上升到公司管理会议上去争论。

在所有业务部门，从销售，营销，采购，到行政，财务，人事，其实都有能力自主通过应用平台来实现自己想要的部门级应用。如果控制每个应用的规模和复杂度，那么大多数应用甚至无需求助IT部门或者外部。因为APaaS产品天生的开放度和灵活度，如果将来需要和其他应用整合到一起使用，也是完全可以办到的。

所以，在任何职能部门中，一些善于运用计算机，有比较丰富应用经验的人可能在部门主管的授权下直接动手来解决。有的时候，部门主管甚至可能自己动手。我们在市场实践中，还看到CEO亲自动手的，虽然这有一些过度管理的争议，但实践证明缺乏IT背景的员工是可能掌握这一代应用平台产品的。读者如果仔细读过了本书的主要部分，应该对此有信心。

掌握APaaS的应用能力无疑是要投入时间成本的。要建立一个简单的部门应用，实际搭建所需要花费的时间以天计，但是搭建前期的业务分析和平台学习可能要花费更长的时间。实际的经验表明，一位有意愿，有基础能力的职员，可以在2-4周之内掌握基础到中级的应用搭建。这些精力的投入，对于企业和个人来说都是十分划得来的。对企业来说，节省了外包开发或者委托IT部门开发的开支和时间，对个人来说，这是职业能力的极致体现。

在职业评价中，用人者通常最看重的是几个特质，高级主管通常都是从拥有这些特质的人才中选拔的。

1）有很强的学习能力和习惯

2）搞得定（Can do）

3）熟悉客户、市场和业务流程

这些能力特质几乎能够确保成为一名合格的业务开发者。反过来说，一位合格的业务开发者也通常都拥有这些特质。能够帮助业务团队搞定复杂的IT问题，无论能力、态度和人缘都是卓越的。

（2）IT部门将为应用治理建立岗位

如果所有的应用开发都是业务部门自己搞定，那么IT部门怎么办？

首先，绝非所有的应用都那么简单，也不代表一个企业的所有应用都是由下至上来实现的。对于核心的业务系统，比如管理销售、财务、运营等环节的应用来说，最好还是企业通过专门部门或小组由上至下来推动。至少，分析和计划的过程应该有统筹性。即便实际从事搭建工作的员工来自业务部门，复杂应用也必须由IT部门来负责统筹指导。

除了零代码实现的环节，应用平台通常还提供API接口开发和低代码实现能力。这些环节通常必须由专业的软件工程师来参与。低代码也是代码，让忙碌的业务经理去从头学习Javascript开发是没有必要的。因此，在应用平台部署后，IT部门应该承担统筹规划和技术实现责任。除了应用实现工作以外，IT部门也可以集中和APaaS厂商反馈平台缺陷和提出产品改进建议。因为专业对等，这样的沟通效率要比业务部门分散来进行高得多。

中小企业如果没有专职的IT部门，则可以寻找服务商来外包完成。应用平台交付应用要比传统定制开发快速和便宜得多。大型企业的IT部门如果缺乏开发能力，也可以通常寻求外包商来解决，只是因为业务复杂度高的原因，所以通常对提供服务的开发商由更多经验和能力上的要求。

即便将应用设计和搭建工作外包给服务商，因为APaaS平台易于理解和透明度，用户企业也会感到非常放心，不会想定制开发合同委托那样是一个黑盒子。

（3）零代码/低代码小组

我们前面提到企业不太会专门设置零代码应用专员这样的长期岗位，但是在最近几年，大中型企业开始显性地研究应用平台产品，有一部分先锋型客户已经建立了专门的选型和使用小组，有些甚至建立了"零代码实验室"这样的临时组织。在新兴IT产品走向成熟和普及的过程中，这种做法其实很常见。它能够加速新技术的落地，也能控制风险，让技术应用过程更加有序。他们也往往成为APaaS厂商提供最深度服务的核心客户。

创业机会

新的技术，新的价值创造过程，新的需求不仅会改变用户行为，还会孕育新的市场。零代码和低代码平台的产品成熟会推动软件和信息服务业发生结构上的改变。这意味着创业机会。

（1）平台产品

在定制开发和标准软件产品之间，APaaS成为了一个新的选择。它既有标准应用的易用性，也有定制开发的灵活性。虽然它在前端界面自由度和逻辑颗粒度方面有所牺牲，但是总体而言，它给用户创造了净价值。而且每一个应用平台都有自己的目标市场，着重解决一两个领域的问题，并不存在应用平台通吃所有的软件需求的问题。大体上，APaaS产品可以分为模型驱动和可视化IDE两种技术路线，他们各有优缺点，但基本都是用来解决企业中后台业务系统的构筑需求。另外，还有一些分支分别解决特定领域的需求，比如用来建立网站和小程序的应用平台，将重点解决顾客前台系统的问题；还有更加细分的APaaS，比如在工业控制领域，人工智能领域和大数据处理领域，都开始有创新的应用平台产品出现。

平台产品的创业机会当然是最吸引人的，它能够触及上万亿的软件服务市场。但是平台产品的研发周期也是最长的，它需要一大批高级软件工程人员花费数年的时间才有可能打造出来。即便做出了可用的产品，还需要建立和顾客与渠道的连接，验证产品能力，打造品牌和影响力。这在企业软件领域是最高难度的创业方向。当然，一旦成功，回报也是惊人的。

目前，国内外已经有上百个APaaS产品正在成熟和发展的过程中。本书附录列举了一些成熟度相对较高的产品。

（2）ISV

参与APaaS市场最多的主体不会是平台产品，而是广泛的独立软件开发商（ISV）群体。他们是软件行业最核心的主力，分散在各个地区，各个行业和各个技术领域。

在软件产业，其实大多数厂商并不是只开发和销售单一软件产品的，这样的公司至多占市场的1%。所谓的独立软件开发商是指使用、集成和销售其他软件产品，但本身并不依附其他主体的软件厂商，这就是"独立"两个字的根源。不同的ISV创造价值的方式不同，有的是简单的软件分销，有的是集成其他软件产品为解决方案，有的是完全提供定制开发服务，有的是将其他软件产品或模块和自己的产品进行整合，再销售给终端客户。还有一些在平台产品上开发自己的应用或模块，再通过自己其他业务伙伴销售给终端客户。我们将这些企业统称为ISV。

我们就市场上几种常见的ISV类型，来说明APaaS平台产品对各自的市场机会。

1）定制开发商

这可能是数量最大的软件企业。他们在特定区域为企业按需开发各种管理软件，也有覆盖网站建设，小程序建设和网店建设等业务的。他们可以将传统的代码开发方式迁移一部分到APaaS平台，利用平台来实现个性化应用交付。

历史以来，定制开发商的生态位始终不高。他们受人力成本和客户议价能力的双重压力，很难向客户提供差异化的服务能力，总体上只能成本定价，按照人天收取开发费用。如果缺乏必要的项目管理能力，定制软件开发服务是很难获取持续利润的。

利用APaaS产品，定制软件开发商可以在多个业务环节实现增效：

* 使用APaaS搭建模型应用，用更低的售前成本获取客户。对比只能提供方案书的竞争对手，更能够获取客户的信任。

* 通过应用平台交付应用，既能够获取定制应用搭建的收入，也能够同时获得应用平台授权销售的佣金。

* 一旦客户采纳了平台+应用的交付模式，服务商和客户之间就建立了长期联系的桥梁。在应用平台上，老的应用可以不断发展，也可以根据客户需要创建新的应用。应用与应用之间的数据可以互通，从而能继续降低边际交付成本。

* 定制开发商有机会将已经提供过服务的应用留存下来作为解决方案，来满足其他同类或近似客户的需求。当这些客户案例积累到一定程度，还可以重新规划一个抽象度更高，更普遍适用的应用模型。

在中国市场，提供定制软件开发的门槛不高，这导致了比较充分的市场竞争。但是因为提供企业服务的性质，这些ISV很难退出市场，一旦签约了一些企业客户，供应商就有责任持续提供支持。这导致很多ISV卡在中间，既不能快速发展，也不能轻易撤退。应用平台的采纳可能是帮助这些ISV走出新路的机会。

2）自有产品和解决方案的厂商

第二类ISV拥有自己的软件产品和解决方案，但在面向终端客户时，并不仅仅销售软件产品，而是用项目交付的方式提供比较整体的解决方案。在大数据，人工智能，OA，HR和物联网领域，这样的业务模式更加常见。

这种既有产品，又有服务的商业模式的形成有软件行业内在的原因。首先，大中型企业的软件实施很少是只需要一个固定产品的功能就能完成的，或多或少都需要其他产品或者扩展的定制开发来闭环，所以始终需要一些供应商来提供项目化的服务；其次，在推广或者投标这些项目时，如果厂商缺乏专业能力和领域知识，也很难通过客户的考核。这就导致那些具备解决方案能力，有同时善于进行高效项目管理的公司在市场上留存下来。他们相对来说，具有更好的市场议价能力。和软件产品公司相比，这一类ISV拥有数量更少的客户，但是更高的客单价，这是因为他们获取了软件产品授权以外的各种增值业务收入。

产品加服务型的ISV非常看重互补产品。面向已有的客户和项目，一个高质量，高灵活度的互补产品几乎立刻可以增加价值。而且这些ISV通常比纯产品型公司更重视客户关系的维护，他们面向现有客户进行再次销售是比较容易的事情。

APaaS可以说是这一类ISV最适合的增值工具。它的部署和使用虽然可以简单到客户自助完成，但是对于大中型企业来说，想要充分利用APaaS的潜力还是需要依赖专业软件企业的服务。APaaS产品一旦部署到客户企业内部，就可以在客户粘性使用的前提下持续拓展新的应用场景。这对ISV来说，意味着持续的新增收入机会。

至于ISV自有产品和解决方案与应用平台的对接，在技术上有各种方案可以解决。除了双边开放API的快捷对接，在必要的情况下，也可以按需进行代码开发集成。集成开发的成本总是远远低于功能逻辑的定制开发，而且这样的对接开发成果通常都可以复用到所有客户。

因为APaaS产品极致的通用性，适合采纳APaaS产品作为延伸集成的技术领域非常繁多。我们可以举一些例子来说明。

比如物联网技术领域，完整的项目交付几乎不可能是狭义的物联网技术环节，客户总是要和自己的主体业务流程结合起来才能享受到物联网技术带来的效率提升。所以，物联网领域的ISV可以利用APaaS平台来解决：

1）设备、人员、场地等业务主数据对象的管理。

2）项目中可能包含的内部填报、审批、通知等离散流程。

3）自动化工作流，基于设备数据或事件触发，自动调度的其他数据操作和其他动作。

4）一些管理报表、仪表台的呈现。

5）基于业务数据结果生成自定义报表。

6）在管理闭环中，尚无法通过设备自动采集的数据，需要用人工填报表单的方式完善的情况。

7）特定项目非常特殊的流程需求，在过去不得不使用定制开发模式的其他情况。

除了物联网技术领域外，大数据，人工智能，智能制造，以及ERP，OA，HR等职能解决方案都有扩展对接的客户需求。美国知名的低代码应用平台Outsystems最主要的一块业务来源就是作为SAP这样大型ERP应用的延伸（SAP Extensions），而这些延伸集成工作大多数其实是有合作的ISV来完成的。

3）系统集成商

系统集成商（Sytem Integrator）一般而言不会有自己的产品和解决方案，他们理论上应该代表业主利益负责选择和集成各种软硬件产品，并完成必要的定制开发，最终交付给业主。但在市场实践中，有时候系统集成商和ISV难以分清界限，所以客户关系比较密切的系统集成商也有使用应用平台来交付项目的诉求。这其中的利益关系和价值创造过程和上文介绍的ISV类型是类似的。

4）咨询服务商

和传统IT产品市场略有不同，APaaS产品因为它的易用性，也能给非软件行业的咨询企业带来新的业务机会。

咨询企业依靠自己的领域知识和管理工具来服务客户，但是越来越多的管理方法论其实和数字化管理工具密切相关。脱离工具落地的咨询项目往往无法给客户带来实效，所以咨询行业长久以来都在寻求落地工具。甚至也有不少咨询企业过去花费过重金来打造一个软件工具，作为咨询服务的补充。但因为能力边界的存在，咨询企业往往无法搞定复杂的软件工程问题，难以提供有竞争力的软件方案和产品。

现在，管理方法可以直接通过零代码应用搭建的方式来实现，这意味着有一批咨询师可以将自己的想法和经验直接用软件来表达。他们当中很多都是来自垂直产业，非常清楚行业客户的实际痛点和最优的解决方案，他们搭建出来的应用往往非常务实，更容易得到行业客户的认可。

咨询商业模式本身也有难以复制，产能有限等缺陷，结合数字化工具交付后，咨询企业有机会获得连续的客户服务机会和连续的收入，也会大大提高毛利率。在和同类咨询业者的竞争中，有数字化落地工具的团队往往拥有高得多的客户胜率。

（3）服务提供者

除了现有的实体以外，当应用平台普及时，也一定会有新的角色加入市场。虽然无法预知最终的产业生态，但我们还是可以先概括地称之为服务提供者。

培训服务：为初学者到中高阶用户提供的教育内容和服务，尤其是帮助业务开发者掌握零代码应用平台使用能力的服务。

考试和认证服务：编写教材和考核题库，并给出第三方认证的服务。通过应用平台使用能力考核的员工将增加他们在职场的竞争砝码。培训和认证服务通常都是基于具体软件产品而展开的，最典型的微软Office相关的MSCP（微软认证专家）项目。

应用平台咨询服务：帮助客户最大程度利用应用平台潜能的咨询服务。服务提供者结合客户的实际行业和企业目标，帮助客户获得行业最佳实践，创造更有竞争力的用法，并协助落地的全过程。

应用开发商：当在某个应用平台的应用足够丰富的时候，平台方一定会建设一个应用交换中心，类似Salesforce所构建的APEX，在这个子平台上，开发者可以上传和推广自己的应用，现有的平台用户可以快速安装和试用，并最终决定是否购买。

这一章节作为本书的结束，勾勒了应用平台可能催化的行业结构变化。这只是一个行业预测，最终的市场结构还取决于应用平台市场内部竞争的结果。无论最终产业终局如何，上文所提到的客户和从业者工作内容的变化趋势是确定无疑的。软件行业会因为应用平台的出现大幅减少重复发明轮子的投入，产业整体效率也因此得到提高。不同角色的人和公司可以在这个变化的过程中，结合自己的愿景和资源，找到属于自己的定位。

我的近期文章

零代码简史

2020-08-22

谁该承担中国SaaS贫瘠生态的一点责任

2020-07-30

大家都在谈的数字化转型，到底指的是什么？

2020-07-11