我们一起看几个财务信息化过程中的案例， 和一些有趣又实用的观点。
1. A公司财务信息化项目上线流程案例分享
A公司在进行项目上线时，通常是这样的流程：先确定总体目标，确定涉及的职能部门关键人员，成立项目小组，把相关职能分工模块谁负责明确下来。项目启动后，进行正常的调研，排期，确定时间计划和目标计划，根据需求调研结果，先从下往上，再从上往下的给每个模块确定目标。
通常IT会引导财务的需求，决定第一期满足什么功能和第二期预计安排什么功能。在企业实际项目运行过程中，一般多个项目同时进行，因此时间把控比较难。上线后会有1-2个月的试运行时间，评估完成的项目效果和目标是否有差距，同时收集用户反馈。反馈意见基本分为两部分：系统问题和需求问题。系统问题通过现有的三层反馈机制，从最终用户到关键用户对反馈做处理：Helpdesk处理第一层问题，无法处理的问题会被提交给IT，作为第二层处理。如仍旧处理不了，IT会再提交到软件公司，这是第三层处理。IT会针对提交的需求和问题成立项目小组评估，分析用户需求与总体目标、成本和时间是否符合，再确定是否要提交给软件公司进行开发。
分析点1：是否需要IT引导业务需求？
A公司的上线流程已经很专业且细致了。通常上线的过程IT和业务部门都是很苦很累的，日例会、周例会、上线后支持等等。又因为上线后的反馈很多，用户认为没达到预期，还要再拿一笔钱给供应商去做修补。
这里面有个常见的误区：引导客户需求。引导客户需求其实是一把双刃剑，引导了客户，需求就不发散了，这本身来说是好的。但误区恰恰是因为需求被引导了，最后交付的东西可能不是他们想要的，和实际的需求可能有差异。客户对你的引导是有感知的，但不反对并不一定意味着赞成，毕竟他们的本职工作并不是做这个项目，你也做的很辛苦。如果在需求调研阶段引导了需求，可能在三个月后项目上线时出问题，这时客户可能记不得当时被你引导的需求，如果你交付的东西没有解决他的实际需要，客户自然还是会不满意的。IT项目经理如果事无巨细的去管，反而项目会出问题。并行项目的数量级增加后，管理难度会成几何级数增加。
分析点2：自上而下还是自下而上？
案例中的公司提到了A企业做项目是先自下而上，再自上而下。我们在这里有一个更直接的观点：如果是自上而下的项目，可以直接按照老板的要求雷系风行地去执行；如果预算是集团统一的，分子公司完全不花钱，那就完全按照集团的意志来做。而自下而上的项目，却需要仔细收集需求。这里权衡需求的原则不是部门描述的急迫程度，而是大家愿意花多少钱办多少事。哪个部门想要特别的需求，这个部门就要掏钱，这一方面体现了争取预算的能力，另一方面也说明这是一个真需求，有痛点，这个功能做出来才是有价值的，是会解决实际问题的。
分析点3：用钱衡量需求真实性
做项目的时候，你一定会遇到某个部门说他们想做一个需求而又不想掏钱。这时候该如何应对？你就可以先说这个功能比较复杂，先不做。这并不是一句敷衍，而是通过这句话让这个部门指导所有的系统和功能的实现是有成本的。如果没有人愿意掏钱，最后这个系统做成什么样也都不是你的问题，他也没有理由来说你不好。如果没有预算或钱很少，但真的想做，也需要出点钱， 这样才有参与感。做项目时当裁判员很难，很多时候某个人无法判断部门的业务需求是否合理，到底有多紧急。当部门肯掏钱的时候，一定真的是很紧急，有需求。不掏钱的话，潜意识里，部门也会觉得是因为没掏钱才没做他们的需求。在内部一定要谈钱，用钱在内部衡量需求会越做越顺。
2. 流程精细化改变管理流程的案例分享
B集团的一个子公司做了一个这样的大项目：打通 SAP、财务端和业务端系统。起初的想法是让物流和财务流可以打通，后来产品经理想要更进一步，提出物料账可以按物料号去界定每一个产品，每一台车，每一个底盘号的成本。这听起来很好，但实际上母公司也没有做到这个精细度。项目上线半年后问题很多，经常关不了账，因为前端对基础数据的要求和业务端的操作需求非常高，流程非常严格，而公司本身管理并没有达到这个精细度，并且公司其实也不需要这么严密的底层的信息，精细到这样的成都也没有什么实际意义。现在业务部门总会来抱怨财务部门牵头的这个项目，导致账关不了，还给业务部门添了很多麻烦。
观点：管理的代价是高昂的
美好的东西不一定适合现在，任何需求都是有成本的。无论是外部供应商还是内部开发都是很贵的。更重要的是任何管理都是有成本的，管理越精细化成本越高，尽管大家可能没意识到。管理上系统的本质是两害相权取其轻，经营体量到一定规模后，如果不付出信息化成本，就要面临更严重的后果。我们要考虑计算的不仅是上系统的成本，还有上线后续会产生的成本，统筹收益分析的结果可能就是这个系统上线是没有什么收益的。
3. 业财一体化集成的反面案例
分享一个业财一体化的反例。C集团有且只有一套大而全的系统，从差旅，费控，OA，销售，审批，资金，回款，总账和财务报表都在一起，现在上线四年了，可以说没有这个系统业务就无法运作，从这一点来说这个系统是成功的。C集团花了两年时间上线这套系统，从之前用的Oracle迁移过来，也曾经遇到很多瓶颈。现在一个很明显的问题是，C集团的业财一体做得过于紧密，没有任何灵活性，系统现在已经到了僵化的地步。集团自身没有开发能力，系统的运营维护成本很高，只能依赖供应商。而运维供应商的锁定价格最多只能保持3到5年，熬过三年之后，乙方开价就开始很吓人，成本非常高。C集团也反思过自身的问题，首先供应商来源太单一了，不够分散。另外系统没有改造的空间，如果有一天系统用不下了，唯一的选择只能重新换一套系统，会非常昂贵。从前端客户数据进来之后所有的合同和信息和财务的输出都汇总到一条线上，中间任何一个地方想改都非常困难。这个导致的问题就是现在创新业务非常难上，只能拼命打补丁，尽量让数据贴合，甚至去改财务账。
观点：紧密型与灵活性的取舍
这是个特别有意思的业财一体化案例。一个紧密的一体化的系统自然有他的好处，而坏处就是丧失了灵活性。对于以前的企业而言，买一条生产线十年不用变动，动了反而不稳定，也很少出现更换生产线的情况。而现在的企业变化速度很快，系统作为业务的支撑，灵活性可能比稳定性更重要。
