判断一个自研ERP项目会不会烂尾不需要看代码只需要问三个问题业务边界有没有人签字数据口径是谁说了算应用模块之间的集成契约长什么样问完这三个问题基本就知道结局了。我见过太多团队一腔热血冲进自研ERP的战场技术栈很现代微服务、云原生、低代码全上了结果半年之后数据对不上、流程接不上、成本核算怎么都跑不平。问题不出在开发而出在架构层面缺乏一套总控机制。说得重一点很多自研ERP项目不是被写代码写死的而是被没有架构约束的“自由发挥”拖死的。这篇文章想跟你聊的是基于TOGAF 4A架构来构建ERP自研方法论。TOGAFThe Open Group Architecture Framework是全球应用最广的企业架构框架4A即业务架构BA、数据架构DA、应用架构AA、技术架构TA四条主线。这套方法论解决的核心问题是怎么让ERP自研从“拍脑袋建表、凭感觉写接口”变成“有蓝图、有边界、有契约、有治理”的工程体系。适合企业架构师、IT信息化负责人、资深开发管理者以及正准备立项自研ERP的决策者参考。1. 自研ERP死因解剖不是研发力不行而是没有架构总控先泼一盆冷水。很多团队立项自研ERP时立项报告写得天花乱坠但真正拆解下来失败原因高度相似。我把过去几年的观察总结成四个“死因”每个都能在4A架构里找到对应的失控点。1.1 需求蔓延业务架构缺位的必然结果自研ERP最容易犯的第一个错误是把业务需求当成“需求清单”而不是“业务架构设计”。业务部门今天说要加一个字段明天说要加一张报表后天说审批流要改一下开发团队来者不拒半年之后系统里堆了几百张表、上千个接口没人说得清楚哪张表是主数据、哪个字段是权威口径。这不是需求管理的问题而是业务架构缺位。没有从顶层把业务域、业务流程、业务对象梳理清楚需求的“蔓延”就是必然的。每一笔新增需求都是在没有边界的地基上加砖地基不稳楼越高塌得越快。1.2 数据跑不通数据架构没人在意“成本ERP数据没有跑通”这个词条能上热搜说明这是一个普遍到不能再普遍的痛点。我调过很多ERP项目的成本核算模块报表出不来、成本分摊不对、财务和业务对不上追溯到最后往往不是开发代码写得有问题而是主数据不统一、数据血缘混乱、计算口径各说各话。物料编码在一个模块里是A-001在另一个模块里是B_001BOM版本没有统一管理成本中心和利润中心的映射关系只在Excel里有一份。这些问题的本质是项目从头到尾都没有做过数据架构设计没有定义数据标准、数据Owner、数据分布和数据流转规则。1.3 模块边界模糊应用架构没有契约自研ERP和买套装软件最大的不同在于你需要自己定义应用边界。采购模块要不要管质检质检的结果怎么传给库存库存的可用量是按订单锁定还是按仓库实时扣减这些都不是开发能拍板的问题而是应用架构层面的集成契约问题。没有应用架构开发就会“就近实现”能查表绝不调接口能在本地冗余一份数据绝不走服务调用。短期看开发速度快了长期看系统耦合度失控改一个模块崩三个模块运维成本呈指数上升。1.4 技术栈割裂技术架构没有治理很多自研ERP最终死在了“技术栈自由”上。订单组用Java库存组用Python报表组用Node.js数据库一会儿MySQL一会儿PostgreSQLKafka用了但没有人负责Topic规范。这种混乱带来的后果不是单点性能问题而是整体协作效率崩塌以及后续没人敢接手维护的“遗产代码”。这四个死因放在一起看逻辑很清楚自研ERP缺的不是代码缺的是一套从业务到技术的完整架构设计体系。TOGAF 4A架构方法论的价值恰好是把这四个层面的设计工作变成一张可以执行、可以评审、可以治理的工程路线图。2. 4A架构在ERP里的“四张蓝图”业务、数据、应用、技术分别画什么理解了“为什么死”之后接下来要回答“怎么建”。4A架构不是四个抽屉各做各的而是一条贯穿始终的主线业务架构提出业务问题数据架构回答数据如何组织应用架构决定由谁处理技术架构解决用什么承载。2.1 一条主线串联四层架构拿最常见的销售订单流程举例业务架构层面定义从线索、报价、订单、发货、开票到回款的端到端流程明确每个环节的输入、输出、角色和业务规则。数据架构层面识别“订单”这个核心业务对象有哪些属性订单号、客户、产品、数量、单价、交期、状态等定义订单数据在整个生命周期里如何创建、更新、归档。应用架构层面决定订单功能模块属于哪一个应用服务订单服务与库存服务、客户服务、财务服务之间用什么接口交互。技术架构层面确定订单服务部署在什么基础设施上采用什么开发框架数据库怎么分库分表与其他服务的通信走同步API还是异步消息。四层架构缺一不可而且必须自上而下层层映射。业务架构里的“流程节点”可以追溯到数据架构里的“数据实体”再追溯到应用架构里的“功能模块”最后落实到技术架构里的“服务组件”。这张追溯链就是自研ERP架构设计的核心交付物。2.2 业务架构从战略目标到流程分级很多团队一听“业务架构”就觉得虚其实在ERP自研里业务架构是可以落到很具体的。关键是做好两件事业务域划分和流程分级。业务域划分是把企业运营拆成相对独立的领域比如营销域、供应链域、生产域、财务域、人力资源域。每个业务域再往下拆成业务流程组例如供应链域包含采购、库存、物流三个流程组。这套划分为什么重要因为它定义了后续所有应用模块和数据库表归属的“上层容器”边界清楚了需求才能被准确地“定位”。流程分级是更实操的技术。建议把流程分成三级L1级端到端价值链流程比如“从采购到付款”“从订单到收款”数量控制在10条以内。L2级业务流程组比如“采购管理”下的“供应商管理”“采购订单管理”“收货管理”。L3级具体操作流程比如“采购订单审批流”“收货质检流程”这类流程是要能画出流程图、定义出系统功能点的。这个分级的价值在于当业务方提需求时可以快速判断这个需求属于哪个域、对应哪个L2流程、影响哪些L3节点而不是一上来就讨论加不加字段。2.3 数据架构数据实体、数据血缘与主数据数据架构是自研ERP最容易偷懒、也最不能偷懒的一层。我建议按三步走第一步识别核心数据实体。以制造业为例核心数据实体至少包括物料、BOM物料清单、供应商、客户、库存、工序、工单、成本中心、利润中心、会计科目。这些实体就是业务架构流程节点上流转的“信息载体”。第二步绘制数据流转图。回答每个数据实体在什么流程节点被创建、被更新、被读取。这一步会暴露出大量问题同一个数据在多个地方被更新却没有人定义哪个是源系统报表数据直接查业务库导致大查询拖垮核心交易。数据流转图的价值是让数据像水流一样有明确的“上游”和“下游”。第三步定义主数据治理方案。主数据是ERP的命根子。物料主数据由谁创建、编码规则是什么、在哪个系统维护客商主数据是否需要与CRM同步会计科目表由谁统一管理。这些必须在数据架构阶段定出规范。经验是主数据治理做得好的ERP项目即使业务流程有瑕疵数据也能对得上主数据混乱的项目业务流程再顺报表也是乱的。2.4 应用架构应用边界与集成方式应用架构回答“谁来处理这件事”。在单体架构时代这很简单一个系统搞定但在如今微服务、中台概念流行的背景下应用架构反而成了最容易扯皮的一层。我对自研ERP应用架构的建议是不要迷信微服务先按业务域划分逻辑应用边界再决定物理部署方式。一个中型制造企业自研ERP完全可以把系统拆成以下逻辑应用主数据管理应用统一管物料、客商、BOM等主数据。供应链应用采购、库存、物流。生产制造应用工单、工序、报工。财务核算应用总账、应收、应付、成本、固定资产。销售应用报价、订单、发货、开票。边界划分完成之后立刻要定义集成契约每个应用对外暴露哪些API、同步还是异步、数据格式是什么、异常如何处理。这比选技术栈更重要。我见过不少项目在集成层反复纠结REST还是gRPC却连接口字段由谁定义都没说清楚。2.5 技术架构平台选型与治理标准技术架构是4A里最“接地气”的一层也最容易走极端。我的建议是两条原则一致性优先先进性其次标准化优先个性化其次。在ERP自研场景下技术选型不需要“惊艳”需要“稳定可控”。开发语言统一、数据库选型收敛、服务框架统一、部署方式统一这四个“统一”能解决80%的协作问题。具体来说开发语言建议后端统一一种语言不要把团队拆成多个语言阵营沟通成本会吞掉技术红利。数据库OLTP场景统一选择一个关系型数据库不要多库混用OLAP场景单独建数仓不要用业务库扛报表。消息队列选择一种主流的消息中间件统一Topic命名规范。部署方式要么全容器化要么全虚机化不要有的模块上K8s有的模块直接裸奔。技术架构还要产出非功能性需求基线包括性能指标核心接口的响应时间、并发量、可用性指标系统可用性达到几个9、安全基线权限模型、审计日志要求。这些如果不提前定上线前一定会被运维和安全团队按在地上摩擦。3. ADM裁剪实战把TOGAF的“标准动作”变成自研ERP的执行节奏4A架构解决的是“画什么蓝图”TOGAF ADM架构开发方法解决的是“按什么顺序和节奏来画”。标准ADM有八个阶段从架构愿景、业务架构、信息系统架构、技术架构到机会与解决方案、迁移规划、实施治理、架构变更管理。如果完全照搬一个项目光做架构设计就要做半年团队早散伙了。所以实战中必须做裁剪。我的做法是把ADM压缩成四个阶段每个阶段都有明确的输入、输出和评审节点。3.1 为什么不能照搬标准ADM标准ADM面向的是大型企业架构项目的完整生命周期产出物非常多。而自研ERP通常是企业信息化建设的一部分时间窗口有限团队规模也有限。照搬的全部后果是架构设计文档写了一大堆开发团队根本看不完最后架构师自嗨开发自行发挥。裁剪的原则是保留主干、砍掉冗余、强化与落地相关的工作。ADM最核心的主干五步是现状分析AS-IS→目标设计TO-BE→差距分析→路径规划→治理机制。这五步一个都不能少其余可以按项目实际情况简化。3.2 裁剪后的四个阶段我推荐把自研ERP的架构设计分成四个阶段阶段一架构愿景与范围锁定对应ADM预备阶段和架构愿景阶段这个阶段一周到两周产出三样东西项目架构愿景说明书、业务范围清单明确做什么、更重要的是明确不做什么、架构原则比如“主数据统一管理”“财务月结时效不超过3天”。这个阶段最重要的动作是“签字确认”。业务范围清单需要业务一把手和IT负责人同时签字后续需求哪怕再“紧急”只要超出范围就必须走正式变更流程。没有这一道锁需求蔓延就是必然。阶段二基线架构与目标架构设计对应ADM业务架构、信息系统架构、技术架构阶段这个阶段是整个架构设计的核心通常需要四到八周。产出四套架构蓝图AS-IS架构现状、TO-BE目标架构未来、架构差距清单、架构路线图。AS-IS基线不是可选项。很多团队觉得“反正要重新做系统现状梳理没有意义”这是大错特错。现状里藏着大量隐性业务规则和存量数据问题不摸清现状目标设计就是空中楼阁。实际做法是每个业务域都要做现状访谈画出当前流程图标注痛点再在此基础上设计目标流程。TO-BE目标架构必须给出关键流程的系统支撑矩阵每个L3级流程节点由哪个应用模块支撑操作哪个数据实体。这样开发团队拿到架构文档后能直接知道“这段业务流程我应该开发什么功能、操作什么表”。阶段三机会与解决方案规划对应ADM机会与解决方案、迁移规划阶段这个阶段要回答“先做什么后做什么”。自研ERP不可能全模块一步到位必须排优先级。排优先级时建议按“业务价值”和“实施难度”两个维度打分高价值低难度的先做低价值高难度的明确搁置或分期。迁移规划还要回答“旧数据怎么迁移”“新旧系统并行期怎么处理”。这块是自研ERP最容易忽视的很多项目上线当天数据迁移出问题直接导致业务停摆。阶段四架构治理与演进对应ADM实施治理和架构变更管理阶段架构设计完成不代表工作结束后续开发过程中的架构遵从度监督、需求变更对架构的影响评估都属于这个阶段。我习惯在项目例会上加入一个固定议程架构偏差评审任何偏离架构设计的技术决策都必须在这个议程上说明原因。3.3 架构基线文档AS-IS到TO-BE的落地映射很多人问架构基线文档写到什么程度才算合格。我的判断标准是八个字能追溯、能对照、能评审。能追溯是指目标架构里每个设计都能找到对应的问题来源能对照是指开发完成后可以拿实际系统与目标架构做差异比对能评审是指架构评审会上评审委员可以在有限时间内看完并给出有效意见。一份合格的目标架构文档至少应包括目标业务流程图、数据实体清单及说明、应用模块划分及职责说明、模块间集成关系图接口清单及协议以及关键技术决策记录。这套文档不需要写成几十页的“大部头”但每个结论背后都要有推导过程。4. 让架构师“工作留痕”一份能落地到代码的架构设计文档长什么样网上搜索“TOGAF架构设计文档模板”能找到大量模板但很多模板套用到ERP自研时往往水土不服。模板太厚没人看太薄又不够指导开发。分享一下我实际项目中验证过的文档结构以及每部分内容怎么写才真正能落地。4.1 架构文档不是写给评审看的是写给开发用的一个常见的认知误区是架构文档是给架构评审委员会看的“汇报材料”。错了架构文档最核心的读者是开发团队尤其是一线负责模块开发的技术骨干。文档写得是否合格不是看评审委员会是否通过而是看开发拿到文档之后能不能回答出“我这个模块要做什么、边界在哪、跟谁交互、数据存哪张表”这几个问题。因此我反对在文档里堆砌大量图表、堆砌理论概念。文档里的每个设计决策都要能和代码对应上。比如定义了一个“库存可用量计算”接口那文档里就要明确这个接口的输入参数、返回结构、异常场景以及为什么要由库存服务提供而不是由订单服务自己算。4.2 一份实操过的ERP架构文档目录以我最近一个制造业ERP项目为例架构设计文档的核心目录如下1. 架构愿景与范围 1.1 背景与目标 1.2 业务范围与边界 1.3 架构原则 1.4 关键风险与假设 2. 业务架构设计 2.1 业务域划分业务架构图 2.2 L1/L2/L3流程清单与流程图 2.3 关键业务规则清单含规则来源、规则Owner 2.4 业务流程与系统支撑矩阵 3. 数据架构设计 3.1 核心数据实体定义与属性清单 3.2 数据流转图每个核心实体的创建/更新/读取分布 3.3 主数据治理方案编码规则、维护责任、分发机制 3.4 数据归档与数据质量规则 4. 应用架构设计 4.1 应用模块划分与职责说明 4.2 应用集成架构图与接口清单API定义、协议、数据格式 4.3 模块间依赖关系与版本策略 5. 技术架构设计 5.1 技术选型原则与版本基线 5.2 基础设施与部署架构拓扑图、环境规划 5.3 非功能性需求基线性能、可用性、安全 6. 架构路线图 6.1 阶段规划分期实施计划 6.2 依赖关系与关键路径 6.3 迁移方案与新旧系统并行策略 7. 架构治理规则 7.1 设计与开发遵从检查机制 7.2 变更控制流程 7.3 架构评审Checklist这套目录的特点是每章都有可以直接指导开发的内容。比如第2章的业务规则清单很多项目都不写但我们把“审批金额超过10万元需要总经理审批”这样的规则全部编号管理开发做审批流时直接按规则编号实现验收时逐一核对需求遗漏率大幅下降。4.3 集成契约怎么定义开发才不会扯皮应用架构设计里最需要花精力的是集成契约。模块一旦多了“接口由谁定义、参数改动通知谁、接口版本怎么管理”就会变成日常摩擦的根源。我的经验是每个接口在架构文档里至少回答五个问题接口的职责边界是什么由哪个应用提供调用方是谁被调用方是谁数据格式是什么用JSON还是XML字段含义和格式约束是什么同步还是异步超时和重试策略如何异常场景如何定义业务异常和系统异常如何区分举个例子销售订单创建后需要通知库存锁定可用量。这个接口的设计必须明确订单服务调用库存服务的锁定接口是同步调用还是发MQ消息如果库存锁定失败订单是创建失败还是进入“待锁定”状态后续如何补救这些决策如果不提前定义开发和测试各凭想象实现联调阶段一定会炸。4.4 架构评审检查清单架构评审不能只“走过场”我的评审Checklist里必有这几项业务流程与系统支撑矩阵是否覆盖了所有L3级流程节点有没有“流程有但系统不支撑”的断点。数据实体清单里每个实体的创建方和Owner是否明确有没有“谁都能改”的实体。接口清单与集成架构图是否一致有没有“图上画了、清单里没有”的接口。非功能性需求是否量化能不能在验收时被测试验证。架构原则是否与实际设计冲突比如原则里写了“主数据统一管理”但设计里出现了两个独立维护物料档案的模块。每一项都直接对应后续开发中可能踩的坑。评审时不要怕吵把问题暴露在架构阶段远好于上线后在用户面前爆发。5. 数据跑不通、流程断链ERP实施中最常见也最致命的架构失控点理论讲了一堆回到现实。自研ERP项目上线后最常出现的两个问题就是热搜词里提到的“成本ERP数据没有跑通”和“ERP系统业务流程”断链。这两个问题表面是运维和配置问题本质都是架构设计阶段的隐患在后期爆发。5.1 成本数据跑不通的排查链路成本模块数据跑不通是一个极具代表性的“数据架构失败”案例。我处理过的一个真实场景是这样的现象月底成本核算报表产出时间长且每次都有几款产品分摊不到成本成本结果与实际严重偏离。第一轮排查数据源先检查原料领用记录发现部分工单的领料记录缺失。进一步查找是仓库人员在系统里做“倒冲领料”时因为BOM表物料编码与仓库实际物料编码不一致系统无法自动匹配导致领料单未生成。第二轮排查主数据追查为什么编码不一致发现BOM表维护在产品数据管理模块编码规则是“物料大类流水号”而仓库使用的是ERP库存模块的编码“仓库代码流水号”。两套编码都在用而数据架构设计阶段没有定义主数据统一编码规则。第三轮排查计算链路成本核算需要从工单归集料工费再通过成本中心分摊间接费用。由于工单领料数据缺失成本归集不全分摊基数失真最终导致部分产品成本异常。根因不是某个计算函数写错而是在数据架构设计阶段物料主数据编码没有得到统一治理数据血缘从源头上就是断的。这个案例的排查链路很有代表性数据问题 → 数据源问题 → 主数据问题 → 架构设计缺陷。所以成本模块上线前一定要用“数据架构四问”做自检各模块的核心主数据编码是否统一每个核心数据实体的创建方是否唯一数据流转的关键路径上有没有中间环节靠人工维护数据成本计算链路涉及的数据是否都有明确的时间戳和状态标记这四个问题只要有一个“否”成本数据跑不通就只是时间问题。5.2 业务流程断链的定位方法业务流程断链比数据问题更隐蔽它的表现往往是“一个单据走到某一步就消失了”“审核通过了但下游看不到”。定位这类问题靠的是架构阶段建立起来的流程-系统支撑矩阵。具体排查链路是先把出问题的业务场景还原成L3级流程图然后逐节点核对每个节点的系统支撑情况。流程断链通常有三个典型原因流程节点没有系统支撑比如“设计评审”这个节点在设计阶段没有定义由哪个系统承载实际执行靠线下Excel一换人就断。流程节点间的数据接口缺失前面的环节在A模块录完数据下一个环节在B模块找不到数据中间缺少接口视图或数据同步。流程角色配置缺失审批流断在“等待某角色审批”但系统里这个角色没有配置具体人员。第三个原因在自研ERP里最常见。很多系统上线时把流程设计得“完美”但组织架构和人员权限的维护没有跟上。这个问题的根治方案是在应用架构和业务架构设计时明确流程节点与组织角色的映射上线前用真实组织架构做一次完整的流程演练不要拿测试人员模拟的角色去验证。5.3 用4A视图做“事故归因”当ERP出了问题很多团队的第一个反应是找运维改数据、找开发修代码修完之后没有沉淀根因。我的建议是把每一个严重问题当成一次架构复盘素材用4A视图做归因如果是数据对不上追溯到数据架构层是主数据设计问题还是数据流转缺失如果是某个流程走不通追溯到业务架构层是流程设计问题还是应用支撑缺失如果是模块间合作冲突追溯到应用架构层是边界划分不清晰还是集成契约不完整如果是性能或稳定性问题追溯到技术架构层是选型问题还是部署问题这套归因方法最大的价值是让问题解决从“救火式”走向“体系化”。每个反复出现的问题背后大概率有一个反复没有被修复的架构缺陷。6. 方法论固化从一次架构设计到一套可持续演进的架构资产库最后一层也是很多企业做完一次自研ERP后没有想清楚的事情如何把这一次的方法论沉淀成组织能力让未来的信息化建设不再“重复造轮子”。6.1 构建企业架构资产库做完一个自研ERP项目会积累大量有价值的架构资产业务架构业务域划分、流程清单、业务规则库。数据架构数据实体模型、主数据治理标准、数据流转图。应用架构应用模块边界、接口契约、集成规范。技术架构技术选型标准、部署指南、运维基线。这些资产如果散落在个人电脑或者某个过期的共享目录里下一次再启动任何系统建设时都会归零。我建议在项目立项时就将架构资产库纳入交付物范围按4A维度建立目录结构并指定责任人维护。资产库的作用会在后续项目中几何级放大。比如上ERP之后又要上MES制造执行系统如果ERP的数据架构资产里有完整的物料主数据标准和接口契约MES与ERP对接的工作量会大幅下降而不是又做一次需求调研和架构设计。6.2 架构治理机制让架构从“文档”变成“准绳”架构资产库如果只是存文档没有配套治理机制最后就会沦为档案室里的废纸。我推荐在企业内部建立三个层级的治理机制第一层架构评审委员会。由CIO或CTO牵头各业务域IT负责人参加负责审批所有重大的架构设计和架构变更。委员会不需要每周开会但在关键节点必须介入比如新系统立项、大版本升级、跨域集成方案评审。第二层架构遵从检查。在开发过程中定期做代码级和设计级的架构遵从检查对照架构文档检查模块边界是否被破坏、接口是否按契约实现、是否有绕过统一数据管理的“近路”代码。第三层架构变更管理。任何影响架构基线的变更新增数据实体、修改接口协议、更换技术组件都必须走变更流程评估影响面更新架构资产库而不是只改代码。这三层机制成立后TOGAF 4A架构方法论才算真正从概念变成了组织的工作方式。6.3 从ERP到整个企业架构下一步演进方向ERP自研方法论本质上可以复用到企业几乎所有的信息系统建设上。原因在于4A架构的逻辑是通用的任何系统都有要服务的业务流程有要管理的数据有要提供的应用功能有要依赖的技术平台。区别只是复杂度不同。如果你的企业已经把基于TOGAF 4A的自研方法论在ERP项目里跑通了一遍后续再做数据分析平台、供应链协同平台、客户关系管理平台时完全可以复用同一套语言、同一套流程、同一套治理机制。这个复用过程才是方法论体系真正的增值时刻。我个人在做架构落地的过程中最深的体会是架构方法论最大的价值不在于产出那些漂亮的架构图而在于它强制团队在动手编码之前先把“边界、责任、契约、标准”四个问题想清楚。这四个问题想不清楚省下来的架构时间后面都会加倍还给项目。如果你正准备立项自研ERP建议把“架构设计”作为项目正式启动的第一项任务像这篇文章里说的一样先把4A的四张蓝图画出来把ADM的四个阶段走完再让开发团队进场。这不是多一道流程而是给项目上一道最重要的保险。 TOGAF 4A架构：自研ERP项目防烂尾的核心方法论
判断一个自研ERP项目会不会烂尾不需要看代码只需要问三个问题业务边界有没有人签字数据口径是谁说了算应用模块之间的集成契约长什么样问完这三个问题基本就知道结局了。我见过太多团队一腔热血冲进自研ERP的战场技术栈很现代微服务、云原生、低代码全上了结果半年之后数据对不上、流程接不上、成本核算怎么都跑不平。问题不出在开发而出在架构层面缺乏一套总控机制。说得重一点很多自研ERP项目不是被写代码写死的而是被没有架构约束的“自由发挥”拖死的。这篇文章想跟你聊的是基于TOGAF 4A架构来构建ERP自研方法论。TOGAFThe Open Group Architecture Framework是全球应用最广的企业架构框架4A即业务架构BA、数据架构DA、应用架构AA、技术架构TA四条主线。这套方法论解决的核心问题是怎么让ERP自研从“拍脑袋建表、凭感觉写接口”变成“有蓝图、有边界、有契约、有治理”的工程体系。适合企业架构师、IT信息化负责人、资深开发管理者以及正准备立项自研ERP的决策者参考。1. 自研ERP死因解剖不是研发力不行而是没有架构总控先泼一盆冷水。很多团队立项自研ERP时立项报告写得天花乱坠但真正拆解下来失败原因高度相似。我把过去几年的观察总结成四个“死因”每个都能在4A架构里找到对应的失控点。1.1 需求蔓延业务架构缺位的必然结果自研ERP最容易犯的第一个错误是把业务需求当成“需求清单”而不是“业务架构设计”。业务部门今天说要加一个字段明天说要加一张报表后天说审批流要改一下开发团队来者不拒半年之后系统里堆了几百张表、上千个接口没人说得清楚哪张表是主数据、哪个字段是权威口径。这不是需求管理的问题而是业务架构缺位。没有从顶层把业务域、业务流程、业务对象梳理清楚需求的“蔓延”就是必然的。每一笔新增需求都是在没有边界的地基上加砖地基不稳楼越高塌得越快。1.2 数据跑不通数据架构没人在意“成本ERP数据没有跑通”这个词条能上热搜说明这是一个普遍到不能再普遍的痛点。我调过很多ERP项目的成本核算模块报表出不来、成本分摊不对、财务和业务对不上追溯到最后往往不是开发代码写得有问题而是主数据不统一、数据血缘混乱、计算口径各说各话。物料编码在一个模块里是A-001在另一个模块里是B_001BOM版本没有统一管理成本中心和利润中心的映射关系只在Excel里有一份。这些问题的本质是项目从头到尾都没有做过数据架构设计没有定义数据标准、数据Owner、数据分布和数据流转规则。1.3 模块边界模糊应用架构没有契约自研ERP和买套装软件最大的不同在于你需要自己定义应用边界。采购模块要不要管质检质检的结果怎么传给库存库存的可用量是按订单锁定还是按仓库实时扣减这些都不是开发能拍板的问题而是应用架构层面的集成契约问题。没有应用架构开发就会“就近实现”能查表绝不调接口能在本地冗余一份数据绝不走服务调用。短期看开发速度快了长期看系统耦合度失控改一个模块崩三个模块运维成本呈指数上升。1.4 技术栈割裂技术架构没有治理很多自研ERP最终死在了“技术栈自由”上。订单组用Java库存组用Python报表组用Node.js数据库一会儿MySQL一会儿PostgreSQLKafka用了但没有人负责Topic规范。这种混乱带来的后果不是单点性能问题而是整体协作效率崩塌以及后续没人敢接手维护的“遗产代码”。这四个死因放在一起看逻辑很清楚自研ERP缺的不是代码缺的是一套从业务到技术的完整架构设计体系。TOGAF 4A架构方法论的价值恰好是把这四个层面的设计工作变成一张可以执行、可以评审、可以治理的工程路线图。2. 4A架构在ERP里的“四张蓝图”业务、数据、应用、技术分别画什么理解了“为什么死”之后接下来要回答“怎么建”。4A架构不是四个抽屉各做各的而是一条贯穿始终的主线业务架构提出业务问题数据架构回答数据如何组织应用架构决定由谁处理技术架构解决用什么承载。2.1 一条主线串联四层架构拿最常见的销售订单流程举例业务架构层面定义从线索、报价、订单、发货、开票到回款的端到端流程明确每个环节的输入、输出、角色和业务规则。数据架构层面识别“订单”这个核心业务对象有哪些属性订单号、客户、产品、数量、单价、交期、状态等定义订单数据在整个生命周期里如何创建、更新、归档。应用架构层面决定订单功能模块属于哪一个应用服务订单服务与库存服务、客户服务、财务服务之间用什么接口交互。技术架构层面确定订单服务部署在什么基础设施上采用什么开发框架数据库怎么分库分表与其他服务的通信走同步API还是异步消息。四层架构缺一不可而且必须自上而下层层映射。业务架构里的“流程节点”可以追溯到数据架构里的“数据实体”再追溯到应用架构里的“功能模块”最后落实到技术架构里的“服务组件”。这张追溯链就是自研ERP架构设计的核心交付物。2.2 业务架构从战略目标到流程分级很多团队一听“业务架构”就觉得虚其实在ERP自研里业务架构是可以落到很具体的。关键是做好两件事业务域划分和流程分级。业务域划分是把企业运营拆成相对独立的领域比如营销域、供应链域、生产域、财务域、人力资源域。每个业务域再往下拆成业务流程组例如供应链域包含采购、库存、物流三个流程组。这套划分为什么重要因为它定义了后续所有应用模块和数据库表归属的“上层容器”边界清楚了需求才能被准确地“定位”。流程分级是更实操的技术。建议把流程分成三级L1级端到端价值链流程比如“从采购到付款”“从订单到收款”数量控制在10条以内。L2级业务流程组比如“采购管理”下的“供应商管理”“采购订单管理”“收货管理”。L3级具体操作流程比如“采购订单审批流”“收货质检流程”这类流程是要能画出流程图、定义出系统功能点的。这个分级的价值在于当业务方提需求时可以快速判断这个需求属于哪个域、对应哪个L2流程、影响哪些L3节点而不是一上来就讨论加不加字段。2.3 数据架构数据实体、数据血缘与主数据数据架构是自研ERP最容易偷懒、也最不能偷懒的一层。我建议按三步走第一步识别核心数据实体。以制造业为例核心数据实体至少包括物料、BOM物料清单、供应商、客户、库存、工序、工单、成本中心、利润中心、会计科目。这些实体就是业务架构流程节点上流转的“信息载体”。第二步绘制数据流转图。回答每个数据实体在什么流程节点被创建、被更新、被读取。这一步会暴露出大量问题同一个数据在多个地方被更新却没有人定义哪个是源系统报表数据直接查业务库导致大查询拖垮核心交易。数据流转图的价值是让数据像水流一样有明确的“上游”和“下游”。第三步定义主数据治理方案。主数据是ERP的命根子。物料主数据由谁创建、编码规则是什么、在哪个系统维护客商主数据是否需要与CRM同步会计科目表由谁统一管理。这些必须在数据架构阶段定出规范。经验是主数据治理做得好的ERP项目即使业务流程有瑕疵数据也能对得上主数据混乱的项目业务流程再顺报表也是乱的。2.4 应用架构应用边界与集成方式应用架构回答“谁来处理这件事”。在单体架构时代这很简单一个系统搞定但在如今微服务、中台概念流行的背景下应用架构反而成了最容易扯皮的一层。我对自研ERP应用架构的建议是不要迷信微服务先按业务域划分逻辑应用边界再决定物理部署方式。一个中型制造企业自研ERP完全可以把系统拆成以下逻辑应用主数据管理应用统一管物料、客商、BOM等主数据。供应链应用采购、库存、物流。生产制造应用工单、工序、报工。财务核算应用总账、应收、应付、成本、固定资产。销售应用报价、订单、发货、开票。边界划分完成之后立刻要定义集成契约每个应用对外暴露哪些API、同步还是异步、数据格式是什么、异常如何处理。这比选技术栈更重要。我见过不少项目在集成层反复纠结REST还是gRPC却连接口字段由谁定义都没说清楚。2.5 技术架构平台选型与治理标准技术架构是4A里最“接地气”的一层也最容易走极端。我的建议是两条原则一致性优先先进性其次标准化优先个性化其次。在ERP自研场景下技术选型不需要“惊艳”需要“稳定可控”。开发语言统一、数据库选型收敛、服务框架统一、部署方式统一这四个“统一”能解决80%的协作问题。具体来说开发语言建议后端统一一种语言不要把团队拆成多个语言阵营沟通成本会吞掉技术红利。数据库OLTP场景统一选择一个关系型数据库不要多库混用OLAP场景单独建数仓不要用业务库扛报表。消息队列选择一种主流的消息中间件统一Topic命名规范。部署方式要么全容器化要么全虚机化不要有的模块上K8s有的模块直接裸奔。技术架构还要产出非功能性需求基线包括性能指标核心接口的响应时间、并发量、可用性指标系统可用性达到几个9、安全基线权限模型、审计日志要求。这些如果不提前定上线前一定会被运维和安全团队按在地上摩擦。3. ADM裁剪实战把TOGAF的“标准动作”变成自研ERP的执行节奏4A架构解决的是“画什么蓝图”TOGAF ADM架构开发方法解决的是“按什么顺序和节奏来画”。标准ADM有八个阶段从架构愿景、业务架构、信息系统架构、技术架构到机会与解决方案、迁移规划、实施治理、架构变更管理。如果完全照搬一个项目光做架构设计就要做半年团队早散伙了。所以实战中必须做裁剪。我的做法是把ADM压缩成四个阶段每个阶段都有明确的输入、输出和评审节点。3.1 为什么不能照搬标准ADM标准ADM面向的是大型企业架构项目的完整生命周期产出物非常多。而自研ERP通常是企业信息化建设的一部分时间窗口有限团队规模也有限。照搬的全部后果是架构设计文档写了一大堆开发团队根本看不完最后架构师自嗨开发自行发挥。裁剪的原则是保留主干、砍掉冗余、强化与落地相关的工作。ADM最核心的主干五步是现状分析AS-IS→目标设计TO-BE→差距分析→路径规划→治理机制。这五步一个都不能少其余可以按项目实际情况简化。3.2 裁剪后的四个阶段我推荐把自研ERP的架构设计分成四个阶段阶段一架构愿景与范围锁定对应ADM预备阶段和架构愿景阶段这个阶段一周到两周产出三样东西项目架构愿景说明书、业务范围清单明确做什么、更重要的是明确不做什么、架构原则比如“主数据统一管理”“财务月结时效不超过3天”。这个阶段最重要的动作是“签字确认”。业务范围清单需要业务一把手和IT负责人同时签字后续需求哪怕再“紧急”只要超出范围就必须走正式变更流程。没有这一道锁需求蔓延就是必然。阶段二基线架构与目标架构设计对应ADM业务架构、信息系统架构、技术架构阶段这个阶段是整个架构设计的核心通常需要四到八周。产出四套架构蓝图AS-IS架构现状、TO-BE目标架构未来、架构差距清单、架构路线图。AS-IS基线不是可选项。很多团队觉得“反正要重新做系统现状梳理没有意义”这是大错特错。现状里藏着大量隐性业务规则和存量数据问题不摸清现状目标设计就是空中楼阁。实际做法是每个业务域都要做现状访谈画出当前流程图标注痛点再在此基础上设计目标流程。TO-BE目标架构必须给出关键流程的系统支撑矩阵每个L3级流程节点由哪个应用模块支撑操作哪个数据实体。这样开发团队拿到架构文档后能直接知道“这段业务流程我应该开发什么功能、操作什么表”。阶段三机会与解决方案规划对应ADM机会与解决方案、迁移规划阶段这个阶段要回答“先做什么后做什么”。自研ERP不可能全模块一步到位必须排优先级。排优先级时建议按“业务价值”和“实施难度”两个维度打分高价值低难度的先做低价值高难度的明确搁置或分期。迁移规划还要回答“旧数据怎么迁移”“新旧系统并行期怎么处理”。这块是自研ERP最容易忽视的很多项目上线当天数据迁移出问题直接导致业务停摆。阶段四架构治理与演进对应ADM实施治理和架构变更管理阶段架构设计完成不代表工作结束后续开发过程中的架构遵从度监督、需求变更对架构的影响评估都属于这个阶段。我习惯在项目例会上加入一个固定议程架构偏差评审任何偏离架构设计的技术决策都必须在这个议程上说明原因。3.3 架构基线文档AS-IS到TO-BE的落地映射很多人问架构基线文档写到什么程度才算合格。我的判断标准是八个字能追溯、能对照、能评审。能追溯是指目标架构里每个设计都能找到对应的问题来源能对照是指开发完成后可以拿实际系统与目标架构做差异比对能评审是指架构评审会上评审委员可以在有限时间内看完并给出有效意见。一份合格的目标架构文档至少应包括目标业务流程图、数据实体清单及说明、应用模块划分及职责说明、模块间集成关系图接口清单及协议以及关键技术决策记录。这套文档不需要写成几十页的“大部头”但每个结论背后都要有推导过程。4. 让架构师“工作留痕”一份能落地到代码的架构设计文档长什么样网上搜索“TOGAF架构设计文档模板”能找到大量模板但很多模板套用到ERP自研时往往水土不服。模板太厚没人看太薄又不够指导开发。分享一下我实际项目中验证过的文档结构以及每部分内容怎么写才真正能落地。4.1 架构文档不是写给评审看的是写给开发用的一个常见的认知误区是架构文档是给架构评审委员会看的“汇报材料”。错了架构文档最核心的读者是开发团队尤其是一线负责模块开发的技术骨干。文档写得是否合格不是看评审委员会是否通过而是看开发拿到文档之后能不能回答出“我这个模块要做什么、边界在哪、跟谁交互、数据存哪张表”这几个问题。因此我反对在文档里堆砌大量图表、堆砌理论概念。文档里的每个设计决策都要能和代码对应上。比如定义了一个“库存可用量计算”接口那文档里就要明确这个接口的输入参数、返回结构、异常场景以及为什么要由库存服务提供而不是由订单服务自己算。4.2 一份实操过的ERP架构文档目录以我最近一个制造业ERP项目为例架构设计文档的核心目录如下1. 架构愿景与范围 1.1 背景与目标 1.2 业务范围与边界 1.3 架构原则 1.4 关键风险与假设 2. 业务架构设计 2.1 业务域划分业务架构图 2.2 L1/L2/L3流程清单与流程图 2.3 关键业务规则清单含规则来源、规则Owner 2.4 业务流程与系统支撑矩阵 3. 数据架构设计 3.1 核心数据实体定义与属性清单 3.2 数据流转图每个核心实体的创建/更新/读取分布 3.3 主数据治理方案编码规则、维护责任、分发机制 3.4 数据归档与数据质量规则 4. 应用架构设计 4.1 应用模块划分与职责说明 4.2 应用集成架构图与接口清单API定义、协议、数据格式 4.3 模块间依赖关系与版本策略 5. 技术架构设计 5.1 技术选型原则与版本基线 5.2 基础设施与部署架构拓扑图、环境规划 5.3 非功能性需求基线性能、可用性、安全 6. 架构路线图 6.1 阶段规划分期实施计划 6.2 依赖关系与关键路径 6.3 迁移方案与新旧系统并行策略 7. 架构治理规则 7.1 设计与开发遵从检查机制 7.2 变更控制流程 7.3 架构评审Checklist这套目录的特点是每章都有可以直接指导开发的内容。比如第2章的业务规则清单很多项目都不写但我们把“审批金额超过10万元需要总经理审批”这样的规则全部编号管理开发做审批流时直接按规则编号实现验收时逐一核对需求遗漏率大幅下降。4.3 集成契约怎么定义开发才不会扯皮应用架构设计里最需要花精力的是集成契约。模块一旦多了“接口由谁定义、参数改动通知谁、接口版本怎么管理”就会变成日常摩擦的根源。我的经验是每个接口在架构文档里至少回答五个问题接口的职责边界是什么由哪个应用提供调用方是谁被调用方是谁数据格式是什么用JSON还是XML字段含义和格式约束是什么同步还是异步超时和重试策略如何异常场景如何定义业务异常和系统异常如何区分举个例子销售订单创建后需要通知库存锁定可用量。这个接口的设计必须明确订单服务调用库存服务的锁定接口是同步调用还是发MQ消息如果库存锁定失败订单是创建失败还是进入“待锁定”状态后续如何补救这些决策如果不提前定义开发和测试各凭想象实现联调阶段一定会炸。4.4 架构评审检查清单架构评审不能只“走过场”我的评审Checklist里必有这几项业务流程与系统支撑矩阵是否覆盖了所有L3级流程节点有没有“流程有但系统不支撑”的断点。数据实体清单里每个实体的创建方和Owner是否明确有没有“谁都能改”的实体。接口清单与集成架构图是否一致有没有“图上画了、清单里没有”的接口。非功能性需求是否量化能不能在验收时被测试验证。架构原则是否与实际设计冲突比如原则里写了“主数据统一管理”但设计里出现了两个独立维护物料档案的模块。每一项都直接对应后续开发中可能踩的坑。评审时不要怕吵把问题暴露在架构阶段远好于上线后在用户面前爆发。5. 数据跑不通、流程断链ERP实施中最常见也最致命的架构失控点理论讲了一堆回到现实。自研ERP项目上线后最常出现的两个问题就是热搜词里提到的“成本ERP数据没有跑通”和“ERP系统业务流程”断链。这两个问题表面是运维和配置问题本质都是架构设计阶段的隐患在后期爆发。5.1 成本数据跑不通的排查链路成本模块数据跑不通是一个极具代表性的“数据架构失败”案例。我处理过的一个真实场景是这样的现象月底成本核算报表产出时间长且每次都有几款产品分摊不到成本成本结果与实际严重偏离。第一轮排查数据源先检查原料领用记录发现部分工单的领料记录缺失。进一步查找是仓库人员在系统里做“倒冲领料”时因为BOM表物料编码与仓库实际物料编码不一致系统无法自动匹配导致领料单未生成。第二轮排查主数据追查为什么编码不一致发现BOM表维护在产品数据管理模块编码规则是“物料大类流水号”而仓库使用的是ERP库存模块的编码“仓库代码流水号”。两套编码都在用而数据架构设计阶段没有定义主数据统一编码规则。第三轮排查计算链路成本核算需要从工单归集料工费再通过成本中心分摊间接费用。由于工单领料数据缺失成本归集不全分摊基数失真最终导致部分产品成本异常。根因不是某个计算函数写错而是在数据架构设计阶段物料主数据编码没有得到统一治理数据血缘从源头上就是断的。这个案例的排查链路很有代表性数据问题 → 数据源问题 → 主数据问题 → 架构设计缺陷。所以成本模块上线前一定要用“数据架构四问”做自检各模块的核心主数据编码是否统一每个核心数据实体的创建方是否唯一数据流转的关键路径上有没有中间环节靠人工维护数据成本计算链路涉及的数据是否都有明确的时间戳和状态标记这四个问题只要有一个“否”成本数据跑不通就只是时间问题。5.2 业务流程断链的定位方法业务流程断链比数据问题更隐蔽它的表现往往是“一个单据走到某一步就消失了”“审核通过了但下游看不到”。定位这类问题靠的是架构阶段建立起来的流程-系统支撑矩阵。具体排查链路是先把出问题的业务场景还原成L3级流程图然后逐节点核对每个节点的系统支撑情况。流程断链通常有三个典型原因流程节点没有系统支撑比如“设计评审”这个节点在设计阶段没有定义由哪个系统承载实际执行靠线下Excel一换人就断。流程节点间的数据接口缺失前面的环节在A模块录完数据下一个环节在B模块找不到数据中间缺少接口视图或数据同步。流程角色配置缺失审批流断在“等待某角色审批”但系统里这个角色没有配置具体人员。第三个原因在自研ERP里最常见。很多系统上线时把流程设计得“完美”但组织架构和人员权限的维护没有跟上。这个问题的根治方案是在应用架构和业务架构设计时明确流程节点与组织角色的映射上线前用真实组织架构做一次完整的流程演练不要拿测试人员模拟的角色去验证。5.3 用4A视图做“事故归因”当ERP出了问题很多团队的第一个反应是找运维改数据、找开发修代码修完之后没有沉淀根因。我的建议是把每一个严重问题当成一次架构复盘素材用4A视图做归因如果是数据对不上追溯到数据架构层是主数据设计问题还是数据流转缺失如果是某个流程走不通追溯到业务架构层是流程设计问题还是应用支撑缺失如果是模块间合作冲突追溯到应用架构层是边界划分不清晰还是集成契约不完整如果是性能或稳定性问题追溯到技术架构层是选型问题还是部署问题这套归因方法最大的价值是让问题解决从“救火式”走向“体系化”。每个反复出现的问题背后大概率有一个反复没有被修复的架构缺陷。6. 方法论固化从一次架构设计到一套可持续演进的架构资产库最后一层也是很多企业做完一次自研ERP后没有想清楚的事情如何把这一次的方法论沉淀成组织能力让未来的信息化建设不再“重复造轮子”。6.1 构建企业架构资产库做完一个自研ERP项目会积累大量有价值的架构资产业务架构业务域划分、流程清单、业务规则库。数据架构数据实体模型、主数据治理标准、数据流转图。应用架构应用模块边界、接口契约、集成规范。技术架构技术选型标准、部署指南、运维基线。这些资产如果散落在个人电脑或者某个过期的共享目录里下一次再启动任何系统建设时都会归零。我建议在项目立项时就将架构资产库纳入交付物范围按4A维度建立目录结构并指定责任人维护。资产库的作用会在后续项目中几何级放大。比如上ERP之后又要上MES制造执行系统如果ERP的数据架构资产里有完整的物料主数据标准和接口契约MES与ERP对接的工作量会大幅下降而不是又做一次需求调研和架构设计。6.2 架构治理机制让架构从“文档”变成“准绳”架构资产库如果只是存文档没有配套治理机制最后就会沦为档案室里的废纸。我推荐在企业内部建立三个层级的治理机制第一层架构评审委员会。由CIO或CTO牵头各业务域IT负责人参加负责审批所有重大的架构设计和架构变更。委员会不需要每周开会但在关键节点必须介入比如新系统立项、大版本升级、跨域集成方案评审。第二层架构遵从检查。在开发过程中定期做代码级和设计级的架构遵从检查对照架构文档检查模块边界是否被破坏、接口是否按契约实现、是否有绕过统一数据管理的“近路”代码。第三层架构变更管理。任何影响架构基线的变更新增数据实体、修改接口协议、更换技术组件都必须走变更流程评估影响面更新架构资产库而不是只改代码。这三层机制成立后TOGAF 4A架构方法论才算真正从概念变成了组织的工作方式。6.3 从ERP到整个企业架构下一步演进方向ERP自研方法论本质上可以复用到企业几乎所有的信息系统建设上。原因在于4A架构的逻辑是通用的任何系统都有要服务的业务流程有要管理的数据有要提供的应用功能有要依赖的技术平台。区别只是复杂度不同。如果你的企业已经把基于TOGAF 4A的自研方法论在ERP项目里跑通了一遍后续再做数据分析平台、供应链协同平台、客户关系管理平台时完全可以复用同一套语言、同一套流程、同一套治理机制。这个复用过程才是方法论体系真正的增值时刻。我个人在做架构落地的过程中最深的体会是架构方法论最大的价值不在于产出那些漂亮的架构图而在于它强制团队在动手编码之前先把“边界、责任、契约、标准”四个问题想清楚。这四个问题想不清楚省下来的架构时间后面都会加倍还给项目。如果你正准备立项自研ERP建议把“架构设计”作为项目正式启动的第一项任务像这篇文章里说的一样先把4A的四张蓝图画出来把ADM的四个阶段走完再让开发团队进场。这不是多一道流程而是给项目上一道最重要的保险。