0代码定制和低代码定制是最近2B软件行业的热门词汇，网上的文章和各种说法也很多，究竟能不能大规模定制？如果能，如何大规模定制并产生商业价值，这是每一家所谓的平台化软件企业必须回答的问题。

本文试图去求解这一难题，给出体系化的方法和思路，兼与陈飔老师隔空讨论，也希望对于我们的销售、售前和实施提供一些指引，对于研发人员和产品经理提供一些关于未来的思考的输入。

开篇：大规模与定制的矛盾

协同管理软件的目的在于提升组织管理与协作的效率，成就高绩效组织，其方法论支撑在于战略与执行的协同、职能部门与业务单元的协同、业务单元之间的连接与协作等等，其本质在于将组织作为有机体进行数字化，成为组织的基础信息化设施，让人与人、人与组织系统起来，从而使得组织中人的集合比单个个体能够创造更大的价值。

这个看是老生常谈却是初心与本义，回归到组织信息化本身在新的阶段需要完成组织的数字化转型，而不仅仅是一个业务模块的信息化，所以连接集成、整合信息孤岛，实现业务协作和工作任务的过程信息化就成为组织数字化的根本。

这里需要特别强调一下所谓的ERP软件特别是其关键部分的财务软件，其本质在于对组织的绩效进行测量，从而获得组织的生产力、效率和利润等经济指标信息，为企业战略服务，而没有聚焦于工作任务、工作目标如何开展本身。

企业如何展开工作？计划、组织、协调、控制这种适合于业务层组织管理的方法和体系是否可以信息化，是否每一个企业都非常独特? 以至于信息化、数字化的成本高企，价值却并不那么明显？

当然。这是组织数字化转型升级的根本出路，企业通过数字化实现转型升级可以大幅度提升工作效率和工作质量，有效控制企业由于生产效率低下、客户响应速度慢、对于技术和环境不敏感等诸多问题，回归本质就是如何提升工作质量和工作效率的问题。

从企业应用聚焦效率、质量和时间的视角来看，实现高价值的数字化转型的关键在于基于企业转型升级的主题任务的信息化、自动化从而带来大幅度的工作效率和质量的提升，这是信息化、数字化定义的点，是可行的。

规模在于企业信息化、数字化的基础变量是否一致度高，如果一致度高，就可以抽取产品实现规模化的软件作品的生产，并通过商业交换实现规模经济。

但企业是独特的，企业存在的理由恰恰是企业的独特性，也就是差异化u的能力，无论是产品还是服务。

这是企业信息化需要驾驭的悖论，要么定制、要么规模，规模+定制还没成功的先例。

技术先进与制造的落后-软件行业

软件行业从来给人感觉都是高科技行业，但相对于制造业，我们并没有实现大规模的制造业分工，所以软件行业是一个农业时代的手工艺生产模型，这就是coding从0开始写功能的结构性的偏差。

实际上，如何实现制造和交付的分离，实现制造和服务的分离，以及运维保障的分离，这是软件行业要从产业发展的视角去改变的问题，这不仅仅是一个简单的所谓商业模式就能解决的问题，是产业结构的问题。

当然，it产业本身还是有大分工的，比如网络环境提供了信息传输与送达的基础能力，操作系统提供了隔离计算机硬件差异的运行环境，背后是图灵机和冯.诺依曼体系结构的机制与分工的产业体系。这些年互联网的发展带来了计算机之间联网协作的机会，为信息连接、融合、协同工作带来了基础的机制和机会，而移动互联网连接了人和系统，成为真正的人与互联网的入口门户和交互界面，这是根本性的基础准备。

就信息化价值来看，2C软件行业的最终目的在于交易，其变量只有产品和价格，连接的是组织与人或者人与人，其结构当然比2B简单，所以电商系统（如果我们也叫软件的话）先行了一步，也提供了方法论的支撑。

是的，管理软件的生产方式是基于操作系统、基于互联网的连接结构和移动多端特性构建起来的（这里仅仅是描述，并不严谨哈），但生产过程却是从最基本的语言、数据等最基本的微粒开始组织和功能编码的，这种方式比原始人的农耕没有本质区别，而其使用的工具都是在最基础的级别提供编写和调试，实际上数十年来计算机语言的进步似乎一直是在适应互联网的能力扩展中挣扎，而没有针对现代的复杂的企业应用增长出新的语言或者开发模式出来。

这是现代与古老的结合，这是高科技与手工作坊的组合，显然不能符合未来大规模应用的诉求，所以软件工程师们就996拼苦力，成为了新一代的“搬砖工人”，这是不符合现代化大规模生产的。

有需求，就有动力，世界在进步，软件特别是企业管理软件的生产方式应该改变，也必须改变。

从走出软件作坊到规模化开发：依然是产品

《走出软件作坊》是我的一位朋友阿朱的一本在业内比较有名的开发管理的书籍，如何提升开发效率和开发质量，如何让我们不再那么靠“工匠精神”而是现代化的团队作战，作者从体系化的方法论提出了很多办法。

但这依然不是结构化的改变，作者更多地都是如何通过改善过程做出更高质量、更符合客户需求的产品，就像陈飔老师所言：产品化是规模化的前提。

但是否有另外一种思路，我们帮助客户的信息化基础设施建设，如果一定要说这种能力是什么的话，就是帮助客户的组织本身实现数字化，流程、制度作为生产线的设施可以随意拿来组装流水线，这就有可能实现规模化，这是基础设施，也是工具。

一句话，我们帮助客户实现信息化的基础设施，以实现客户自建生产流水线的能力实现建立“管理的流水线”、“管理的任务协作系统”、“管理的业务看板”等等这些从生产设施到管理设施的信息化！

如果给客户以鱼到客户以渔都不足够，通过数字化、自动化、信息组件和业务功能组件的提供，使得客户可以自己创新出自己的“渔”，将it技术、编程技术、调试技术、工程技术隐藏在复杂的平台体系之中，提供给客户聚焦组织管理、聚焦业务协作、聚焦战略管理的信息化基础设施，这也许就可以实现平台化的支撑。

这种不是走出软件作坊，而是重构软件的产业链，作为协同管理软件厂商的梦想在于实现建设企业的基础设施的能力，让企业可以自行组装自己的信息化生产线，实现组织管理信息化的自我DIY，这是一种终极目的，如果要折中的话，这些能力可以由专业分工的组织管理、业务管理的专业厂商来提供，但这些厂商不需要对于图灵、对于冯.诺依曼以及背后的架构熟悉，从而实现大范围的专业化分工，这就是协同软件—中台的定义的力量。（这里仅仅是场景描述，不是严密论证）

组件化与标准件的定制机制：这才是架构

制造工业生产如何做？首先需要建立生产线，通过装备、工艺和工装解决生产流程建设问题，而大规模定制软件开发首先就需要解决“生产线”的设施问题，如果没有流水线，就不会有现代化大工业，也就是制造业的繁荣。

对于软件行业，我们的生产线仅仅有开发语言、运行容器（通常被称为中间件比如tomcat），改变一下，生产线不是开发的语言工具，而是搭建工具呢？

还有一个改变，软件作为产品就像汽车一样，不能从练钢铁、生产塑料开始，而应该通过部件组装进行，这里就需要各种各样的部件就像汽车行业的总成，实际上现代汽车的整车厂生产已经不是福特T型车年代，而是部件组装，并且可以实现柔性化生产，虽然还有诸多不足。

对应于软件行业的开发来说，所有的功能不能仅仅通过一行行代码堆砌，虽然我们已经有很多语言开发级的函数库、对象库和组件库，但这些都是通用的计算函数、技术组件类，而不是像汽车一样的底盘、发动机，这种组件和构件的开发需要汽车模块化的设计、生产，已经成为现代汽车生产的主流方式。

而软件开发也可以这么做，通过模块、组件化开发，而背后应该有面向领域、行业和组织级客户的基础平台，比如底盘、总线结构等等，对于企业管理软件来说，就必须要有比如组织模型的基础架构支撑，工作流、表单等基础部件的结构，以及门户首页、工作空间等对于现实场景的线上表达或称称之为入口，这些整体的系统化的模式、方法，就是应用架构和体系化能力。

对于机械工业，大家知道标准件吗？实际上就是螺钉螺母，各种连接件，这些都是按“千克”销售的，成为组装系统的必须。

对于软件开发来说，前后端分离，让空间、交互就像我们汽车的装饰，住宅装修一样，形成不同的风格和交互，并通过前端组件进行拼接，就会形成更好的交互体验，并且可以兼顾多端系统，比如手机、平板和PC交互。

如果能够达成这样的效果，大规模定制就会因为“生产线”+组件的模式而大幅度提升效率，这虽然与陈飔老师所谓的配置有相似性，但本质上每一个组件都是可替换的，而基础架构又是能够支持组织数字化的基础搭建的，从而会大幅度提升生产效率，提升客户交付的效率和质量。

并且，这里软件开发工程师主要生产并创造流水线结构，形成“现场定制”的组件、模块和工艺结构，以支撑到快速交付，并隐去了技术的细节，使得对于设计产品的人以产品需求导向，以业务模组成为组装原材料，从而避免了代码编程。

当然，这里会有一个问题，有些组件不适用怎么办？这就需要对于组件进行重构，形成新的型号或者新的版本，从而实现组件的互换，这也是现代化机械制造生产的一种场用方法，比如替换电阻、电容一样地替换一个前端界面组件，从而实现相似而又不同特性的功能。

共生与互联：信息、协议和组合

致远CAP4正是这样一种结构的探索，并取得了实际的效果，在前进的道路上迈进了一大步，目前基于CAP4的大量的组件已经能够提交到协同云上，通过云端定制实现多人协作的业务包产品开发，这是一种初步的模型，还有很多不完善，但已经走出了模式创新，实现了设计流水线和产品生产者的分离，实现了专业化应用的开发不完全依赖于代码编程的新的业务软件的生成模式，实现了专业化的分工的雏形。

更进一步，多个业务软件包之间如何连接、组合形成更大的业务包，更复杂的业务应用组合，这种堆叠式的开发模型也是现代复杂产品生产的一种有效模式，能够实现规模的模块的重用。

这里的软件模块成为了业务包，而业务包本身正是基于组织模型、工作流、业务表单、门户空间等等架构技术实现的技术模型支撑的。

大规模定制的基本方式是复用，现代企业管理的复杂性决定了整体复用有其困难和障碍，但企业管理本身是人的管理，只要人性不变，那么管理模式其实本质上很难改变，也就是由相似的业务、相似的过程、相似的任务和业务模块组合而成，而人与机器或者说软件系统打交道的方式和交互体验也是有限的模式可以探索的，通过模块化抽象、并基于对组织、流程、业务协作模型的研究，形成标准件、组件、模块、总成的结构，这些是可以期待的，并且随着各种组件的丰富，软件的搭建或者说生产将会变得越来越快捷，随着从业人员的增多，对于这些知识、框架和模型的了解和学习越来越深入，各种类型的专业软件的搭建都将成为可能，对此我们深信不疑。

这些这种目的，我们需要的是生态，也就是更多懂得业务、领域应用，对于管理创新和业务协作有思想、有认知的企业，有志于从事这些业务的实施人员、伙伴愿意投入资源从事这种生产性的活动，基于平台去搭建系统，形成丰富多彩的应用和应用组合，那么生态的活跃会反哺系统平台的能力提升，并整合各种组件、资源和信息互动的平台化能力提升。

并且，不同的业务模块、业务软件之间如何信息互通，如何连接协作需要信息互换的协议，需要业务软件（其实就是业务包）之间相互识别，相互通信，相互自动协作，这需要：协议的定义，这是更高层面的自适应、自动化的有机组合，也可以称之为智能化连接，这是未来发展的趋势和方向。

未来：软件不是应该是这样开发的

致远互联在CAP上的探索已经明确了大量定制的可行性，我们大量的实施人员和伙伴制作出来的数千个（也许更多）业务包已经运行在CAP的运行器上，CAP分离了设计器和运行器，就是将流水线的设计能力提交给了我们的伙伴和客户，而软件产品的业务包形成了各类客户的按需定制的业务信息化实现，成就了高绩效组织。

另外一方面，设计器生产的业务包在最先的生产环境中已经实现了业务包的版本迭代开发和修改的模式，这就使得软件产品是可以不依赖代码开发人员而进化的。

这不是未来的模式，这是今天已经实现的模式。对于有些特殊的功能、组件还需要重新开发组件，或者增加组件，这种低代码的开发在一个相当长的阶段还会持续，但这同时会造就更多的业务组件、前端组件、界面组件，封装出来就会成为未来可用的部件，从而降低未来的开发代价，成为可复用的资产。

当然，这些还不足够，平台、体系的能力还需要增强，对于组织、流程的组合，对于人员、组织的描述能力，对于多端的识别，对于业务模块组装的限制等等，问题依然不少。

平台化、生态化开发需要更大的产业分工，需要现代的实施交付人员和伙伴成为未来的生产线的设计师、师傅，成为制作以0代码定制业务的先行者。

这也需要新的观念，新的开发模式，也需要更多的组件开发者提供更多的标准件、组件和模块总成，这些也许需要代码，需要编程。

但这就像最初的汽车只有黑色，没有空调，没有挡风玻璃一样，虽然简陋，但毕竟上路了。

只要走在正确的路上，目标方向正确，经过前仆后继的众多参与者的努力，未来一定会越来越好。

这就是致远业务定制兼顾规模的定制模式，我们坚定不移地往前，往前，再往前。