在数字化领域，能够低代码化、实现”软件批量生产“的场景是有一定前提条件的。判断识别某个业务场景是否适合低代码，以及是否具备低代码化的条件，显得尤为重要。
上一节谈到，软件有自己的特殊性。一方面体现在面对不同客户需求所表现的个性化差异，同时，软件作为虚拟商品，较难像实体行业那样实现各类标准定义，这些对于低代码所主张的”软件工业化“批量生产的愿景构成了很大的挑战。
事实上，工业化发展至今，还是会有相当比例的产品不能也不适合实现"工业化"生产的，同理，在数字化领域，在未来能够低代码化、实现”软件批量生产“的场景也是有一定前提条件的。所以，判断识别某个业务场景是否适合低代码，以及是否具备低代码化的条件，显得尤为重要。
判定一个业务场景低代码化是否成立，主要看两个方面：业务场景是否适合低代码与企业组织是否适合低代码。
业务场景的重复度
经过长期观察实践以及大量样本对比，我们认为判断一个业务领域是否适合低代码，需要具备的关键前提是：这个业务场景的业务问题的总体重复度大于某个阈值。
所谓业务问题的总体重复度，指的是从较长的时间来看，该领域的问题出现重复的总体概率是否收敛在某个范围。在企业内部，我们以营销活动举例，从阿里巴巴历次促销活动来看，大部分的货架类营销页面都可以由特定的模块构成，这包括了标题栏、头图、Banner位、跑马灯、Tabs、各类奖券、商品列表、主播列表等。比如在中后台系统场景，大部分的中后台系统页面都可以通过使用导航栏、面包屑、工具条、Tabs、各类表单、表格、分页栏、步骤条、对话框等构成；后台业务逻辑同样满足这样的分布，大部分的业务场景都是围绕着有限的几类领域模型展开的，以电商举例，商品、类目、店铺、用户、订单、交易、权益等主要业务对象涵盖了大部分的应用场景。
重复度超过70%才有意义
业务场景具备一定的重复特征是实现低代码的基础，我们实践发现，这个总体重复度超过70%，才具备真正意义低代码化的可行性。
好消息是，根据统计，**对于绝大多数长期迭代、业务模式相对成熟的领域，总体上是符合82原则的，即当一个需求事件（问题）发生，历史上出现过类似问题（重复）的概率大约在80%左右，或者说，真正称得上新问题的概率在20%左右。**所以，即使全新的业务，只要历经了一段时间的探索积累，大部分业务还是符合这个总体重复度，从而适合使用低代码的。
这一点是低代码适合某类业务场景商业化决策的重要判定依据，以目前行业中出现的氚云、轻流等平台为例，这些公司也是选择那些具备总体业务重复度高的应用场景，例如销售管理、采购、库存、社区防疫、行政管理、财务报销等领域，通过表单加流程等建模方式让用户快速定制功能。
这里提到的“总体重复度超过某个阈值”，同时意味着经过低代码化改造后，作为指标之一的“物料复用率”也要达到这个阈值，即在实现上文中提到的“组装式生产”的过程中，能够真正提升影响效能的关键要素之一“可复用比例”。
“物料复用率”是一个非常重要的衡量指标，需要引起注意的是，现阶段的很多低代码系统对这个指标的重视程度不够，尤其是一些面向业务侧的无代码系统，为了实现简单易用、提升用户体验，以降低复用率作为代价，这样的低代码方案对于总体效能提升会大打折扣。事实上，物料复用率与用户体验是可以兼顾的，关于这方面的论述，我们将在后面的章节中展开。
接下来，我们从组织结构出发判断是否具备推广低代码的可行性。
判断一个业务领域是否适合低代码，另一个关键前提是：企业（或团队）组织能够接受低代码带来的新型生产关系。
企业（或团队）组织能够接受低代码带来的新型生产关系，指的是组织能够接受低代码带来新的生产协作方式的转变。低代码所带来的不仅是生产力的提升，在很多情况下会要求组织对既有的生产协作流程、角色分工做出一定改变的。
软件研发中传统的生产关系
还是举电商公司的例子，此前，营销活动的工作开展流程是这样的，负责市场的业务方制定活动的目标、给出活动的主题基调、策略方针等，接下来，产品团队开始跟进，将业务的目标、理念、政策等转化为具体的产品设计，接下来，设计师（用户体验与视觉交互设计等）团队将产品的原型转化为具体的设计稿件，然后，研发团队参与进来，前端、移动端、服务端、测试、数据、安全、运维等完成各自的工作，这中间存在大量的协同工作，大家共同参加各种会议、评审、排期、开发、提交测试、走查、修改等等各个环节不断迭代，最终项目上线。
这时的协作流程可以用下图表示：
企业内部常见的“接力赛” 式的生产协作过程
这种协作方式体现的特点是，大部分项目需要各角色参与、深度协作完成，只有一小部分比例能够由业务方或者业务方加一小部分研发轻度协作完成。
前台与后台的协作过程，只有小部分工作轻度协作完成
引入低代码后的生产关系
引入低代码生产模式之后，这个协作流程发生了简化。回顾前文中提到的“组装式生产”，业务方指定目标与规则之后，产品团队或者提出需求的业务方直接使用低代码系统工具组装产品，在遇到新的物料时再向其他参与方提需求，新的物料准备完成后再回到低代码产品“装配车间”完成组装，最终通过总体测试完成产品的发布上线。
此前，业务产品与设计师、研发工程师更多像是需求任务的发包方与承包方的协同关系，在这种生产模式下，业务与产品自己同时是承包方的主力，“让有想法的人自己实现”是低代码重新定义生产关系的最大特点。在这种“圆桌式”的新型生产关系下，业务方、产品经理、设计师、研发工程师、测试人员等多个角色不再是此前串行化、接力赛式的生产模式，而是围绕最终产品展开即使协作的，在生产过程中随时互动。
新的协作过程如下图所示：
采用低代码后的生产协作过程
大部分的生产过程仅由前台与中台轻量化协作即可完成，少部分由前台、中台、后台深度协作完成，参与角色减少、在中台层面可复用的内容增加，从而达到提升效率、减低成本的目的。
前台与后台的协作过程，大部分工作轻度协作完成
这个协作过程更接近近些年所提倡的“中台”理想：类似特种兵作战的方式，业务与产品作为领域专家作为冲在一线的特种部队，使用各种低代码生产力套件，与提供远程火力与能力支援的设计师、工程师、分析师等即时协作，高效完成任务。
基于低代码的新型生产关系看起来似乎更高效，但是在实际推广的时候也是要视情况而定的。概括来讲包括几个方面：
不适合低代码的情况
现有的生产模式可能更合适实际情况
低代码并非银弹，组织不能为了低代码而低代码，工厂并非在所有情况下都比手工作坊高效。低代码适合那些具备一定规模、有了一定分工、在生产过程中遇到了效能问题的企业组织。
降本增效可能是伪命题
事实上，并不是所有的企业或组织真的需要降本增效，**在没有紧迫的业绩压力、资源充足的情况下，效能提升可能不是组织所迫切需要的。**在前些年互联网资金充裕、人才稀缺的情况下，很多企业在某些生产环节不仅不考虑降低成本，而是要保留一定的资源冗余度以应对业务的快速扩张。
推广成本可能无法接收
低代码所带来不可避免的生产关系优化，这对于企业组织是一个较大的挑战。
我们在前文中提到，一般而言，低代码工具是需要一定的学习成本的。相关团队是否愿意了解学习会是一个问题，事实上，作者见过很多低代码研发团队失败的例子，一味“讨好”业务方用户，为了做到无代码的简单易用，以降低物料复用率作为代价，效能提升效果一般，同时，对于一些复杂的业务场景又无法用无代码的方式解决。
低代码的生产模式会对现有团队带来较大的冲击，**在实施过程中，一些角色不可避免的会被边缘化甚至取代。**例如部分前端开发工程师、移动端开发工程师、后端业务工程师、测试工程师、部分设计师等，在实施过程中，这些成员往往也是反对声音比较大的。所以，这部分成员需要寻找“转型”之路，一个自然的转变是由原来的业务开发转型为物料研发、工具研发或工具实施，从而成为低代码生产模式下的“合作方”、成为新的生产关系的组成部分。
此外，**新的生产模式的收益呈现可能需要一段时间，在开展前期，因为各方磨合，可能会出现总体先“降效”的情况，这种情况下决策者是否有足够的信心以及战略定力也会是个挑战。**在实施过程中，细节流程机制的随时调整也是非常有必要的，事实上，适合组织的低代码生产方式很难有标准答案可以直接照搬的，同一套协作过程不一定适合另一个团队，采用哪些低代码套件、具体的协作流程，往往是需要组织自己持续打磨演化的。从某种角度来讲，低代码的生产方式更像是精益生产，通过建立一套自动化的产线、通过需求拉动的方式随时演化调优。
综上所述，判断某类业务场景是否适合低代码，以及在企业组织中能否推行低代码化，需要从多个方面进行考察论证，关于这方面的进一步论述，我们将在后文中详细展开。
--------------------------------------------------------------------------------------------
感谢阅读，下一篇文章，我们探讨低代码的本质部分。
欢迎访问免费、通用的无代码开发平台Mybricks ，体验图形化编程的乐趣
