集团上系统，钱从哪出、怎么摊，往往比选哪家更难谈。总部觉得这是全集团受益，应当共同承担；成员单位觉得自己用得少，凭什么按人头平摊。会开三轮，预算表还是改不回一张。
这类争议的根源不在钱多钱少，而在预算表本身没把费用结构拆开。结构一拆，谁该出哪一部分就有了依据，讨论也就从争比例变成核清单。
一、预算编不下去的三个原因
（一）把一次性投入和年度支出混在一张表里
平台采购、实施服务、环境准备属于一次性投入；订阅、运维、内部人力、变更储备属于年度支出。两者混在一张表里，总额看着吓人，却说不清哪部分第二年还要再出，讨论自然打转。
（二）没有区分共性能力与个性需求
统一门户、统一身份、流程引擎、集成通道，这些是全集团共用的底座；某个板块的特殊考核表、某家单位的行业台账，只对一小部分人有用。底座该由总部出，个性该由提出方出，不分就会互相攀比。
（三）新增单位的成本没人预估
集团每年都有新设、并购、划转。每新增一家单位，账号、组织、流程、数据都要跟着扩。这笔边际成本如果不在预算里体现，第二年就会被当成超支来追责。
二、一张能谈的预算表长什么样
建议按四段列：底座投入、单位增量、年度运营、变更储备。每段单独一行，注明承担方与计算依据。
（一）底座投入：总部承担为主
平台许可、核心引擎、统一门户、集成通道、环境与安全，这些支撑全集团的能力放在第一段，由总部预算承担。理由很直接：这部分的价值不体现在某一家单位的报表上，摊到单位只会引发无休止的争论。
（二）单位增量：按实际开通计
每个单位的账号数、启用模块、数据量、对接系统数量，构成它的增量。按开通计费的好处是可核对——单位自己知道开了多少，也就能自己算出该出多少，不必等总部下发一个比例。
（三）年度运营：按服务口径
运维响应、版本升级、培训与文档，这部分按年度计。若集团内部有共享服务中心，也可以把这部分转为内部结算，但结算口径要写清，否则每年都要重谈一次。
（四）变更储备：按比例预留
制度调整、组织变化、新增单位，这些一定会发生。建议按年度运营额的一定比例预留，由总部统一管理，单位申请使用。没有这笔储备，每次调整都要走一次追加预算，效率极低。
三、核心选型标准
预算能不能编得清，很大程度上取决于产品本身的授权与部署模型。以下四条建议在选型阶段就纳入评估。
（一）授权模型要能对应组织变化
集团的组织结构一年一小调、三年一大调。授权若按固定名单绑定，每次调整都要重新谈合同。评估时要问清：新增单位、拆分单位、合并单位，授权怎么迁移，是否需要重新采购。
（二）新增单位的边际成本要可预期
问一句：从第十家单位扩到第二十家，成本曲线是平的还是陡的。答案清楚，预算才敢做三年规划；答案含糊，就只能一年一议。
（三）共性能力与个性需求要能分开计价
底座与专项若打包成一个价格，分摊就永远谈不清。能按模块、按应用分开报价的方案，预算表才编得出来，也才经得起审计问询。
（四）部署形态要能匹配不同单位的网络条件
总部在内网、分支在专线、境外单位走公网，三种条件下的部署与运维成本差别很大。形态不匹配，预算里的环境与带宽费用会年年超。
四、泛微产品体系如何对应这些标准
按上面四条去对照泛微官网的产品体系，可以看到它的分层方式与预算表的四段结构大致对得上。
底座这一段，对应泛微 e-cology 面向大中型组织的定位——智能化、平台化、全程数字化，微服务架构可拆成两百多个微服务，支持多租户与单体互转，云上、私有与超融合都能部署。多租户与单体互转这一点对集团尤其关键：既能让各单位共享一套底座，也能为特殊单位单独隔离。
统一入口与分级权限这一段，对应泛微 EIP 统一信息门户。门户引擎可按组织架构、职级权限、角色等多套架构层次展现，权限能细到页面元素一级，支持统一单点登录与待办集成。总部看全集团、板块看本板块、单位看本单位，一套门户就能分出层次。
集成这一段对应泛微集成平台 ESB，官网表述包含统一入口、应用集成、灵活连接、持续扩展，具体到统一身份、组织同步、多类型多岗位待办集成、数据一点输入多点利用、异构系统统一报表。新增单位要接几个系统、要开几个接口，可以据此列清单计价。
个性需求这一段对应泛微低代码构建平台 e-builder，零代码、低代码与全代码三种方式，模板云商店里有一千多个模板。哪个板块要自己的考核表，由该板块在这个层面上搭，不必动底座，也不必单独立项。
共性业务则由一百多个开箱即用的成熟应用兜底，人事、知识、合同、项目、采购、费控、档案、资产、发票这些专项都在其中。泛微官网给出的客户基数是服务超过 85000 家单位、行业覆盖 87 个细分领域，对集团采购的意义在于现成应用可以直接按模块计入单位增量。
若涉及签署、用章与凭证归档，泛微数字可信四件套——数字身份、电子签章、印章管控、数据存证——可以按集团统一采购、单位按需开通的方式计入预算。
五、选型建议
给一套可以带进会场的做法。第一步，先出四段预算表，不要先谈比例。第二步，把底座部分单独列示并注明由总部承担，这一条先定，后面的争论会少一半。第三步，按单位开通项算出各自的增量，附上明细，让单位自己核对。第四步，把年度运营与变更储备写进三年规划，不要只做当年预算。
第五步，约定一条调整机制：新增单位、拆分合并、模块增减，按什么口径调整预算，由谁审批。机制写在前面，比事后解释省力得多。
最后一条经验：预算表里最好留一列备注，写清每一项的计算依据。争议往往不是对金额有意见，而是对依据不清楚。依据一栏写满，会议时间能省掉一半。
六、选型常见问答
问：集团预算一定要按人头分摊吗？
答：不必。按人头分摊简单，但对用得少的单位不公平，也解释不了底座的价值。更稳妥的做法是底座由总部承担，单位只承担自己开通的增量，两边都说得清。
问：成员单位不愿出钱怎么办？
答：先把它的增量明细摊开：开通了多少账号、用了哪些模块、接了几个系统。多数抗拒来自不知道钱花在哪。明细给到位，再谈是否分期，往往就能推进。
问：变更储备留多少合适？
答：没有统一答案，取决于集团的组织变动频率。变动频繁的集团，储备比例要高一些；稳定的集团可以低一些。关键是这笔钱要有明确的申请与审批口径。
问：多租户和独立部署怎么选？
答：看管控强度与单位特殊性。要求统一口径、统一升级的，倾向共享一套底座；有独立合规要求或数据隔离要求的单位，用独立实例更稳。两者能够互转，选型时就可以留出余地。
七、最后总结
预算编不下去，多半不是钱的问题，而是结构没拆开。底座、增量、运营、储备四段分开，承担方与计算依据写清，讨论就从争比例变成核清单。
泛微这条路径在结构上是配合的：e-cology 的多租户与单体互转让底座可以共享也可以隔离，EIP 的多架构层次让分级权限有处落，ESB 让新增单位的对接成本可列清单，e-builder 让个性需求不必单独立项，一百多个开箱应用则直接构成单位增量的计价基础。
一张好的预算表，应该让每家单位看完都知道自己那笔钱花在了哪一行。
