华为MetaERP关联交易模块：Inside还是Outside？用4A架构四域分析法终结拉锯战

华为MetaERP项目进入实施阶段后摆在财务IT和架构团队面前的选择题往往是这样在华为MetaERP上开发“关联交易管理”模块到底选Inside模式原生内置还是Outside模式外部集成这个问题在一些集团企业的方案评审会上来回拉锯甚至能吵上好几轮。我参与过几家企业的方案设计发现争论之所以僵持不是大家不懂技术而是缺一个统一的分析框架——有人只看功能边界有人只管数据归属有人纠结性能开销各自从自己熟悉的维度出发最后谁也说服不了谁。华为4A架构业务架构、应用架构、数据架构、技术架构恰好提供一个把大家拉到同一个频道上的方法。这个标题问得很准因为它表面是技术选型实质是企业架构决策。我打算按4A架构逐层拆解从业务本质到应用形态从数据分布到技术承载最后给出一个可以直接拿去评审会上用的决策矩阵。这篇文章既适合正在做华为MetaERP落地方案的架构师也适合财务合规团队想搞清楚“为什么技术同事总在问我业务规则”的情况。1. 这个决策不是技术选型而是架构路线之争1.1 一个真实评审场景Inside还是Outside的争论是怎么起的我见过最典型的评审场景是这样的财务共享中心提了一个需求说上市公司每年关联交易披露工作量巨大Excel手工台账根本管不住希望在MetaERP里加一个关联交易管理模块。IT部门一听“加模块”很自然就问是做成MetaERP原生内置的Inside模式还是搭一套独立的Outside系统做集成然后两拨人就开始各说各话。IT倾向Outside理由是独立部署、独立发版不用被ERP的大版本节奏绑死财务偏向Inside理由是业务操作就在ERP里为什么还要跳去另外一个系统录入一遍合规部门在旁边补一刀我们只关心审计的时候数据链路完不完整、披露底稿能不能一键出来。这个场景在真实项目里太常见了。三个角色诉求不同关注维度不同如果没有人从企业架构层面把问题结构化评审会开十次也不会有结论。1.2 两种模式的准确定义别被名字带偏先说清楚Inside模式和Outside模式到底指什么因为这两个词在不同语境下含义可能被带偏。Inside模式原生内置是把关联交易管理作为MetaERP平台上的原生模块来建设。模块跑在MetaERP的应用框架内使用MetaERP统一的元数据模型、权限体系、单据模板、审批流引擎和报表能力。数据模型直接定义在ERP的数据库Schema里和总账模块、应收应付模块、采购销售模块共享一套数据底座。业务人员在MetaERP界面里做完采购订单触发的关联交易识别、审批、标记都在同一个平台内完成不需要跨系统跳转。Outside模式外部集成是建设一个独立于MetaERP的应用系统可能基于自有技术栈开发拥有独立的数据库、独立的部署环境、独立的UI。它通过华为MetaERP开放出来的API、事件消息或定时批量任务与ERP交换主数据和交易数据。对外部系统来说MetaERP只是它众多数据源中的一个对MetaERP来说外部系统只是一个偶尔调用接口的第三方服务。这两种模式名字听起来只是“位置”的区别实际上背后藏着完全不同的治理逻辑。Inside意味着你接受平台的约束换取平台的能力Outside意味着你保留最大自由度但必须自己处理平台本来帮你解决的问题。1.3 为什么必须用华为4A架构来做这个决策华为4A架构方法论把企业架构拆成四个域业务架构回答“业务流程怎么跑”应用架构回答“用什么应用系统承载业务流程”数据架构回答“数据产生在哪里、归属谁、怎么流动”技术架构回答“应用和数据跑在什么基础设施上”。这四层是自上而下的约束关系。业务上要求实时识别关联方应用上就倾向于在交易系统内嵌规则应用上选择了独立外部系统数据上就必然出现跨系统传递数据上要求审计追溯技术上就要考虑日志、链路追踪和账本一致性。任何一个环节的决策都会传导到其他环节。所以当你纠结Inside还是Outside的时候别急着比较技术栈也别先争论UI体验。先从业务架构层把关联交易管理的本质诉求理清楚一层层往下推。这也是我用4A架构来做系统性分析的原因——答案不是某个域单独给出的而是四个域收敛出来的。2. 业务架构域关联交易的业务本质把两种模式分到了不同赛道2.1 先拆开看关联交易管理的业务流程全景关联交易管理在业务上不是单一流程而是一组流程的集合。我做项目时习惯先把它拆成六个子流程关联方识别与名录维护定义哪些法人、自然人、组织属于关联方维护关联关系图谱通常需要对接外部工商数据。交易环节的关联方判定在采购、销售、资金调拨等交易发生时识别交易对手方是否是关联方并标记交易性质。定价公允性评估对关联交易的价格与市场公允价做对比分析支持转让定价文档的生成。分级审批与授权控制根据交易金额和关联方类型走不同的审批层级重大关联交易可能需要董事会或股东会层面审议。交易统计与披露报告按期间统计关联交易金额、类型、余额生成定期报告和临时公告所需的披露附注。审计与合规追踪保留完整的数据链路和流程记录应对内部审计和外部监管检查。这六个子流程对ERP系统的依赖程度是完全不同的。有的流程天生就应该长在交易系统里有的流程本质上属于分析型业务放在独立系统里反而更顺手。关键观察是如果你把这六个子流程逐一贴到“交易发生→入账→月结→披露”的ERP主链路上会发现前两个环节识别、判定和中间两个环节审批、统计高度依赖ERP的事务性数据和实时状态而后两个环节公允性评估、审计追踪属于典型的分析型工作负载对实时性要求没那么高但对数据完整性和加工逻辑要求很高。2.2 业务流程与ERP的“绑定深度”决定了模式分叉业务架构层面对Inside和Outside选择最有决定性的一个判断标准我管它叫“绑定深度”——这些业务流程到底是和ERP的日常交易强绑定还是相对独立。先看交易环节的关联方判定。这是一个极其典型的实时嵌入式规则。当采购员在MetaERP里录入一张采购订单或者财务在应付模块里做发票校验时系统需要立刻判断“这个供应商是不是关联方”。如果是Inside模式这个判断就在同一平台内完成规则引擎直接读取关联方名录秒级返回结果并能当场阻止超权限的关联交易继续流转。如果是Outside模式就算外部系统已经把关联方标记回写到MetaERP从数据产生到标识生效之间始终存在一个时间窗口这期间发生的交易可能漏判。再看披露报告生成。这个场景恰恰相反。财务部门在季度末需要把关联交易按关联方、按交易类型、按币种汇总生成披露附注。这个流程不需要在交易瞬间发生它需要把多个期间的交易数据做清洗、转换、合并再套用监管模板。这种工作放到外部独立系统里反而更灵活因为你可以专门为披露规则做数据模型不用被ERP的财务科目体系绑住。所以业务架构层的结论是关联交易管理并不是铁板一块地选“Inside”或“Outside”而是要看哪个子流程占主导。如果企业最痛的点是“交易环节经常漏识别关联方”Inside模式是正解如果最痛的点是“季末披露底稿手工整理太慢”Outside模式有优势。这两个痛点同时存在的情况非常普遍所以后文我会专门讲折中方案。2.3 业务Owner和监管节奏对选择的影响业务架构层还有一个容易被忽略的因素这个模块的业务Owner是谁。关联交易管理在企业里通常是“一个模块两个婆婆”。财务共享中心关心的是核算和披露法务合规部门关心的是审批流程完整性和利益冲突防范。这两个部门对流程透明度和数据可见性的诉求并不完全相同。财务希望披露数据从ERP一键出来合规希望审批流程独立、关卡清晰。如果是财务主导Inside模式通常更顺因为数据直接从ERP出核算口径统一如果是合规主导Outside模式有时候更受欢迎因为它可以在集团层面统一建设一套独立的合规平台不受ERP的流程限制特别是当集团旗下有多套ERP系统不只是MetaERP的时候外部平台可以做跨系统的关联交易总控。监管节奏也要考虑进去。交易所和监管机构对关联交易披露的格式要求一直在更新企业必须随时跟进。Inside模式下这个模块的发布节奏大概率受MetaERP整体发版节奏影响哪怕MetaERP支持模块级独立发版你也要走平台内部的变更审批流程。Outside模式下规则更新就是一个独立应用的普通发版今天改模板明天就能上线。这一点对披露事项特别多的上市公司来说不是加分项是决定项。3. 应用架构域功能边界、接口契约与变更节奏的真正分水岭3.1 Inside模式统一应用环境下的收益与代价Inside模式在应用架构层面的核心优势首先是复用。MetaERP平台本身提供了用户认证、权限鉴权、组织架构、审批流、单据编码、消息中心、报表设计器等一整套通用能力。关联交易管理模块如果原生内置这些能力全部可以直接继承不需要单独开发也不需要再做一遍企业SSO对接、权限矩阵映射这类的重复劳动。对实施团队来说这意味着更短的建设周期和更少的集成联调。其次是用户体验。业务人员大部分时间在MetaERP里干活采购、销售、财务看到的就是唯一的工作台。关联交易审批和日常单据审批在同一套待办中心里不用来回切换系统。对于一线操作人员来说减少一套系统就是减少一次培训、一堆账号、一叠操作手册。但代价也很明显。绑定在MetaERP平台里意味着模块的技术实现受平台约束。平台用什么样的框架、支持什么样的前端组件、数据模型怎么扩展你都要在平台规则内做事。这倒不一定是坏事儿但如果你希望用自己团队更熟悉的另一套技术栈来实现部分复杂逻辑在Inside模式下几乎没有选择空间。更大的代价是变更协同。模块和ERP核心功能在同一个应用环境里虽然可以做到应用层面解耦但底层数据模型和基础设施共享。任何一个涉及公共数据模型的改动都需要和ERP其他模块做回归测试确保没有影响总账、没有影响采购付款链路。这种变更成本在业务规则频繁调整的阶段会被无限放大。3.2 Outside模式独立应用环境下的灵活与成本Outside模式的应用架构特征更像是搭了一套独立的“关联交易合规平台”。这个平台可以是一个微服务集群打包成独立的容器镜像部署在单独的Kubernetes命名空间里拥有自己的配置中心、日志系统和监控大盘。团队可以选择自己最熟悉的技术栈按照自己的节奏迭代。这是它最大的吸引力。独立带来的直接好处是故障隔离。假设外部系统某个接口出现性能问题或者数据库连接打满影响范围被限制在这个独立应用内部不会波及MetaERP核心交易链路。反过来也一样MetaERP升级维护时外部系统可以继续运行等接口恢复后再做数据补偿。但独立也意味着很多原本由平台解决的事情现在要自己解决。登录认证要自己对接统一身份认证体系权限模型要自己设计审计日志要自己存消息通知要自己接。这些在Inside模式下一行配置就能搞定的事情在Outside模式下每一项都是工作量。更关键的是外部系统与MetaERP之间所有交互都要通过接口契约。应用架构层面最容易被低估的就是这个接口契约带来的长期成本。这不是开发阶段联调一次的问题而是在系统全生命周期里每一次字段变更、每一项主数据调整都需要契约同步。后面我会专门展开讲这个点。3.3 接口契约是Outside模式最大的隐性成本如果选择Outside模式我建议项目启动的第一件事不是画架构图而是把接口清单列出来。我在实际项目里总结出的Minimum接口清单大概是这样主数据同步接口组织架构、供应商、客户、银行账户等基础资料的增量同步。关联方判定依赖主数据上的标识字段这个接口一旦延迟所有下游判断都会失真。交易数据获取接口采购订单、采购发票、付款单、销售订单、销售发票、收款单、总账凭证需要支持按增量实时或按期间批量拉取。关联方判定结果回写接口外部系统完成判断后要把结果和判定依据回写到MetaERP的交易单据上便于业务人员在ERP端看到“此单为关联交易”的标识。审批结果同步接口外部系统的分级审批完成后要同步状态回MetaERP控制交易流程继续流转还是退回。合规调整凭证生成接口如果涉及关联交易的合规调整需要生成会计凭证外部系统要调用ERP的凭证创建接口。这张清单里的每一个接口都要面对幂等、重试、时序、补偿四个问题。比如交易数据接口重复推送了两次业务数据会不会重复入账主数据变更和交易数据到达的顺序不对关联方标识会不会匹配不上接口调用超时了是重试还是跳过这些问题在联调阶段不那么显眼但到了生产环境的每个月结期间会一个接一个冒出来。对比之下Inside模式完全绕开了接口契约这个层次因为数据共享发生在数据库和应用内部不需要序列化、传输、反序列化这一整套额外开销。这也正是很多团队在项目后期发现Outside模式“越做越重”的深层原因。3.4 应用架构层面的决策小技巧在应用架构层我通常会给客户一个非常实操的判断方法把关联交易管理模块需要的能力拿出来逐个对照MetaERP平台已有的平台能力看覆盖率。覆盖率高Inside模式省下来的成本相当可观覆盖率低比如你要的很多能力平台的报表、流程引擎都不支持那硬塞进Inside反而束手束脚。另一个技巧是评审变更频率。内部问一下财务团队过去一年关联交易相关的规则、模板、审批流改过多少次如果一年改个两三次Inside的变更成本完全可以接受如果一个月改好几次那绝对不要把自己绑死在主平台的大版本节奏里Outside模式或者混合架构是更稳妥的选择。4. 数据架构域数据主权、一致性与审计追溯最容易翻车的环节4.1 关联方主数据“事实”数据与“交易”数据的本质区别数据架构层有一个根本问题我每次做方案都会先抛出来关联方名录到底应该算“事实数据”还是“交易数据”关联方名录的典型属性包括企业名称、统一社会信用代码、股权结构、实际控制人、关联关系类型、关系开始和结束日期这些数据主要来自工商登记、股权穿透、董监高名单本质上是一种外部事实数据不依赖ERP内部的任何交易动作。而交易数据比如采购订单、销售发票、收付款记录是在ERP的业务流水中自然产生的。这个区别之所以关键是因为它直接决定了数据的“出身”。如果你把关联方名录作为Inside模块的一部分建在MetaERP里那它就混入了ERP的财务数据模型和客户供应商主数据搅在一起。这在维护上会产生一些麻烦外部工商数据变了你需要一个流程把变更同步进来而ERP主数据变更又受到各种引用关系约束。反倒是把它放在外部系统里作为独立的数据域管理来源清晰、更新独立、分发路径可以灵活定义更符合“事实数据”的管理逻辑。换成数据架构的行话来说关联方名录天然适合外部系统或主数据管理平台来负责而交易环节的打标和判定结果才是ERP应该持有的数据。这个区分对后面要讲的混合模式是最重要的理论基础。4.2 一致性窗口强一致与最终一致的分界线数据架构里另一个核心问题是数据一致性。围绕关联交易最敏感的数据操作是“标记”——在交易发生时给这笔交易盖上“关联交易”的章。这个章盖得准不准、盖得及时不及时直接决定后续所有统计和披露是否可信。Inside模式下这个标记发生在同一个数据库事务里。采购订单保存的瞬间事务内的规则引擎读取关联方名录写入标记字段要么都成功、要么都失败不存在中间状态。这是典型的强一致。Outside模式下事情就复杂得多。ERP先保存交易单据再通过接口把交易数据推给外部系统外部系统判断后把结果回写。整个过程是异步的存在一个“交易已保存但尚未判定”的时间窗口。如果刚好在窗口期内做数据抽取或统计漏掉那几笔还没打标的单据结果就是错的。等到回写完成你还需要一个机制来发现并修正之前统计的错误。这已经进入最终一致的范畴。对这个时间窗口怎么处理是你做Outside方案数据架构设计时必须回答的问题。有些企业选择“过了窗口期再做对账”每天晚上跑一次增量比对第二天早上出差异报告有些企业选择“宁可多判不可漏判”在关联方名录里做宽松匹配宁可把非关联方误标成关联方也不放过一个真正关联方。这两种策略各有代价但都比什么都不做强。做Inside模式这个问题在事务层面就消失了你根本不需要设计对账机制。4.3 审计与披露数据血缘是绕不开的功课关联交易是上市公司监管的重点领域数据血缘会成为审计时绕不开的硬要求。监管检查的时候对方不只看最终披露的数字对不对还会顺着数字往下挖这个金额来自哪几张凭证凭证后面是哪笔订单订单的交易对手方为什么被认定为关联方认定依据是什么Inside模式下这一整条数据链路都在MetaERP内部闭环。订单、凭证、审批记录、关联方标识、批注依据全部存在同一个数据库里数据血缘天然完整。审计人员要抽查某笔重大关联交易顺着单据编号一路回溯路径清晰、物理上在一个库解释起来也容易。Outside模式下这条链路被切断了。交易数据在MetaERP判定结果在外部系统审批记录可能又在外部的流程引擎里披露底稿再经过一道数据加工被拆成好几个副本。审计人员要还原完整链路你必须额外建设数据血缘追踪能力把跨系统的调用链、字段映射、加工逻辑都记录下来。这不是不能做但它需要专门的审计追踪模块支撑是Outside模式里数据侧最大的额外投入。4.4 一次关联方接口失效的经典事故复盘我在一个项目里经历过一次印象特别深的事故完全可以当反面教材看。那家企业选的是Outside模式外部合规平台从工商数据源同步关联方名录通过API给MetaERP回写供应商的关联方标记。上线后一切正常直到有一次工商数据源做接口升级关联方名录里一家核心供应商的社会信用代码格式发生了变化外部平台清洗后回写了标记但MetaERP侧旧主数据里那个供应商的信用代码还是老格式。接下来两天采购部门在ERP里录入的所有涉及这家供应商的新订单都无法命中外部平台的关联方判断规则全部漏标。等月底统计时发现异常已经产生了将近一个亿的关联交易没走分级审批。复盘下来根因就是“同一个实体的标识在两个系统里没有唯一化”。这看起来是数据质量问题本质上是Outside模式下数据分布割裂的必然结果。如果采用Inside模式关联方名录和供应商主数据在同一套数据模型里用同一个唯一标识这种问题根本不会发生。如果必须用Outside模式就一定要在主数据同步层面做实体解析和映射管理不能假设两个系统里的“同一家公司”长得一样。5. 技术架构域性能预算、安全边界与运维体系决定天花板5.1 关键路径性能每笔交易多一次远程调用的代价技术架构域最直接的影响是性能。关联交易判定如果发生在交易单据保存的关键路径上它对延迟是非常敏感的。我之前在性能测试环境里做过一组对比。MetaERP标准采购订单保存接口在单笔交易场景下的P95延迟大概是200毫秒左右。如果在这个关键路径里插入一个外部系统远程判定调用即使接口本身很快加上网络传输、序列化、可能的鉴权开销P95延迟会直接翻到400到500毫秒。对于月结期间批量处理一大批单据的场景这种额外延迟会明显拖慢整体处理速度。Inside模式下这个判定是在平台内部完成的可能只是一个服务调用或者规则引擎内部的函数执行额外增加的开销在个位数毫秒级几乎可以忽略不计。如果企业交易量大、对单据处理时效要求高这一点就足以影响决策。当然Outside模式可以设计成异步判定、事后打标但这其实是把技术延迟转化成了数据一致性问题就像我前面说的你又得为那个时间窗口做对账。性能和一致性之间总要选一头。5.2 安全边界与权限模型的差异关联交易数据的安全级别通常比普通业务数据更高因为它涉及关联自然人、高管信息、未披露的敏感交易属于内幕信息管控的范围。安全边界怎么建两种模式差别很大。Inside模式下数据天然在MetaERP的安全边界内。权限体系是现成的字段级权限、数据权限、审计日志都能复用平台能力。你需要做的只是把关联交易数据对象的权限模型配置好不需要单独建设安全服务。Outside模式下你必须独立建设一套安全体系。关联方名录、交易明细表、定价分析数据散落在自己的数据库里你要自己定义谁能看、谁能改、谁能导出还要把登录、访问、导出、删除等操作日志完整记录下来。更要命的是外部系统和MetaERP接口传输的数据包含敏感的财务和人员信息网络层要做加密接口层要做访问控制整个安全合规的范围会大很多。从安全投入角度讲Inside模式明显更经济。但这里有个例外如果企业希望把关联交易合规平台作为一个集团级共享平台同时服务多套ERP和多个法人主体那么独立平台反而能在更广的范围统一安全策略这是Outside模式的安全侧优势。5.3 发布、升级和运维模式从根本上决定团队生态最后聊聊运维和团队生态这个经常被低估。Inside模式下模块的生命周期和MetaERP平台深度绑定。平台的升级、补丁、数据库变更都会影响模块。你需要一支熟悉MetaERP平台技术体系的团队来维护它跟着平台一起做升级测试。好处是你不用额外维护一套部署环境监控告警、备份恢复、容灾切换这些基础设施能力都由平台提供。Outside模式下你养的是另外一支技术栈的团队有一套独立的部署流水线、监控体系和运维值班机制。表面上是多了一套系统实际上是多了一套完整的运维体系。接口性能出问题、数据库连接池被打满、消息积压导致数据不同步这些故障场景都是团队需要自己应对的。我见过的成功案例里选择Outside模式的企业通常集团层面本身已经有成熟的自研系统研发运维体系能支撑这套额外的基础设施选择Inside模式的则更多是希望聚焦业务而不过度投入技术基础设施的企业。这没有绝对的优劣但它决定了你后续要养一支什么样的技术队伍属于典型的长期成本。6. 四域汇合的决策矩阵到底该选Inside还是Outside6.1 一个可复制的四域评分模板讲了这么多最终还是要落回到决策。我自己在项目里常用下面这个四域评分模板把前面四个域拆成八个细分维度每个维度按企业实际情况打分最后汇总偏向。架构域评分维度Inside模式优势Outside模式优势业务架构交易环节实时识别强事务内打标弱存在窗口期业务架构披露报告灵活调整弱受平台节奏约束强可独立迭代应用架构平台能力复用强开箱即用弱需要自建应用架构模块独立迭代弱受主版本影响强独立发版数据架构数据一致性与血缘强天然闭环弱需要额外建设数据架构多系统统一管控弱只覆盖单套ERP强可跨系统统一技术架构关键路径性能强低延迟弱远调开销技术架构运维独立与隔离弱依附平台强独立生命周期打分的时候注意权重不能一刀切。交易量大、受监管关注多的企业业务架构的实时识别权重应该抬高披露规则变化频繁的上市公司应用架构的灵活迭代权重应该抬高。每个企业打完分之后呈现的偏向通常会在某个方向上非常明确。6.2 三类典型企业画像与推荐路径结合这些年的项目经验我归纳了三类典型企业画像可以直接对号入座。第一类母公司管控强、上市公司主体多、监管披露压力大的大型集团。这类企业往往需要一套集团级的关联交易合规平台跨多个ERP系统做统一管理。推荐Outside模式并且要把主数据管理、数据血缘、审计追踪三件事在项目启动时就立项不要等上线后再补。第二类单套MetaERP覆盖核心财务流程、关联交易以日常经营性交易为主的中型企业。这类企业最痛的是漏识别关联方、审批关不严。推荐Inside模式把判定规则嵌到交易链路里利用平台事务能力做到强一致整体建设成本低、见效快。第三类集团正在从底层数套ERP整合到MetaERP而关联交易平台已经单独存在多年的企业。这类企业不是从零开始选型而是做系统演进。我更推荐“以Outside为主、以Inside为补充”的混合路径先把核心交易打标下沉到Inside把工商数据维护和披露报表留在Outside逐步过渡。6.3 折中方案Inside做控制点Outside做分析面前面几章反复提到关联交易管理不是一个单块系统而是由多条流程组成的。如果企业两个痛点同时存在完全没必要陷入二选一的死胡同。业界正在被验证的路线是“Inside做控制点Outside做分析面”。具体拆开是这样的交易环节的关联方判定、打标、分级审批控制用Inside模式落在MetaERP内部保证实时性和一致性。这块是整个方案的安全底座也是最不能含糊的部分。关联方名录维护、工商数据同步、定价公允性分析、披露报告生成、审计数据加工放在Outside平台让合规和财务团队有一个独立的分析工作台。两个部分之间的数据流是单向为主的Inside侧产出“已打标的交易数据”通过接口或消息流向Outside分析面Outside侧维护的“关联方名录”通过主数据同步回传Inside侧。这样分工既解决交易实时控制问题又给了披露规则一个灵活的迭代空间。我在实际项目里验证过这个混合模式最大的感受是它把“冲突”转化成了“分工”。财务不再被强制要求接受某个单一模式的所有缺点架构师也不用在两个方案之间做痛苦的取舍。唯一需要投入精力的是把Inside和Outside之间的数据接口契约管理好那是这个架构的命门。我个人在实际操作中还有一个体会不管最终选了哪种模式项目启动时一定要先把业务Owner是谁、数据真相源放在哪里、变更窗口谁能等三个问题定下来方案评审会才有真正的决策基础。如果这些基础问题没对齐Inside和Outside的争论还会在后续每一个版本里反复出现消耗团队的耐心和预算。