高顿财经财务信息化讲座系列：业财融合篇

8月14至16日，高顿财经与上海财经大学联合举办的财务信息化管理（FIM）高级研修班在学员们热烈的掌声中圆满举行，见知数据联合创始人王晓青老师为学员现身说法，解析财务信息化管理的架构蓝图和发展路径。本期为大家带来王老师关于业财融合的精彩分享。

王晓青履历简介：高顿财经金牌讲师，见知数据联合创始人和CFO。前GE生命科学集团亚洲工厂财务总监，6-Sigma专家，曾负责财务共享中心搭建。此前曾就职于KPMG。于上海交通大学取得数学学士和MBA学位。

业财融合是少数没有英文单词对应的财务术语。这是为什么呢？我推测是因为中国的业务速度发展太快了。传统的KPI常以ERP内的财务数据为基础制定，而以此为基础做管理和数据分析的问题就在于频率。大部分企业按月关账，意味着每月才能拿到一次数据，面对变化的行业环境或快速发展的业务情况，频率太慢了，是远远不够的。此时业务和销售等前台部门需要数据，以月为周期的数据难以跟上实际情况，而我们作为面向未来的财务专业人士，就要通过财务数据去支撑前段业务发展。而这就推进了企业管理的数字化，告别“拍脑袋”的决策方式，也就开始有了“业财融合”这件很有意思的事情。

业务的经营加上财务的管理，用财务管理的手段结合业务经验去引导业务发展向前。业财融合往往是有数据支撑需求的业务提出来的，希望财务能够“跳出财务看财务，回到财务做财务”，用业财融合给财务工作指明方向。具体来说，就是当业务有数据支持需要的时候，可以跳出财务视角分析财务数据；回到财务岗位时，有扎实的能力和思维能将财务数据和本职工作整理好。

财务需要思想变革，改变模式，需要往前走。虽然有部分成功实现的人和案例，比如一个合格的CFO必须具备“跳出财务看财务，回到财务做财务”的能力，做业务前进方向的指引者，通过全局视角，区分事情的轻重缓急。但对于绝大部分的财务人，这件事还是很难的。首先，做财务是一种选择，绝大多数财务工作人员态度严谨，比较在意安全感，性格比较保守稳健，需要更多安全感和舒适空间。财务部的工作环境相对独立封闭，更容易潜移默化的让人闭塞。所以，让财务人员“走出去”这一点，普遍上是有一定难度的。业财融合的理念是合理的，但真正的业财融合需要的不是单独的超人，不是让某个人“走出去”，变成业财融合的精英，而是建立一个完整的团队体系。

这其中最难的是那个“+”号，业务经验加上财务管理。如何实现这个加号？我们自然而然的会想到搭建业财一体化平台。我们需不需要搭建业财一体化平台？不一定。

为什么这么说？搭建任何一个平台都有两个前置条件，第一个就是需要有足够的量，平台才有存在的意义。业财一体化的前置条件，就是这个公司本身的信息超过了一定的量，意味着公司已经步入了成熟期，有大量稳定的业务流，也意味着业务考核是不太会发生变化的。大公司建立KPI之后变更不易，找供应商来抽数据，建模，测试再上线，动辄耗时数月。所以真正需要搭建业财一体化的企业，是在成熟期，有大业务量，而且形态和指标比较稳定的企业。比如财务报表中，毛利率毋庸置疑很重要，但是毛利率的变化能对公司的经营改变什么呢？生产力，业务和商业模式等共同决定了毛利率，我们都希望毛利率越高越好，但有时候定价权并不在你的手里。有的人会从财务角度出发，可能要把低毛利率的产品线砍掉。比如制造业有很多工厂，制造成本高于收入却仍在生产，从毛利率角度来看为负，是没有存在意义。但是从经营角度出发，很多成本已经投入了，这些沉没成本摊销下来，企业主会发现不生产亏的更多。两害相权取其轻。所以我们要综合考虑企业是否可能会有大量业务变化，以及业务是否是高度依赖于数据指标的。业财一体化平台上有很多信息和数据，的确有很大的潜在价值，但如果没有利用好就会帮助寥寥，有的时候甚至不如业务敏感的一线人员的直觉判断，这也是为什么有些业务觉得财务比较鸡肋，而觉得业财一体化的数据是“nice-to-have”，有当然好，没有也能转下去。

很重要的是，上平台之前先需要花一段时间解决部门间双向沟通的问题，可以的话，最好用半年时间派专人去了解业务上的真实需求，在外资企业这个角色叫做财务分析，或者业务财务，Finance BP，先用 Excel 测试，跑半年磨合，了解业务情况的变化速度和可能性，也给业务足够的时间了解财务有什么数据，理清自己的实际需求和思路，留足时间建立双方的理解和共识，创造良好的反馈机制，消除信息不对称。核心的第一步就是先要有这个人，如果没有这个人解决沟通问题，了解实际需求，后续的平台是很难解决实际问题的。组织架构中必须要有这个角色并留出这个时间，当业务财务在部门间磨合完善之后，再考虑是否需要建立一个平台。如果半年的过程中，判断需求量够大，并且需要大量人力才能做好，再用业财一体化项目来标准化解决这个需求。

总结三点：第一要建立业务财务的角色，如果组织架构中没有这个角色的话。第二是半年时间磨合，实际了解业务部门实际情况和需求。第三是达成共识，建立快速反馈机制，让业务和财务部门互相清楚理解对方有什么和需要什么。业务的需求是一定会变化的，而如果变化的太快速频繁，或者超出财务的预期，而且无法流畅沟通的话，花再多的钱，花再多精力搭建的业财一体化平台都是很难达到预期效果的。

观点1：从我的经验来看，不太赞同“打通”这个说法。首先，集团组织是有类似业务财务的岗位的，比如采购财务专门支持采购部门做账本的工作，销售财务制定定价批准跟走等一系列方案，制造财务跟踪生产制造是否合理，等等。回到业财一体化平台这个问题，我不太赞成的原因有几个：首先成本很高，打通吃力不讨好。其次把这么多信息都汇集在一个中央系统里做，需要系统能力很强大，很包容，同时既满足财务需求，又满足业务需要，又要兼顾稳定性和灵活性，真的挺难的。所以我认为不用从并联变成串联的状态，在系统之间搭一些桥就能解决问题。不然如果任意流程出问题，整个流程就断掉了，系统稳定性就不好了，数据就流不下去了，反而可能对基本的财务业务都产生了影响。

观点2：我对打通的定义为“接口”。业务部门有专业信息化系统，需求明确的话做接口，做集成。财务需要的相关的第一手的数据需要从业务系统来，需要接口接入到相关业务系统，做融通，而业务也需要调用财务数据分析。我认为只是做需求的对接，通过接口让数据流转，让财务和业务都能看到需求的信息和数据，而不是全部系统整合为一套系统。

观点3：打通看具体情况，我更赞成数据的汇总，而不是流程打通。流程是不一体化的，但数据是需要汇总的。同样说的不是流程的串联，而是业务和财务数据的对接，分析之后的汇总。

“财务数据中台/数据仓库”这个概念很火，但其实很少有人去做。财务数仓把数据抽上来，在同一个地方做汇总，是很有价值的。一体化原本是个比较中立的词，但随着说的越来越多之后，打通和一体化的潜台词变成了要做一个大而全的东西。如果做不到流程的大而全，就做到数据的大而全，如果这也做不到，就保证数据抽上来汇总，让数据可以流通起来。

这里要和大家分享的是，从个人经验来看，不建议去做大而全的一体化打通项目，这是一个风险很大，很容易出问题，有很大隐患的事情。当然这种项目做成功了就是企业的核心系统，有难度，又消耗大量资金和时间，如果能做成功，可以“一战成名”。实际上，大部分这种项目会受限于资源的掣肘，实操起来和规划的时有很多差异。如果不做流程的打通，而是让数据通过集成做到自由流转。

首先，很多人是在盲目使用“业财一体化”这个词的。绝大多数人眼中认为的 IT系统，本身是一体化。就好比企业全公司都只用 Oracle，兼容性一定是很好的。就好像全家所有东西都只用苹果或者小米，兼容会非常顺畅，用起来很舒服，一体化，大而全。但代价是只能使用这些操作系统和产品，如果有些功能不支持，没法换，只能等待，而这对企业可能是很严重的问题，是等不起的。之所以反对盲目上一体化系统，是因为虽然体验和满意度很好，但对企业长期发展很不友好，会导致企业的发展规划跟着信息化厂商的逻辑走了，而厂商的产品更迭往往是市场平均逻辑：市场上有许多客户有需求，愿意买单，厂商才会做。而 IT 是业务的支撑系统，如果业务是具有独特性和创新性的，快速增长的或特别复杂的，只有一个市场平均水平的支撑系统是不够的。比如小米，在扩张期通过与生态体系内的大量公司合作分工，创造出了大量物美价廉又体系统一的各种产品，对于这种业务高速发展，模式创新型的公司，一个牺牲了兼容性的大而全的一体化系统，或者一个只有市场平均水平的系统，都会成为发展的桎梏。

现在市场上最好的技术和前沿的解决方案，很多都不在大厂，而在规模敏捷的初创科技公司手里。面向未来的企业需要有一个足够敏捷的系统，支持快速尝试，采用和推广这些最前沿的方案，驱动业务的创新和发展。系统的重点是在稳定的基础上，把兼容性做好，可以很灵活快速的接入新产品，系统分开本身并不是坏事。

在系统刚上线的一小段时间里，用户体验是向下走的，然后再逐步回升，形成一个J曲线。而在项目初始的体验谷底期，业务很可能觉得平台不好用而抱怨。所以不要认为上平台只是上功能，上线前的工作很多时候其实就决定了系统是否能够获得成功。

上系统需要经历一些环节，比如测试和培训。很多人都认为培训很鸡肋，没有用，效果很糟糕，后来甚至变成发成一个文档过去。培训系统本身是没有什么作用的，但我们应该把培训变成一个给业务做培训，让他们了解财务的机会，消除信息不对称。在通用电气的时候，我们每季度一次给所有业务销售培训专业财务知识，灌输财务数据能给业务发展带来的价值。业务能够操作好业财一体化平台的前提条件是要能看的懂，知道有什么指标，有什么用，其次才是系统都有什么功能和具体如何操作。给大家的一个小建议是，之后在企业上系统之前，多花心思和时间做好做足培训，邀请高级别的业务负责人，按他的时间多培训几场，你会发现虽然分工不同，业务人员对财务知识其实是很渴望的。

另外分享一个如何做数据集成的心得。实操经验是尽量做单向的集成，双向的集成很容易出问题。抽完数据处理后再回写，就意味着数据生成源增加了一个入口，就产生了新旧数据间对账和发生矛盾后如何覆盖的问题。除非 IT 能力很强，又非常懂业务，对字段处理和各种可能发生的情况做了非常详尽的考虑，不建议仓促进行双向数据流集成。

总结一下，一体化原本是个中立的词，小而美的产品在兼容性可靠的前提下，很灵活，容易达成效果，大概率比上大型一体化项目效果要好很多。大型项目上线后一定会出现体验的J曲线，要借这个机会做好前期工作，建立快速反馈机制，消除信息不对称。