（一）多维报表的实现

通过费用的多口径归集和多路径分摊，就可以得到成本对象的成本计算表，如表4-9所示。

表4-9 成本对象的成本计算表

成本对象可以关联不同口径，如图4-25所示。

图4-25 成本对象关联不同口径

成本对象关联不同口径，结合成本对象的成本计算表，就可以得到不同维度的成本计算表，如表4-10所示。

表4-10 不同维度的成本计算表

通过不同维度的成本计算表，就可以进行多维度展现了，如表4-11所示。

表4-11 成本报表的多维度展现

多维度展现，其表现形式是成本分析的万表同源。万表同源的实现机制，则是费用分配的百口归一。也就是说，费用分配的百口归一，为成本分析的万表同源创造了前提，为多维度展现提供了基础。

百口归一，就是任何类型的资源消耗，任何口径的费用归集，全部分摊到成本对象，形成成本对象的成本计算表；万表同源，就是所有维度的成本查询，所有指标的去向追溯，全部来源于成本对象的成本计算表。"百口归一"，"万表同源"，是形象但并不夸张的说法。我们介绍了多口径归集，所以对百口归一的"百"就不用再解释了，这里解释一下万表同源的"万"。

成本对象是多维组合，就算只有客户、产品、作业、部门四个维度。这四个维度分别有多个属性，任何一个属性又可以关联其他的主数据，从而自动带出其他主数据的多个属性。例如客户有专营业务员属性，专营业务员的主数据又有性别、年龄、籍贯等属性。所有这些属性均可以作为维度且进行任意组合，从而产生上万张各有业务意义的成本报表。当然了，如果有人坚持眼见为实，一定要我把这上万张成本报表都画出来，那我是没办法做到的。我用手指着月亮，你却盯着我的手。

多口径归集和多路径分摊确实是一项比较艰辛的工作，不过这种艰辛通过多维度展现可得到足够的补偿，更何况后面还有数据分析和数据挖掘的红利，以及应用价值的惊喜，能有这些回报，所以付出是值得的。如果读者认可了这一点，那么作者的付出也是值得的。

多维报表查询在实务中往往是一个递进过程。例如先查询各客户的成本，如表4-12所示。

表4-12 各客户成本

发现某客户的成本异常后，下钻查询该客户各产品的成本，如表4-13所示。

表4-13 某客户各产品的成本

发现该客户某产品的成本异常后，下钻查询该客户该产品的各部门消耗的成本，如表4-14所示。

表4-14 某客户某产品各部门的成本

发现该客户该产品某部门的成本消耗异常后，下钻查询该客户该产品该部门各作业消耗的成本，并最终找到成本异常的原因，如表4-15所示。

表4-15 某客户某产品某部门各作业的成本

可以看到，这是一个顺藤摸瓜的过程。之所以顺藤能摸到瓜，是因为这条藤是成本计算时的各条分摊路径相互交织并逐层递进形成的，否则不仅摸不到瓜，反而可能摸到一个大疙瘩。

（二）多维表与二维表

多维表基于数据仓库的数据模型，是"维度加指标"模式；二维表基于数据库的数据表或视图，是"字段加记录"模式。多维表和二维表分别通过字段关联和主键关联，可实现横向到边、纵向到底的查询。由于关联是无止境的，多维组合的数据量是指数级的，所以横向到边、纵向到底，理论上近乎横向无边、纵向无底。

多维表和二维表的展现形式不同。多维表的展现形式如图4—37所示。

表4-16 多维表示例

二维表的展现形式，如表4-17所示。

表4-17 二维表示例

除了展现形式不同，多维表和二维表还有其他不同。

二维表侧重反映流程化的业务过程，例如001号采购申请单采购某商品100个，二维表可查询执行采购申请已下达订单的数量80个，采购订单已入库的数量60个，采购入库单已开具发票的40个，采购发票已付款的20个。多维表侧重反映模型化的分析过程，例如某商品本月采购申请数量100个，订单数量100个，订单数量与采购申请数量不一定存在关联关系。

二维表可展示很多业务属性，例如客户的发货地址、电话、传真、邮箱、联系人等。多维表从数据分析的需要出发，在模型中不一定包括类似数据。

（三）多维表与报表模块的报表

多维表与报表模块的报表，本来没有什么可比性，但既然都叫报表，我们还是对比一下。

（1）多维表可下钻上卷，是活的；报表模块的报表是行列固定的，是死的。可以想一想，如果我们需要在不同的查询间切换，两者会有什么不同。

（2）多维表不需要设置单元格公式；报表模块的报表需要设置单元格公式。可以想一想，如果一张报表有上万条数据，两者会有什么不同。

（3）多维表的维度是自动维护的；报表模块的报表需要人工维护。可以想一想，业务系统有成千上万的客户或产品，如果增加了几位客户或几种产品，两者会有什么不同。

（4）多维表是基于数据仓库的，计算可瞬时完成；报表模块的报表是基于数据库的，计算需从最底层取数。可以想一想，生成一张新报表所花的时间，两者会有什么不同。

（5）多维表的分析是基于数据模型的；报表模块的报表分析是基于数据表的。可以想一想，如果需要进行不同企业、不同期间的对比分析，需要进行比重、比较、趋势分析，两者会有什么不同。

（6）多维表的指标为支持不同场景的反复使用只需一次定义；报表模块的报表项目为支持不同场景的反复使用需要反复定义。可以想一想，如果有成百上千个不同的场景使用同样的指标，两者会有什么不同。

（7）多维表不用写指标汇总公式、表间取数公式、计算稽核公式；报表模块的报表需要写汇总公式、取数公式、稽核公式。可以想一想，如果指标层级多，关系复杂，两者会有什么不同。

报表模块仅仅是为了做法定报表，满足工商、税务、国资委等的对外披露要求，所以也许不应该进行这种对比。但实务中有的企业将报表模块定位错误，用于了内部管理，所以我们还是进行对比，以便企业能够将其重新定位。如果这种对比伤害了报表模块的开发者，那我就在此道歉。不过，我真不是故意的。

针对需求分析制定的解决方案，其总体框架即多口径归集、多路径分摊和多维度展现，适用于所有类型企业的多维组合成本项目，但共性之外还有个性，具体到每家企业还需要进一步具体化，即结合每个行业每家企业的特点制定针对性的解决方案。也就是说，我们先谈解决方案的普遍性，后谈不同行业不同企业的特殊性。

实践是丰富多彩的，场景是千变万化的，决定了成本的归集与分摊工作是错综复杂的。常说兵来将挡，水来土掩，对于每一个具体问题，阐述其解决方案总是相对容易的；而兵和水一起来，对于众多的具体问题，阐述一个统一的解决方案，则是相对困难的。为了阐述的方便，在这里对解决方案进行示例时，有一个重要的假设前提，那就是具体的某项费用，其归集口径是唯一的。如果没有这个前提，示例将极其复杂，几乎没有办法进行。

那么这个前提存不存在呢？当然有可能不存在。例如发生业务招待费100元，有10元是归集到某位客户的，有60元是归集到某个部门的，有30元是归集到某个部门某位客户的。对于这样的情形需通过多口径归集解决，即归集到客户的要向部门分摊，归集到部门的要向客户分摊，这样等于将业务招待费100元归集到了"客户+部门"这个唯一的口径。这个已归集到"客户+部门"的业务招待费100元，就是示例的基础，它是客户、部门之外其他维度的共耗费用。示例不再考虑专属费用，因为无论是专属于客户的费用10元、专属于部门的费用60元，或专属于"客户+部门"的费用30元，都已经通过多口径归集，统一到了"客户+部门"这个唯一的口径，下面只用示例共耗费用的多路径分摊。简单地说，导致示例前提可能不存在的问题已经解决了，这一前提已经被创造出来了。它可以作为我们进一步向前讨论的基础，可以使讨论使用的示例是脉络清晰的。

以下我们示例多维组合成本在不同行业的解决方案。