全维时代:当管理会计不再纠结维度的限制

管理会计的概念体系是一个比较大的范畴，广义的管理会计包含了前面我们所谈到的经营分析，而相对狭义的管理会计则由收入分成、成本分摊和盈利性分析三个核心部分所构成。而在这三个部分，都离不开维度的概念。在传统的技术条件下，维度的应用受到了不小的限制，而智能时代大数据的技术框架可能对此有所帮助。我们在这里从财务能够理解的技术角度来看一看财务如何从维度的限制中得以突围。

管理会计眼中的维度

首先，我们来看一看维度和管理会计是怎样的关系。在《元数据和大数据：不一样的经营分析》中我曾经介绍过，元数据是“数据的数据”，用维度和维值来描述数据是我们对经营情况展开分析的重要方式。而管理会计从其功能上讲，可以是经营分析的底层支持，经营分析对基于多种维度的不同视角的观察，同样对管理会计提出了要求，需要管理会计能够将收入和成本等经营信息基于不同的维度视角进行加工处理，并达到最终多维度成本盈利分析的效果。从这个角度来看，维度和管理会计存在着密不可分的关系。

下面我们再来具体谈一谈维度这个事情。

1 如何设计维度？

维度从本质上讲是我们看事情的视角。正如盲人摸象这个故事中所蕴含的道理，当我们对一个事情进行认知的时候，很难一次性看到它的全貌，在正常情况下，我们看到的只是一个视角下的不完整的认知，随着视角的不断增加，我们所获得的观察对象的信息会不断丰富起来，从而帮助我们的认知水平不断提升，并最终有可能还原出接近真实的场景。为什么要说接近真实？客观讲，我们现在很难说对那个时期能够做到真正意义上的完整认知。

当我们知道，维度是一个看事情的视角后，在进行管理会计的维度设计的时候，就可以重复利用这一概念了。由于管理会计的最终目的是辅助我们进行经营决策，所以，回答“需要什么维度来看管理会计”的本质就在于需要用怎样的视角来看经营。

需要用怎样的视角来看经营？

在缺乏管理会计体系支撑的情况下，我们能够用来看经营的视角是十分有限的，很多企业也仅仅能够依赖会计核算系统，从会计科目和组织维度来看经营。但当我们引入管理会计后，维度就有条件进行一定程度上的扩展。

如果我们的资源有限，从哪里开始扩展呢？

从逻辑角度讲，我们最应该扩展的维度是从对看经营，指导经营最为有价值的视角开始的。比如很多公司的起点会选择从产品和渠道两个维度下手，因为产品和渠道多绝大多数企业来说都是高度影响其经营结果的视角。随后，不同的行业开始有了不一样的选择。如，以工程交付方式为主的企业可能会优先考虑对工程项目维度的考察，咨询行业会从增加咨询项目的维度，高科技行业会从增加研发项目的维度，电信、金融会从增加运营的维度，零售行业会从增加客户、客群的维度等等。当然，上面所罗列的这些例子并不一定是所有行业公司的一致选择 ，而实质上，这些行业的公司往往会同时产生多个新增维度的需求。但我们必须要意识到，维度的资源是有约束的，当我们无法一下扩展多个维度的时候，要基于最有用的视角来逐步扩展维度。

2 维度有怎样的特点？

那么对于维度来说，又具有怎样的特点呢？

1 维度值应当具有唯一性

一方面，作为维度，应当是具有清晰的涵义和边界的，也就是说，当我们用维度来描述经营情况时，同样的描述，也就是维度值应当具有唯一性。比如说，很多公司在搞网络销售，如果我们用“网销”作为一个维度值，而这个维度值同时出现在了产品和渠道两个维度中，那么就会导致用户的认知困扰，不知道财务在说的事情到底针对产品还是针对渠道。

2 维度应当具有层次性

另一方面，维度应当具有层次性。比如说对于组织这个维度，我们可以首先定义法人这个层次，进一步，在法人下定义事业部的层次，再细分，可以细分如研发、销售、生产、售后的部门类的层次，最终再落到具体部门上。一个层次清晰的维度体系能够帮助我们更好的基于层次进行自下而上的数据汇总，从而获得更多的管理信息。

3 维度之间是叉乘关系

再有，维度之间是叉乘关系。在管理会计中，如果我们用多个维度来描述一件事情，我们希望看到的是几个维度维值之间的叉乘结果，比如有一笔差旅费，我们希望看到的是深圳分公司、XBOX产品、直营渠道、2017年6月、差旅费、1888元这样一条记录，而不是仅仅在各自维度上去反映情况。

3 收入分成和维度

对于收入来说，通常情况下我们将其与维度的匹配指认会相对容易。通常情况下，我们在发生一笔销售的时候，销售的属性还是相对清晰的，比如说卖的是什么产品，谁卖出去的，通过什么渠道销售的，客户是谁，这些关键信息往往在这笔销售发生时从客观上讲是比较清楚的。在这种情况下，我们要获得多维度的收入分成信息，最为核心的是要在销售的源头进行多维度的交易记录，也就是基于每一笔订单，清晰的记载相关维度信息。

如果在源头没有进行记载，后续再基于合并记载的销售收入来进行拆分难度就会很大，很多时候需要基于主观设定的规则来进行，这将导致分成质量的降低。因此，在进行管理会计的收入分成的系统化时，我们需要尽可能的深入业务前端，通过在交易系统中获得原始数据来达到最佳效果。

当然，有些时候收入即使在源头也无法完全清晰的制定到各个维度上去，这个时候还是需要基于一定的规则来进行支撑处理。

4 成本分摊和维度

对于成本来说，如果要将成本信息和维度进行匹配，面临的情况会比收入分成更为复杂一些。

首先，对于一部分成本来说和我们的销售订单是直接相关的，这种成本往往比较容易处理，与收入一样，我们能够直接指认大部分的成本信息。但对于成本来说，一定有相当大比例的中后台成本，是无法直接进行明细维度指认的。在这种情况下，就需要依赖其他的方式来进行处理。

通常情况下，我们需要在成本发生的各类系统中尽可能的去清晰的记载一些维度信息，比如在报销的时候，我们可以要求报销人指定可以确定的直接维度信息，如部门、产品、项目等等。当然，这种指定是有局限的，有些维度我们无法指认到底层的维度值，有可能停留在父级维度值上，甚至有些维度根本无法指认，必须依赖后续的成本分摊来进行。

对于成本分摊来说，又是一个很大的话题，成本分摊的方法也有很多，对于管理会计来说，最为重要的是要选择合适的成本动因和分摊路径，这里就不再展开赘述。

5 如何利用维度进行盈利性分析？

当我们通过对收入和成本的维度信息匹配处理后，就具备了进行多维度成本盈利分析的可能性。

理想的多维度盈利性分析的数据基础应该是我们所预先设定的维度都得到了充分的匹配。也就是说我们在底层数据中能够基于各个维度最底层的维度值展开叉乘，且所有叉乘记录上都应该有相应的值。当然，对于无意义的叉乘，可能获得的是空值，但有业务含义的叉乘结果都应该能有相应匹配的叉乘值。

在这个基础上，所谓的多维度盈利分析就是能够对单一维度，或所有维度中的某几个或全部维度向上进行灵活的汇总分析，而汇总时，在任何一个维度的层次上都是可以做异步汇总的。通过这样一种模式，我们基本上能够从宏观到微观，从各个不同的层次深度和不同的视角来看待企业的经营情况，比如我们可以看到所有事业部所有产品的收入和成本情况，某个事业部所有产品汇总的收入和成本情况，也可以看到每个事业部每个产品的收入和成本情况。这从管理上赋予了我们最大的灵活性。

管理会计团队的多维之痛

从前面的介绍中我们能够了解到，维度赋予了我们观察企业经营情况的不同的视角，而要想全面的看透经营情况，视角自然是越丰富越好，也就是说我们所能够构造出的维度体系越丰富越好。但是在实践中要做到这一点并不是容易的事情，因为多维度底层收入成本数据的构建和应用是有难度和代价的。

首先，多维度底层收入成本数据的构建需要依靠大量的基础工作来进行支撑，如我们前面所谈到的数据源头的信息采集，业务流程中的维度值的标记，需要我们完整的梳理端到端的信息系统，并进行细致耐心的系统改造。

其次，对于基于规则的收入分成和成本分摊需要系统进行大量的计算处理，一方面，需要系统的计算能力足以支持，另一方面系统处理的时效性要能够保障。往往我们是无法直接从源系统直接抽取数据进行加工处理的，需要通过数据仓库先进行数据的抽取和存储，并在此基础上再进一步进行加工处理，而在某些情况下，数据之间还存在处理的先后逻辑关系，这会导致数据加工处理出现排队的情况。很多时候，管理会计人员是在痛苦的排队等待中迎来绝望的。超出预期的数据处理时间，将使得数据结果因时效性的丧失而价值大大降低。

最后，当我们完整的形成了多维度收入和成本的底层数据后，报表的出具同样受制于系统性能的限制。由于叉乘关系的数据是极其庞大的，每增加一个维度，带来的都可能是几何量级的数据的增长。而在如此海量的数据上进行分层次多维度组合的数据汇总，不难想象，当系统性能不足以支持的时候，漫长的等待同样让人绝望。

从上面的分析我们能够看到，对基于多维度成本盈利分析的管理会计来说，技术性能对于维度的扩展是重要的影响瓶颈。而如果我们要想获得丰富全面的管理会计分析视角，也就是进行任性的维度扩充时，首先要解决的就是技术架构的性能问题。

技术进步下的维度破局

当我们看到了制约管理会计的瓶颈后，我们从技术角度来聊一聊如何进行破局。首先，我们从数据库技术的发展来看看有怎样的破局机会。

1 关系型数据库对于维度的处理

首先，我们还是来看看最为传统的关系型数据库。关系数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。我们可以简单的把关系型数据库理解为是一种二维的表格，一个或多个二维表格构成了关系型数据库。可能你听说过的Oracle、DB2、Microsoft SQL Server、Microsoft Aess等数据库都是关系型数据库。

当我们使用关系型数据来进行数据分析时，需要怎样处理呢？关系型数据库需要基于多个表之间的关联关系进行多次的表链接来实现数据查询，就像一个用一个一个小铁环链接起来的铁链，环环相扣，完成最终的数据处理。这种模式下，如果是小数据量的查询问题是不大的，但是当面对多维度海量数据时，这样的数据链接方式非常耗时，性能问题凸显。对于开发人员来说，关系型数据库的开发周期较长，成本也较高，但好处在于它消耗的存储空间较少，容易扩展。不过这些优点显然不是我们在管理会计的业务应用中所需要的。

2 多维数据库的维度增强

面对关系型数据库在处理多维度大数据量的不足，多维数据库的出现让苦难中的管理会计人员看到了曙光。那么什么是多维数据库呢？

在讲到多维数据库的时候，理解起来还是很抽象的，因此，经常会看到一个立方体的概念被用来解释多维数据库。那么如何看待这个立方体呢？这个立方体背后的含义是多维数据库中，数据被存储在了一个多维数组里，如果用立方体来表达，立方体的边代表了我们所说的维度，立方体本身被叫做度量或事实，其实也就是我们经常理解的具有数量特征的统计对象，比如金额，销量、库存等等。

在大立方体的一个小立方体块中，立方体的边，也就是维度上可以理解有不同的刻度，这些刻度就是我们所讲到的维度值，当多个维度上的刻度确定后，也就是维度组合的每个维度的维度值确定后，就可以锁定一个具体的多维度组合出来的结果，这个结果常常被称之为切片。实际上我们在管理会计中所说的底层的数据记录，在多维数据库中就是由这样一个个切片所组成的。

那么为什么多维数据库能够更好的提升维度组合后的查询效率呢？本质上在多维数据库中存在着大量的冗余，使用了空间换时间的方法，从而提升了运算效率。

这里要科普一个小术语，在多维数据中的数据立方体被称之为Cube，经常会听到不少海波龙的顾问用到这个词。另外，还需要知道的，在多维数据库领域，使用的比较多的是Hyperion（海波龙） Essbase的数据库，这也是为什么Oracle收购的海波龙系统会成为预算、合并、管理会计最为常用的支持系统，这和它善于处理多维度数据记录是密切相关的。

从这里，我们能够看到，对于处理多维数据，多维数据库比关系型数据库更前进了一步，但我们也必须知道，多维数据库仍然有它的局限，当维度扩展到一定的数量后，仍然会有性能的瓶颈。因此，不少海波龙的顾问会告诉你，在业务设计上适当控制一下维度的需求。

3 大数据架构下的维度再突破

而当大数据技术得到快速的发展和普及后，管理会计们对维度的渴求再次有了进一步扩展的机会。

实际上，对于数据处理我们需要关注时效性和数据量，并据此来考虑技术架构。对于时效性要求很高的数据，我们可以称之为实时数据分析。实时分析现在的技术也较以前有了很大的改善，特别是内存数据库的出现，也极大的提升了分析效率，目前比较新的海量数据实时分析工具有SAP的HANA等。我们可以看到，现在就有 一些企业是选择这样的工具来进行管会的处理。但我看来，管理会计对于时效性的要求并不需要追求实时性，离线数据分析往往已经能够满足我们的需求，反而是对于数据量的处理能力更为重要。而在数据量方面，SAP的HANA之类的内存数据库受到总内存的限制，往往可以处理相对一般量级的数据，但在BI量级，以及海量数据下就会产生一定的压力。

我们在前面所讲到的多维数据库往往能够处理的是BI量级的数据，但在海量数据下，它的压力就相当之大，要么负载不了，要么成本过高。而基于分布式文件系统的大数据架构能够在海量多维数据的处理上有所作为。

以最常见的Hadoop为例，它在进行多维分析处理的时候，能够充分利用其处理非结构化数据的能力，采集包含大量冗余信息的数据，同时将这些大量冗余的维度信息整合到事实表中，简单的说，就是用Hadoop强大的塞垃圾的能力，进行更大量的数据冗余，把空间换时间的事业进行的更加彻底。在这种情况下，业务人员能够基于冗余的维度，进行更加灵活的分析视角的切换。另外，Hadoop中的MapRce（一种编程模型，帮助IT人员把程序在分布式系统上运行）有着强大的并行处理能力，这个使得我们在任性扩充维度后，系统的性能开销并不会显著增长。使用这种方式，我们在Hadoop平台上构造了一个巨大的数据立方体，包含着随意任性多的维度，管理会计师们是不是都在流口水？

可以想象，未来的管理会计将有可能突破维度的限制，我们将能够更多的关注在如何构造维度来更好的反映我们的经营情况，而不必再去担心维度在性能上的制约了。这就是我们要说的管理会计全维时代的到来。