这些年做财务信息化，参加过很多项目启动会，发现一个挺有意思的现象：财务信息化项目，需求几乎都来自财务，但真正由财务负责人主导并推进成功的，其实并不多。 粗略看，大概也就三成。大多数企业最后还是会把主导权交给IT、信息化部门，或者由老板亲自盯。

 

但也正因为少，这三成里反而更容易看出门道。

 

今天分享三个令我印象很深的案例。三位都是财务负责人，三家公司情况也都不同。表面上看，都是“财务在推财务信息化”，可项目走的路径、遇到的问题、最后的结果，差别非常大。

 

如果你也正处在一个类似的项目里，也许会从中看到一些熟悉的影子。

 

一、案例A：财务很努力，项目也推进了，为什么最后还是被叫停？

 

先说第一个。

这位财务负责人很有推动力，也很有想法。他当时的目标其实非常明确：把业务系统里的数据全部联动到财务端。这样一来，财务不用再大量手工做账；二来，库存、应收、应付这些关键经营数据，也能实时掌握。

 

从财务视角看，这个目标一点问题都没有，甚至可以说很先进。老板一开始也认可，于是就找了金蝶体系内的一家合作伙伴，项目正式启动。

 

问题不是出在“要不要做”，而是出在“怎么做”。

 

项目推进过程中，他基本绕开了IT，更多是直接去跟供应链、销售、营销这些业务部门沟通。听起来似乎也没什么不对，毕竟业务数据就是从这些部门来。但真正的问题在于，整个需求表达方式，几乎完全是财务语言。

 

简单说就是：财务要什么凭证，业务就给什么数据；财务需要什么口径，业务就按这个口径往系统里传。

 

项目做着做着，就变成了一个非常典型的“财务后端自动做账工程”。

 

这类项目在短期内往往推进得还挺顺，因为业务部门表面上没什么阻力。你不要求他改流程，不要求他重塑动作，也不要求他承担更多责任，他当然愿意配合。可问题也恰恰在这里：业务没有真正被改变，系统只是替财务接了一根更长的数据管子。

 

于是后面很快就出现了几个明显的问题。

 

1）没有整体规划，只解决了眼前入账的问题

项目的出发点很清晰，但停留在“财务怎么拿到数据、怎么生成凭证”这一层，没有上升到企业整体信息化、数字化架构去考虑。

比如未来业务模式要不要变？

以后新系统要不要接？

管理口径变化了怎么办？

后面要不要做经营分析、预算管控、业财协同？

这些都没有预留。

所以项目做到一半，大家就会慢慢发现：它是能出凭证，但也仅仅是能出凭证。

2）业务没有被赋能，旧问题原封不动留下来

业务部门没怎么改，意味着原来业务里的问题也没改。

订单怎么流转、库存怎么记录、应收怎么确认、责任边界怎么划分，这些如果本来就不清晰，那么传到财务端以后，只是把不清晰变成了电子化的不清晰。

财务系统接得再好，也只是接住了问题，没有消灭问题。

3）一旦需求变化，整个体系会很脆弱

因为整个逻辑是围绕财务凭证生搬硬套出来的，一旦业务侧发生变化，或者管理要求提升，财务系统就很容易被牵一发动全身。

说白了，项目没有长在业务土壤里，而是悬在财务逻辑上。

后来这个项目推进到中段，企业内部给出的反馈越来越一致：项目进入“单期”了。

也就是只满足了某一个单点诉求，局部看似落地，整体却没有形成价值闭环。

最后老板把项目叫停，重新评估，改由IT 部门接手。

这件事对很多财务负责人来说其实挺有代表性：

不是你做错了，而是你只站在财务里做对了。

 

二、案例B：项目做成了，但财务成了“接锅中台”

 

第二个案例就更有现实感了。

这家公司最大的特点是：销售极强势。

不只是销售部门强，而是整个公司的氛围，从高层到中层，几乎都是围着销售转。

在这样的企业里，很多规则不是不能定，而是很难让销售为了财务去改变动作。别说流程重塑，有时候哪怕只是让前端多填一个字段、多录一张单据，阻力都很大。

这位财务负责人不是没想过从源头解决问题，他当然知道很多事情应该在业务端做好。比如一笔收款，对应多个项目，最理想的做法一定是业务前端就拆清楚。这样后面的应收核销、收入确认、项目对账都会很顺。

 

可问题是，他推不动。

 

业务系统可以跑，业务结果也能出来，但你要让销售为了后端账务清晰而改变习惯，这在当时几乎不现实。

 

怎么办？项目还得做，财务也不能一直手工熬着。于是他走了另一条路：在财务系统前端搭了一个“中台”。

 

这个中台很像一个缓冲层。业务端无论传过来的是标准数据、半标准数据，还是带着错误的数据，财务都先接住。然后再通过一套财务规则去拆、去补、去修、去校正。

 

你可以理解成，业务端没做完的规范化工作，被整体搬到了财务前面。

 

这套模式最后其实也做成功了。至少从财务部门的角度看，效果不差：

·财务自动化入账实现了；

·很多原来靠人肉判断、手工修正的工作，变成了系统规则；

·一部分历史遗留问题被“消化”了。

但这个成功，带着很明显的边界。

它解决的是财务效率，不是企业流程质量

这就像房子漏水了，你在客厅里摆了一个非常高级、自动排水的接水系统。水确实没淹出来，客厅也整洁了很多，甚至你还能实时监控漏水量。

可天花板的裂缝还在那里。

案例B的问题就在这儿。

财务系统做成了一个非常能干的“后处理中心”，但业务端的问题并没有真正被纠正。错误继续发生，只不过不再那么痛了，因为有人——准确地说，是财务——在后面兜底。

久而久之，财务就容易变成那个最累的部门：

前端出了错，先往后传；

中间断了链，财务补；

结果解释不清，财务再来圆。

很多企业最后形成的，恰恰就是这种机制：

前端负责跑业务，后端负责修业务。

这位财务负责人很清楚，这不是最优解，但在当时的组织环境下，这是他能拿到的最现实解。

所以案例B最值得看的地方，不是“他做得好不好”，而是：

项目成败，从来不只取决于方案本身，也取决于组织权力结构。

如果企业文化天然是销售主导，那你想推动一个“为了财务规范而改变业务动作”的项目，就不能只讲逻辑，还得看谁有话语权。

 

三、案例C：同样是财务主导，为什么他就走通了？

第三个案例，我一直觉得特别值得讲。

这位财务负责人有一个很大的优点：他很清楚自己懂什么，也很清楚自己不懂什么。

他对财务很熟，业务规则也熟，但对IT 技术、系统架构、ERP 产品版本这些不懂。很多人做项目容易卡在这里：懂财务的人想一把抓，结果抓着抓着就抓进技术细节里去了；不懂又不肯承认，最后项目就容易跑偏。

而他处理这件事的方式非常稳。

1）先拿到高层共识，再谈谁主导

他一开始没有急着去选系统，也没有急着拉供应商演示，而是先在公司内部跟高层把方向谈清楚。

也就是说，他先解决了一个最关键的问题：

这是不是公司层面的事，而不只是财务部门的事。

高层一旦形成共识，很多后面的动作就顺了。IT 会配合，业务部门也知道这不是财务单方面的诉求，而是公司决定要做的事。

这一步其实非常重要。因为财务主导项目最怕的，就是名义上是负责人，实际上没有组织授权。看上去你在推进，真碰到跨部门问题时，谁都可以让你等等看、再商量、以后再说。

这位负责人把这一步做得很扎实，所以后面他的“主导”是真主导，不是名义上的主导。

2）先梳理流程，再提出需求

他没有一上来就问“哪个系统能做自动凭证”、“哪个厂商最强”，而是先把自己的需求拆开：

第一步做什么；

第二步做什么；

哪些是必须实现的；

哪些可以分阶段推进；

哪些地方如果业务不改，项目一定做不成。

这个顺序看起来普通，真正能做到的不多。

因为很多企业一做信息化，就容易跳过流程，直接奔着功能去：

有没有这个模块？

能不能自动生成？

有没有报表？

能不能打通接口？

 

功能当然重要，但如果流程本身没理顺，功能越多，往往只是把混乱搬进系统里。

 

这位负责人很明白，只要结果、不改过程，最后一定要有人替这个过程埋单。 所以他推动的不只是财务自动化，而是端到端闭环。业务该调整的地方，也得调整。

3）选供应商时，不迷信演示，而是追问实现逻辑

流程清楚之后，他再把需求发出去，找了三家比较有实力的供应商来做方案。

拿到方案后，他不是只看页面，也不是只听销售讲成功案例，而是会反复追问几个问题：

·这个逻辑到底怎么实现？

·中间哪些环节靠配置，哪些靠开发？

·如果以后业务扩展，这套架构能不能撑住？

·拓展性如何，三年后会不会成为包袱？

更关键的是，他不是一个人拍板，而是带着老板一起，一家一家去聊。

 

很多时候，供应商的能力不只体现在“今天能不能做出来”，更体现在“你跟他聊深一点以后，能不能感觉到他真的理解你的业务、理解你的阶段、也理解你未来可能会变成什么样”。

 

最后他选定了一家供应商。后来的结果证明，前期选型花的时间一点都没浪费。

 

4）项目不是一下子做完的，而是用2年时间一点点迭代出来的

这个项目做了大概2年。

两年听起来不短，但这恰恰是成熟项目的常态。真正有价值的财务信息化，很少是几个月“一键上线”就完美收官的。它更像是一个逐步替换、逐步固化、逐步放大的过程。

他先把手工账往线上迁；

再把财务自动化做起来；

再把业务端和财务端打通；

最后让管理报表自动生成，真正开始支撑经营分析和高层决策。

到这一步，项目才算真正从“财务做账工具”变成了“企业经营基础设施”。

这也是案例C最难得的地方：

他不是只把财务做轻了，而是把整个企业的业财关系理顺了。

 

四、把三个案例放在一起看，会发现什么？

这三个案例，表面看都叫“财务负责人推动财务信息化”，但内核其实完全不同。

案例A的问题，不在于财务想法不对，而在于项目只用财务视角设计，没有形成整体规划，也没有让业务与IT真正参与改变，最后做成了财务单点工程。

 

案例B的问题，不在于方案不聪明，恰恰是太聪明了。它聪明到足以替业务兜底，于是企业更没有动力去修复前端问题。结果是财务效率提升了，但财务也更像“补锅位”。

 

案例C之所以成功，不是因为他比前两位更懂系统，而是因为他更懂项目到底是什么。

它不是一个采购软件的动作，也不是一个财务部门提需求、别人来配合的动作。

它本质上是一次组织协同、流程重塑和系统承载能力的共同建设。

 

说得通俗一点：

·财务可以主导，但不能只代表财务。

·系统可以服务财务，但不能只解决财务。

·自动化可以先从账务开始，但不能止步于自动生成凭证。

 

五、如果财务负责人来推项目，最怕的其实不是不懂技术

很多人会觉得，财务负责人推信息化，最大的短板是技术不懂、系统不熟、产品不会选。

但从这几个案例看，真正致命的往往不是这个。

不懂技术，可以找IT，可以找外部顾问，可以多看方案、多问人。

可如果下面这几件事没想明白，项目通常就很难顺：

 

第一，分不清“财务需求”和“企业需求”

财务的需求，很多时候只是企业需求的一部分。

如果把二者画等号，项目很容易变成“为了财务方便，让全公司配合”。

一旦这么做，阻力就会非常大。因为别的部门会觉得：这是你的事，为什么我要改？

第二，没有处理好“业务改不改”这个根问题

所有信息化项目，最后都绕不开一句话：

系统只是固化流程，不能替代流程治理。

前端该规范的动作不规范，后面系统再强，也只是高效率地处理混乱。

第三，把供应商当成交付工具，而不是共建伙伴

很多项目失败，不是败在系统不能做，而是败在一开始就选错了人。

有些供应商很会演示，很会讲愿景，但对企业未来3到5年的支撑能力未必足够。真正靠谱的，反而未必最会说，但逻辑很扎实，边界讲得清，知道什么该做、什么不该承诺。

第四，以为“上线”就是“成功”

系统上线只是开始，不是句号。

能不能稳定跑、能不能适应业务变化、能不能真正沉淀成管理能力，这才是后面的关键。

 

---

回头来看：财务主导，不一定是问题；只站在财务里主导，才是问题

我一直觉得，财务负责人来推动财务信息化，本身不是坏事。

相反，在很多企业里，财务往往是最早感受到信息断点、流程断点、数据断点的人。哪里手工最多，哪里对不上，哪里反复返工，哪里明明赚了钱却说不清楚为什么，财务通常最先知道。

所以财务来提这个项目，很多时候是合理的，甚至是必要的。

 

真正的区别在于：

你是把自己当成“财务代表”，还是把自己当成“企业项目负责人”。

如果是前者，很容易把项目做成一个精致的财务工具；

如果是后者，才有可能把项目做成一个真正的业财协同工程。

回头看这三位财务负责人，其实都很努力，也都不是没有能力。只是他们所在的组织环境不同，推进方式不同，对项目本质的理解也不同，于是最后走向了完全不同的结果。

这也是财务信息化最真实的地方：

它从来不只是系统问题，也不只是财务问题。

它是业务、财务、IT、管理机制共同作用后的结果。

有时候项目没成，不一定是谁不专业；

有时候项目成了，也不一定就真的做对了。

能不能走远，最终还是要看：

你做的，是不是一个能让企业越来越顺、能自适应未来发展的系统，而不只是一个让财务暂时轻松一点的系统。

 

 

 

声明：此网站所刊载文章、图片等，属于相关权利人所有，若因客观原因存在使用不当的情况，敬请与我们联系及时依法删除或修改处理。
 
这里有更多的财税信息、更专业的政策解读、最激烈的热点碰撞，还有海量的免费课程体验，欢迎加入财税讨论群(微信号：linkedf-fans)