财务模型与电子表格查询规模建议

2.1 财务模型规模

维度数备注： ≤20、21~30 和 >30 是公司当前用于项目方案评审的治理分档，不是产品能够创建的最大值，也不是 PA、HFM 或 Oracle 公布的统一性能边界。进入评审区后，应结合维度业务必要性、成员规模、有效组合、典型表格和实际数据量完成专项验证。

本建议统一定义：成员数 ≥1万且<3万 为大维度，成员数 ≥3万 为超大维度。后文原则上直接使用“大维度”和“超大维度”，不再重复具体成员数。

2.2 表格规模

表格规模按“行组合数 × 列组合数”计算，应在隐藏空行、隐藏零值之前评估。不能因为最终只显示少量非空数据，就认为一个巨大的行列交叉组合是安全的。

2.3 最重要的判断

成员数达到 1 万时就应进入大维度评审，因为两个 1 万成员维度无约束交叉已经达到：

10,000 × 10,000 = 1亿

成员数达到 3 万后属于超大维度。两个刚达到超大维度门槛的维度同时无约束展开，理论组合已经达到：

30,000 × 30,000 = 9亿

因此公司建议把 1 万作为大维度评审起点，把 3 万作为超大维度专项方案起点，并重点控制：

• 一个模型里分别有几个大维度和超大维度。

• 大维度和超大维度之间有多少真实有效组合。

• 是否把这些维度同时放在表格行列轴。

• 查询时是否通过组织、区域、产品线、项目类型等 POV 缩小范围。

• 超大维度应保留在核心模型、拆到明细模型，还是改为层级、属性或表单字段。

4.1 系统维度与业务维度

预算和经营计划模型通常包含六个基础系统维度：

根据业务需要还可能增加 Currency、DataSource、Product、Project、Channel、Customer、Movement 等维度。

4.2 分级建议

维度较多时，应优先按业务过程拆模型，例如：

• 收入预算与费用预算分开。

• 人力预算与财务预算分开。

• 核心计划模型与客户、合同、SKU 明细分析模型分开。

• 法定合并模型与管理分析模型分开。

拆分模型并不意味着数据割裂。可以通过映射、数据同步和汇总报表连接不同模型，但不必让所有业务对象共同出现在一个坐标空间中。

5.1 按维度类型评估

5.2 维度规模分级

同一模型中，1 个大维度可受控使用；1 个超大维度必须限定默认访问范围。存在 2 个大维度或超大维度时，必须说明有效组合、典型 POV、最大表格和增长预测，其中两个超大维度不得自由交叉。3 个及以上大维度优先拆分业务过程、保留时专项验证；3 个及以上超大维度原则上拆分。

成员数按当前值和三年预测值评审，不能只看上线时规模。

5.3 层级设计

• 避免一个根成员直接挂数万叶子成员，应建立有业务意义的分支，例如区域、产品线、项目类型、客户等级。

• 一个父成员的叶子后代超过 1 万时，不建议在交互表格中直接使用“全部后代”。

• 层级用于组织和汇总，不应为了技术分组增加没有业务含义的中间层。

• 同一成员存在多套汇总口径时，应控制共享关系数量，避免大量重复路径。

• 某张表不使用的维度应固定到“不区分XX”等占位成员，不要生成无意义的交叉组合。

6.1 必须评估有效组合

任意两个大维度或超大维度之间，通常不是所有成员都能任意组合。例如：

• 产品只在部分组织销售。

• 客户只属于特定区域或渠道。

• 合同只对应少量项目。

• 员工只属于一个或少量责任中心。

应统计真实允许的组合数量，而不是使用全部成员的笛卡尔积。

有效组合必须在成员选择和表格展开时生效。仅在表格最后把无效组合显示为空白，仍然会产生大量无意义行列。

6.2 多个大维度的放行条件

同一模型存在两个大维度时，必须满足：

1. 每个维度都确实需要独立填报、汇总、筛选或授权。

2. 能说明两个维度之间的真实业务关系和有效组合规模。

3. 日常表格不会同时展开两个维度的全部成员。

4. 至少一个维度通常放在 POV，或限定到一个业务分支。

5. 最大表格满足查询规模建议。

6. 按三年增长后的成员量完成验证。

同一模型存在三个及以上大维度时，应优先拆分业务过程。确需保留时，必须逐对说明有效组合，并证明日常表格不会形成多个大维度的自由交叉。

6.3 超大维度的方案选择

超大维度不直接按“能不能建”判断，而应根据业务用途选择方案：

一个超大维度保留在核心模型时，必须同时明确：

1. 业务必要性：为何不能改为层级、属性、表单字段或明细模型。

2. 访问入口：用户先选择哪个组织、区域、产品线或项目类型，再进入明细范围。

3. 组合约束：与其他大维度或超大维度之间允许哪些有效组合。

4. 展开上限：日常表格最多展示多少成员、多少行和多少单元格。

5. 增长安排：按三年成员量评估，并约定何时拆分或归档。

6. 验证范围：覆盖最大权限用户、最大业务分支和高峰并发。

同一模型存在两个超大维度时，还必须同时满足：

1. 两个维度都确实需要独立填报、汇总、筛选或授权。

2. 有明确的有效组合关系或业务范围约束。

3. 日常表格不会同时展开两个维度的全部成员。

4. 至少一个超大维度固定在 POV，或限定到一个业务分支，不能依赖用户每次自行缩小范围。

5. 最大表格满足查询规模建议。

6. 按三年数据量和预期并发完成专项验证。

任一条件不满足，应采用上表中的模型拆分、调整为层级或属性、专用查询等方案。三个及以上超大维度原则上按业务过程拆分，不建议通过增加硬件直接放行。

6.4 典型场景

7.1 填报表

填报表强调快速打开、清晰录入、保存校验和多人并发，规模应比查询表更小。

超过建议值时，优先采用：

• 按组织、责任中心、产品线或项目类型拆分表单。

• 把 Scenario、Version、Year、Entity 等放在 POV。

• 分开设计填报表和分析表。

• 使用有效组合隐藏无效成员，而不是让用户面对大量空行。

7.2 查询分析表

以下设计属于高风险：

• 两个大维度或超大维度同时放在行轴并展开全部叶子。

• 一个大维度或超大维度放行、另一个放列，并依赖隐藏空值缩小最终结果。

• 多个行维度都使用“全部后代”。

• 在同一张表中同时展示大量版本、场景、年度、期间和业务明细。

• 把明细导出需求包装成交互式财务报表。

7.3 POV 设计原则

对于大维度和超大维度，顾问应优先设计“先选范围，再看数据”的使用路径：

1. 先选组织、区域、产品线、项目类型等业务范围。

2. 再在行列中展开受控成员集合。

3. 需要跨范围比较时，使用汇总层级，不直接展开所有明细。

9.1 IBM Planning Analytics（TM1）

IBM PA 允许一个 Cube 包含 2 到 256 个维度，但官方同时强调维度数量、稀疏度和维度排列会影响性能。PA 的高理论上限不应理解为预算模型适合建立几十个维度。

PA 的实践启示是：

• 多维模型通常高度稀疏，不能只看理论单元格总数。

• 大维度或超大维度本身并非绝对问题，关键是查询集合、汇总方式和非空筛选能否有效缩小范围。

• 小而稀疏的维度与大而稠密的维度需要区别设计。

• 对大型查询应设置单次查询和整体查询的资源保护。

• TM1 Web 默认工作簿单元格数为 50 万，导出阈值为 100 万，可作为公司交互查询与导出分界的参考。

9.2 Oracle Hyperion Financial Management（HFM）

HFM 提供 Scenario、Year、Period、Entity、Value、Account、Intercompany、View 八个系统维度，并支持增加 Custom 维度。Oracle 说明 Custom 维度数量可以扩展，但增加过多维度可能影响性能。

HFM 的实践启示是：

• 财务语义应优先由标准维度承担，例如 Entity 负责组织与合并，Account 负责科目，View 负责 Periodic、YTD、QTD 等期间口径。

• Custom 维度应与科目业务相关，用于产品、市场、渠道、变动等必要分析，不应把所有明细对象都做成 Custom 维度。

• 数据通常录入在基础成员，父成员通过汇总获得结果，因此父成员下的叶子规模直接影响汇总范围。

• 不适用的 Custom 维度应使用 None/不区分成员，避免无业务意义的交叉组合。

9.3 Oracle Planning / Essbase

Oracle Planning 最多支持 32 个维度，但官方最佳实践建议少于 12 个。该数值是 Oracle Planning 的产品最佳实践，不直接作为 DeepFinance 的维度数量限制。Oracle 还建议使用 Valid Intersections 限制无效维度组合，并把大型明细表拆成更小的表单。

Oracle 的实践启示是：

• “最大支持数量”和“最佳实践数量”必须分开。

• 浏览器展示、填报表和批量导出应使用不同上限。

• 有效组合应在成员选择和表格展开阶段生效。

• 多个稀疏维度同时放在行轴会显著增加表格规模。

10.1 评审结论

11.1 方案阶段

• 确认业务过程是否需要一个模型承载。

• 完成维度、属性、层级和表单字段的角色判断。

• 获取当前成员量、增长预测和历史数据量。

• 识别大维度和超大维度，并为每个超大维度确定使用方案。

11.2 详细设计阶段

• 设计典型填报表和查询表。

• 明确哪些维度放 POV、行、列。

• 对大维度和超大维度设计业务分支、默认筛选和有效组合。

• 对超大维度形成保留核心坐标、调整为层级或属性、拆分模型或专用查询的书面结论。

• 形成模型规模评审结论。

11.3 用户验收阶段

• 使用接近生产的数据量验证，不使用少量样例数据代替。

• 同时验证普通权限用户和最大权限用户。

• 覆盖最大父成员汇总、多个期间口径和最大表格。

• 并发数至少达到预计高峰，并保留一定增长空间。

11.4 上线后的变更

出现以下变化时应重新评审：

• 新增一个 Common 维度。

• 任一维度成员数增长超过 20%。

• 任一维度从普通规模进入大维度，或从大维度进入超大维度。

• 模型新增第二个大维度。

• 新增超大维度，或已有超大维度数量增加。

• 最大表格规模增长超过 20%。

• 有效数据量或高峰并发增长超过 30%。

标准模型

多个大维度有条件通过

超大维度有条件通过

建议拆分