这句话听起来很有道理。在企业数字化建设中，我们经常看到这样的现象：业务没有定义清楚的问题，留给产品经理解决；产品没有定义清楚的问题，留给研发或实施解决；系统没有承载好的问题，留给业务人员通过人工操作、沟通和协调来解决。
复杂度并没有因为我们不处理它而消失，只是转移到了其他环节。
但如果继续往下推，就会发现一个问题：复杂度真的守恒吗？
如果业务世界本身就很复杂，我们是否只能暗戳戳希望复杂度不由自己处理？还是说，通过改变系统的组织方式，我们可以真正降低整个系统的复杂度？
一、业务世界本来就是复杂的
先看两个实际业务场景。
### 调整一次生产排期
一家制造企业的生产计划人员，正在用 Excel 调整几个订单的生产优先级。他需要综合考虑客户的重要程度、合同交期和延期责任，关键物料是否齐套、采购进度和供应商承诺交期，以及当前生产进度、设备与人员的可用产能。
这些因素还会相互影响。一个订单物料延期，可能释放部分产能，但能否转给其他订单，还取决于后者的物料齐套情况和工艺要求。优先保障某个客户，又可能造成其他客户延期。
计划人员虽然只是在调整 Excel 里的几行数据，实际上却是在一组相互依赖的事实、资源、规则和目标之间寻找可行方案。
### 采购一台医疗设备
在医院的信息系统中，设备采购可能表现为一张申请表，以及一连串审批节点。申请人填写设备名称、数量、预算和采购理由，相关部门依次审批。
但一张申请单背后，究竟需要完成多少判断？
首先是采购必要性：为什么需要这台设备？是新增诊疗能力，还是替换老旧设备？现有设备的使用情况如何？继续维修是否更划算？
接下来是临床和技术论证。设备需要满足哪些诊疗需求？不同技术路线有什么差异？关键性能指标如何确定？
还要考虑经济性：除了采购价格，设备全生命周期的耗材、维保和人员成本是多少？预算从哪里来？预期效益如何？场地、供电、信息系统和人员是否具备实施条件？
完成需求和可行性论证，才进入具体采购环节。还需要开展市场调研、制定技术要求、进行产品比选、评审和合同谈判，最后完成验收与交付。
这些环节相互依赖：临床需求决定技术要求，技术要求影响供应商范围，预算约束配置方案，实施条件又可能反过来影响设备选型。
表面上是一张采购申请单，实际上是一连串涉及临床、技术、经济、资源与合规约束的决策。
两个场景虽然不同，却有一个共同点：真实业务本来就包含大量对象、关系、状态、规则、资源和目标。局部决策往往需要综合多个维度的信息，并考虑它对其他业务活动的影响。
业务的复杂度，不取决于我们有没有把它写下来，也不取决于现在看起来有几张表单。不建模，不代表复杂度不存在。
二、不在上游处理，复杂度就会转移到下游
如果企业没有清晰维护订单、物料需求、采购进度和生产任务之间的关系，计划人员就需要查询多张 Excel、询问相关负责人，再凭经验整理出当前的真实情况。
医疗设备采购也是如此。如果前期需求没有充分定义和表达，各环节的审批人员就缺乏必要信息，整个流程可能漫长而反复；如果设备配置、预算和技术要求之间缺少稳定关系，每次修改都可能需要重新整理材料、解释背景。
原本可以在上游明确的事实、关系和规则，变成了下游反复进行的判断、沟通与协调。
企业软件中有两种特别常见的复杂度转移方式。
第一种是自定义配置。
字段、表单、流程和权限都可以自定义，但哪些业务事项需要独立对象，哪些只是状态变化，对象之间如何关联？配置工具不会自动回答这些问题。如果产品没有建立稳定的业务模型，实施人员就必须根据每个客户的需求重新判断。
产品没有完成的业务建模，被转移给了实施人员。 这也是《系统实施为什么变成了配置地狱》讨论的问题。
第二种是增加审批。
企业需要管理订单变更，就增加一张变更申请单；需要知会相关部门，就增加抄送节点；担心遗漏责任人，就再增加审批人。
但审批通过究竟改变了哪个业务对象的状态？哪些后续任务受到影响？谁需要决策，谁需要执行，谁只需要知情？
如果系统没有定义这些关系，每个人收到表单，都需要自己判断它与其他业务事项是什么关系，以及究竟要不要现在点击那个“同意”。
审批流转并不等于业务状态管理。系统没有承载好的对象状态、规则和权责关系，被转移成了人的判断与操作。
更根本的问题是：谁负责定义这些业务结构？
在《传统企业数字化里的隐形断层：谁来定义业务如何进入数字世界？》中，我讨论过这个长期存在的职能缺口。业务方熟悉现实，却未必能够将其抽象为稳定的数字模型；软件方擅长实现需求，却通常不负责持续定义企业的整体业务世界。
当这项工作无人承担，复杂度就会在业务、产品、实施和日常执行之间不断传递。
三、复杂度不仅会转移，还可能被复制和放大
如果一项业务规则没有被统一定义，多个部门就可能各自维护一遍。同一个订单在不同环节的状态，如果缺少可靠来源，采购、生产和销售就需要分别确认。不同系统对同一业务对象采用不同的定义，又需要额外的数据转换和协调。
业务发生变更时，这些分散的定义还需要同步修改。一处遗漏，就可能引发新的不一致和返工。
这里实际上发生了三种变化：
- 复杂度转移：上游未完成的定义与判断，被留给下游。
- 复杂度复制：同一项事实、规则或关系，被多个环节重复处理。
- 复杂度放大：重复定义造成的不一致和额外依赖，又引入新的协调成本。
因此，我们实际需要处理的复杂度，并不完全来自业务本身，还有一部分是由系统组织方式引入的。
局部系统看起来简单，不意味着整体复杂度低。 当我们只衡量单个产品或环节的效率，就容易忽略那些被转移出去、甚至额外产生的工作。
四、复杂度真的守恒吗？
“复杂度不会消失，只会转移”，其实隐含了一个前提：系统的整体结构不可改变。
如果结构固定，局部减少的工作确实可能转移到其他环节。但如果允许重新设计系统，结果就不同了。
事实上，优秀的产品经理和架构师一直在做这样的工作：识别重复的业务概念，重新划分对象边界，抽象共性能力，减少模块耦合，让规则与能力能够跨场景复用。
从复杂度的角度看，这些工作的本质，就是通过改变系统结构，减少整个系统需要处理的不必要复杂度。
例如，多个应用原本分别维护同一套业务规则。将规则前置为公共模型后，虽然增加了一次建模投入，却可能减少多个应用的重复配置、校验和后续变更。
更进一步，上游一个对象边界的调整、一条规则的明确，可能同时消除下游多个流程中的判断分支、配置项和异常处理。理论上，一处建模的改进，就可能带来一大片下游复杂度的下降。
这也是优秀产品设计和架构设计的重要价值，只是过去不容易衡量。
我们习惯统计开发了多少功能、提高了多少效率，却很难计算：因为前面做对了一项设计，后面有多少配置、沟通和返工从未发生。
而这些没有发生的工作，恰恰可能构成系统架构的重要收益。
因此，复杂度并不必然守恒。评价设计的好坏，也不能只看局部减少了多少工作，而要比较整个系统的建设、运行和演进成本。
环境建设可能增加前期投入，却减少后续多个任务中的重复定义、判断和协调。要评价它是否划算，需要观察足够长的时间、足够完整的业务范围，而不是只比较某一次任务的成本。
五、让复杂度在上游逐步收敛
仍然以制造企业为例。
客户要求提前某个订单的交付时间。传统的处理方式可能是销售发起变更审批，生产计划人员查看排期，采购人员核对物料进度，各部门再通过表单和消息反复确认影响范围。
但如果在上游已经明确了合同交付项、交付批次、物料需求、采购任务和生产任务之间的关系，并建立了相应的状态与规则，那么一次交期变更就可以直接关联到受影响的业务对象。
系统可以根据这些关系找到需要重新评估的采购与生产任务，计算能够确定的约束，向相应责任人发起任务或通知。人仍然需要处理交期冲突、资源取舍等真正的决策，但不必每次都从头查找对象、恢复关系、判断谁应该参与。
上游增加了一次结构化建模，下游却可能消除大量重复的信息收集、关系判断和协调工作。
这不是简单地把工作提前完成，而是让一部分工作不再需要重复发生。
我在《业务建模，本质是定义业务如何被表征》中，将建模理解为一种有目的的压缩。而要让这种压缩的收益真正传递到系统运行，还需要将业务要求、产品能力和技术实现建立明确联系，这正是《从业务、产品到代码，三张可互算架构图》讨论的方法。
当这些结构可以被持续复用，新增业务场景和应用时，也不必重新定义整个业务世界。
不建模，是让复杂度在下游反复生成；好的建模，是让复杂度在上游逐步收敛。
好的系统设计，不是把复杂度藏起来或转移给别人，而是通过改变系统结构，减少整个系统需要处理的不必要复杂度。