ERP业务知识–14-业务理解比技术更重要

作者
Post Views: 33

从 ERP 开发者视角：业务理解比技术更重要

这篇文章面向有技术背景但 ERP 业务经验不足的开发者。技术不是问题，问题是：你写的代码在解决什么业务问题？

一、技术背景开发 ERP 的天然优势

作为有技术背景的开发者，你在以下方面有明显优势：
  • 数据库设计能力强
  • API 接口设计清晰
  • 状态机/流程引擎实现熟练
  • 并发控制、事务管理有经验
但这些优势只能帮你”把系统做出来”，不能帮你”把系统做好”。“做出来”和”做好”之间的差距，就是业务理解。

二、常见陷阱：技术视角 vs 业务视角

陷阱 1：把业务规则当代码逻辑

技术视角：
“采购订单创建时，从请购单带出数量和供应商，然后 insert 一条记录，完事。”
业务视角：
“采购订单创建时，不仅要从请购单带出数据，还要校验：
  1. 请购单是否已审核（待采购状态）
  2. 采购数量是否超过请购余量
  3. 供应商是否在合格供应商列表中
  4. 采购价格是否在有效期内
  5. 并发冲突处理
  6. 创建后自动更新请购单的’已采购数量'”

陷阱 2：忽视状态机的边界条件

技术视角：
“状态机就是 if-else，草稿可以审核，审核后可以执行。”
业务视角：
“状态机要考虑：
  1. 审核前可以取消，审核后不能取消
  2. 执行中如果下游单据已创建，能否关闭？
  3. 关闭后能否重新打开？（不能）
  4. 状态转换失败时，错误信息要具体到字段级
  5. 状态变更时要触发哪些后置动作？”

陷阱 3：以为”关联字段”就够了

技术视角：
“入库单关联检验单 ID，JOIN 一下就能查到上游信息。”
业务视角：
“关联字段只是外键，但业务上需要：
  1. 入库单详情页要展示完整的上下游穿透链
  2. 要支持按物料维度查询所有关联单据
  3. 要支持追溯路径的可视化展示
  4. 要避免多层 JOIN 的性能问题
  5. 要在上游单据被删除后仍能追踪”

三、如何快速建立业务理解

3.1 从用户故事出发

每张单据都要能回答：
  • 谁创建这张单据？（角色）
  • 在什么场景下创建？（业务上下文）
  • 创建时需要填写什么信息？（数据需求）
  • 创建后这张单据要做什么？（流程下一步）
  • 什么情况下这张单据会结束？（终结条件）

3.2 画出完整的业务流程图

不要只看单个模块，要看整条链路： 
生产订单(MO) → 生产计划单(MP) → 采购计划单(PP) → 请购单(PR) → 采购订单(PO)
                                                                         │
                                                                    供应商发货
                                                                         │
                                                                         ▼
                                                                   到货单(AN)
                                                                         │
                                                                  发货/拒收
                                                                         │
                                                                         ▼
                                                                   送检单(SI)
                                                                         │
                                                                         ▼
                                                                   检验单(QC)
                                                                  /         
                                                               合格         不合格
                                                                │            │
                                                                ▼            ▼
                                                             入库单(GRN)  不合格品单(DEF)
                                                                │            │
                                                                ▼            ▼
                                                             出库单(GI)   退货单(RTN)
在每个箭头上标注：
  • 触发动作是什么？
  • 数量如何传递？
  • 状态如何变化？
  • 哪些数据需要保留追溯？

3.3 用测试数据走一遍完整流程

用真实的业务场景测试一遍全流程： 
场景：生产 100 个产品 A，需要采购钢材 200kg

1. 创建生产订单 MO-001（产品 A，100个，BOM V2.0）
   → 系统 BOM 展开：钢材 200kg

2. 生成生产计划单 MP-001（钢材 200kg）
   → 审核通过

3. 生成采购计划单 PP-001（钢材 200kg）
   → 审核通过

4. 生成请购单 PR-001（钢材 200kg）
   → 审核通过

5. 生成采购订单 PO-001（钢材 200kg，供应商 ABC）
   → 审核通过

6. 供应商发货，创建到货单 AN-001（钢材 200kg）
   → 审核通过

7. 发起送检，创建送检单 SI-001（钢材 200kg）
   → 审核通过

8. 执行检验，创建检验单 QC-001
   → 检验结果：合格 180kg，不合格 20kg

9. 合格部分 → 创建入库单 GRN-001（钢材 180kg）
   → 审核通过，台账 +180kg

10. 不合格部分 → 创建不合格品单 DEF-001（钢材 20kg）
    → 选择"退回供应商"

11. 创建退货单 RTN-001（钢材 20kg）
    → 审核通过，采购订单未到货余量恢复 20kg

12. 闭环检查：
    - MO-001 → MP-001 → PP-001 → PR-001 → PO-001 → AN-001 → SI-001 → QC-001 → GRN-001
    - 数量守恒：200kg ≥ 200kg ≥ 200kg ≥ 200kg ≥ 180kg（合格入库）+ 20kg（退货）✅

四、开发 ERP 的核心思维转变

4.1 从”数据存储”到”流程管理”

传统 CRUD 应用关注数据怎么存、怎么查。ERP 关注的是：
  • 数据怎么产生（单据创建）
  • 数据怎么流转（状态变更）
  • 数据怎么关联（追溯链）
  • 数据怎么结束（单据关闭）

4.2 从”字段校验”到”规则引擎”

普通应用的校验：非空、格式、长度。
ERP 的校验：业务规则、数量约束、权限控制、状态限制。

4.3 从”单表操作”到”事务一致性”

ERP 的每张单据操作往往涉及多张表、多个模块的联动：
  • 入库单审核 → 更新台账 + 写入流水 + 更新上游单据余量
  • 生产订单审核 → BOM 展开 + 锁定库存 + 记录审计日志
所有操作必须在同一个事务中完成，任何一方失败都要回滚。

五、给开发者的建议

  1. 先理解”为什么”，再考虑”怎么做”

    每个业务规则背后都有业务原因。理解了原因，代码才能写对。
  2. 多看测试数据，多走业务流程

    不要只盯着代码，要去系统里实际操作一遍，感受业务流程。
  3. 关注边界条件

    ERP 的复杂度不在于正常流程，而在于边界情况：部分退货、超量容差、并发冲突、状态断裂。
  4. 画流程图，不要只写伪代码

    业务流程用流程图表达比文字清晰得多。每张单据的状态机图、数据流转图都要画出来。
  5. 和业务人员多沟通

    代码能解决技术问题，但解决不了”这个业务规则到底为什么要这样”。多问为什么。

六、小结

技术能力是基础，但业务理解才是上限。ERP 的本质是用系统化的方式管理业务流程，而不是简单地增删改查。当你理解了”为什么要有这张单据”、”为什么要有这个状态”、”为什么要有这个约束”，你写的代码才会有灵魂。 下一篇：总结篇——一期 ERP 系统的全局认知。
这是「ERP 业务知识系列」第 14 篇，系列共 15 篇。

发表评论