案例:项目型企业费用申请和报销审批系统

标签:CFOBI项目管理BPM数据驱动的企业

访客:53740  发表于:2014-01-17 09:31:34

摘要:一大型装修装饰企业发展起来后,老大感觉对于企业盈利和风险的洞察能力减弱,同时对于未来发展方向的决策也希望能有数据辅助。这样一种需求在交给集团财务总监负责后,变成了一个费用申请和报销的审批流程项目。为什么会这样?过程中有什么问题?最佳的解决方案应该是什么?该案例详细描述了全过程。

国内一建筑装修装饰集团公司A从设计起家,发展起来后业务横跨咨询、设计、施工、软配、家具、售后全产业链。家大业大后,老大感觉问题出来了:

  1. 到底哪些客户赚钱?哪些不赚钱?哪些项目赚钱?哪些不赚钱?哪些赚钱多,哪些赚钱少?公司客户和个人客户,那个更赚钱,两个都做还是聚焦一个?
  2. 全产业链上哪些环节更赚钱呢?从设计起家,利用设计的强项做响了名气后顺势进入产业链的上下各个环节,复用了客户资源和销售力量,但同时也铺开了摊子、增加了风险,如何权衡取舍呢?
  3. 能不能利用自己业界的名气做总包,把利润厚的奶油自己吞下,把苦活、脏活、占用资金多的活外包出去,相比现在的模式利润不少,人均利润更高,同时还降低了风险,这种设想能做吗?

老大的问题和想法很多,想用IT的手段来解决上述的问题,并把该项目全权交给了集团的财务总监来负责,还希望该系统能做成装修装饰行业的样板。

为什么老板的上述问题,财务总监现在拿不出数据来回答呢?因为该集团目前的管理是粗放式的,虽然集团的财务是统一管理,收支两条线,但集团下面各个公司的项目经理要付款了,提交纸面的付款申请,上面只有一个笼统的项目费用、付款对象、对应的合同号,没有客户名称、没有项目名称,所以集团财务能做的只是流水记账、查对发票、付款,唯一能把关的是该合同名下付款累计是否已经超出合同金额了。付款申请也没有得到严格的审批,因为集团下面的公司更多地只是一个牌子和税务的需要,人员有些是复用的,管理条线没有清晰定义,项目经理可以选择经理来审批,有时业务公司老总来一个电话就算批准,所以财务总监打算首先上马一个费用申请和报销审批的流程系统来规范化管理。

该公司首先找到了IBM,一听是审批流程应用,IBM引入了旗下一家专门做BPM工作流应用的ISV B来跟踪该项目。B和A的IT部门接触后,感觉项目范围太大、太杂,除了费用申请和报销流程外,还有项目管理,报表分析,甚至连未来3到5年A公司的IT战略规划似乎都包括在内,于是B的老大把我们引入进来。

B和A从第二次接触开始,我们就参与其中。一开始A只有IT部门的人出来,提出的都是信任方面的问题,如:(1)我们是项目型的公司,大多报销的费用是属于某个项目的,你们做过项目管理方面的客户吗?(2)你们有建筑、装饰装修领域的成功案例能介绍吗?A不想做第一个吃螃蟹的客户,希望B有类似客户的经验供参考。对于A的疑问,B心里其实是这么回应的:费用申请和审批是通用的应用场景,没有什么行业特性,所谓项目管理不就是表单中多了一个项目编号吗!我们是做流程管理平台和应用的,不是做项目管理应用或ERP应用的,不过我们还真有房地产领域的客户案例。双方的信任没有建立,接触过2~3次后,双方没有取得大的进展:

  1. A认为自己的需求是独特的,除了审批流程外还要有项目管理,但是到底怎么做自己心里又没底,所以要求B做项目管理方面的演示;
  2. B不明白A所谓项目管理的需求到底是什么,所以反过来要求A写出具体的需求,或者把现有的手工管理规范文档拿出来,再考虑是否演示;
  3. A可能是没有相关文档拿不出来,只能一味要求B先演示,认为己方的业务和财务人员看到演示有直观印象就能提出具体需求;
  4. B本来就觉得A的需求太大、太多、太不清晰,自己又只是强于流程管理这一块,太多的需求把握不好,所以感觉项目不太靠谱,认为A有可能是在利用B的售前来获得免费的咨询,担心前期投入打水漂,又不指着A这个项目吃饭,所以也没有太大的动力。

至此,项目似乎走入了一个死胡同,需要有一方先让步才能进入下一阶段。这种死胡同的场景在国内很常见,根本的原因还是甲方A需求不清晰,自己拿不出一套思考成熟的管理流程和模式,寄希望从乙方B处获得免费的业务咨询或培训,来弄清楚自己的需求。而B作为业内已经摸爬滚打十几年的老牌公司,清楚地知道免费的咨询培训了客户之后,还是免不了招标或议标的结局,自己辛辛苦苦前期做的工作并不能换回中标的保证,报价也不可能比没有前期投入的竞争对手高出去几个点。

虽然还没有见过该公司的老大和该项目的实际主管:集团财务总监,但通过问IT几个为什么的问题得到的答案,我感觉已经把握了客户的需求,即前面已经列出的老大的几个问题。这些问题其实是一些共性的问题,每一个背负企业未来发展和当前沉重开销的老大都非常关心或困扰于此。但为什么这样一个本源需求会变成了一个费用申请和报销的审批项目了呢?实际上也很容易理解:因为项目交给了财务总监。(1)当前的现状是财务总监几乎无法管理费用的支出,只能被动地服务,一旦有了审批系统,必然会固化下来审批流程,不再是下面老总一个电话就必须放行,审批链上的各环节就拥有了权力;(2)财务总监可以规范表单数据(比如客户在集团范围内统一管理且唯一,便于统计其对于集团的价值),有了数据,就可以统计老大的部分需求。(3)为什么还会有3~5年IT规划这样一个需求呢?因为无论是财务总监、IT部门、乙方公司B都不认为该项目能在短期内完成。财务总监和IT甚至希望流程审批项目先从职能部门开始试点,成功后再推广到业务部门。我帮他们翻译成大白话就是先不碰业务部门项目费用的自留地,避免业务部门的抵触和反弹,毕竟谁都不希望自己头上加一个紧箍咒,而是从出差费用、市内交通等常规管理费用入手。项目计划一期半年、二期一年,时间至少要两年,所以IT希望中标的乙方公司要成为战略合作伙伴,能够长期地跟踪自己的需求,修改或增加功能模块,所以提出需要一个IT规划,一方面向上解释项目的周期,另一方面画大饼,证明自己的重要性,为此IT还问出了如何让IT成为利润中心的问题。

其实,客户A老大的需求最好是上一个项目型ERP来解决,不过A公司过往的管理粗放,对于项目的管理还停留在合同费用不超的原始阶段,一时到达不了甘特图等关键路径、前后工序、并行操作、资金、资源、人力的同步跟进和监控的高级阶段,甚至对于每一种类型的项目,应该有哪些工作任务(working item),每一步大概需要多少时间、什么时候需要多少人力资源和资金和什么物资等经验知识,也没有作为企业的知识标准化和固化下来,所以这时候上项目型ERP根本无从入手。再考虑ERP通常会更贵,所以先上马一个费用申请和报销审批流程是一个不错的切入点。

不过这个BPM项目的重点不在流程上,尤其不在流程的审批上。过于关注流程而不明白为什么要有这些节点?为什么在这个节点给的是50万的审批权限?为什么这个节点的审批时限是48小时?这些节点和节点的数字是拍脑袋出来的还是科学地统计分析出来的?没有考虑类似问题的答案是国内很多BPM项目的常见通病。对于A客户,因为一切前期的数据都没有,而上BPM项目的最终目的是解决老大的上述问题,所以该BPM项目的潜在最大目的应该是收集基础数据,规范化地收集数据,而不是审批,因为绝大部分情况下,审批是否同意的依据是缺乏数据支撑的(即data-based decision基于数据的决策,data driven enterprise数据驱动的企业)。

另外,A企业非常强调自己是项目型企业,那么具体到装饰装修行业有些什么特别的业务场景呢?他们特别强调这一点,一定有在这些方面的问题和困难存在,在网上我们查找到了比较接近的行业-地产业和建筑施工行业,发现了一些端倪:所谓的项目管理,最大的体现还是在管钱,还没有到管时间和管资源的精细程度。不过即使是管钱,也有不少问题或需求存在,根本原因是要指导采购招标、前置成本控制和保障权责落地:

  • 项目中的各种费用要归属不同的科目,如建筑施工行业的人工费、材料费、机械使用费、其他直接费、间接费用、分包工程费用等。
  • 实际的具体管理都是基于合同的,但项目和合同如何一一对应呢?一个费用科目下可能会有多份合同,一个合同又可能涉及到多个费用科目(如总包合同),而且都还需要有预测和经验数据,因为对于项目费用的管理,假设某个科目会有3份合同,前两份签订时没有超出费用预算,但可能剩下的余量不足以支付第三份合同要涵盖的工作内容,跨科目就更有可能。这种场景也是A企业老大感到风险加大的原因之一,对于未来要支出的费用有清晰和相对准确的提早预测,是风险可控的唯一办法。
  • 管理精细且有一定数据量沉淀的企业,对于合同的工作内容涵盖、费用的科目,预算的金额都心里有底,在自身强势的情况下直接主导合同的格式或模板,方便后续的执行和监控检查。而在面对更强势的大业主或政府时,无法主导合同的格式和数量,只能停留在粗一层次的管理,但对管理人员经验的要求更高。

了解到上述业务场景和需求,我们设想系统可以如下实现:

  1. 集团范围内统一且唯一地定义客户、项目、供应商、合同等,即元数据Metadata,便于后面分析统计,相应的控制用新增XX或修改XX的流程来保证。
  2. 在费用申请和报销的表单中,一定要记录各种属性信息,如客户名称、项目名称、项目工作子项working item、对应合同名称、对应合同中的项目或条款、下属公司或价值链对应环节、付款供应商、费用科目、费用大小、要求支付时间等。
  3. 表单尽可能统一,这样表单中录入的数据抽取出来,存入关系型数据库的表中,这时候的表天然就是数据仓库的雪花模型,可以直接在OLAP系统中生成维度和量度,用Excel做多维透视表进行多维分析。如果所有数据全部放入一张大表中,而不整理成3范式,不上OLAP,直接用Excel访问就可以数据透视了,以A公司的数据量而言,是不会到百万数据量级,完全没有问题。
  4. 对于表单中的录入项,尽可能用只能选择的下拉框方式,用以规范化数据。但对于项目工作子项,一开始可能做不到事前清楚,也没有在整个公司的所有部门中统一,前期可以在下拉框中增加一个其他Others的选项,另外提供一个自由录入框,解释清楚项目子项。当类似的项目做了多个以后,后台的管理人员就要召集业务部门的项目经理、管理人员、集团财务、采购等多部门人员,把以前做过的项目数据都翻出来,大家一致同意规范到哪些步骤或working item,取得一致意见后修改系统,将自由录入框中标准化后的子项改为下拉选择框,规范数据。不过自由选择框可能还要保留,以应付目前为止没有考虑到的子项。这个过程可能要持续下去,除非该类型项目已经完全了解清楚。
  5. 为什么要记录项目子项?因为经过一段时间的数据采集和汇总分析,上面讲到的BI系统就可以针对类似项目,分析出平均值,即每一条子项需要的时间、需要的材料费用、需要的人力资源和人力成本,无论是项目经理、分公司老总还是集团的财务管控和老大来说,都可以清楚地知道,项目进行到目前,费用和时间是超了还是时间过半、任务过半的正常状态。这样在审批每一笔费用的时候,都可以基于数据和各自的职责,做出科学和灵活的决策(所谓灵活,即可能按照经验值,某子项费用可能会超出预算,分公司老总和集团财务就会预警,提醒项目经理后续工作手头紧一些,把窟窿补回来一些)。
  6. 如果有可能,工作子项要和与业主签订的合同一一对应起来,如工作验收节点、付款节点等,便于与业主的合同管理。
  7. 与下包商和供应商的合同管理,有可能和项目不是一一对应,而是签框架合同,按月结算的。有可能多个项目的物料或人力采购合并到一期,月结给下包商。如果要清晰地管理和下包商的合同,申请付款的审批表单中要记录详细信息,便于详细对账和付款后核销。
  8. 由于上审批系统的目的是收集数据,而不是一上来就是审批和拿捏。这一点可以一开始就由老大清晰地通告业务部门,而且未来的统计经验数据出来后,会分享到所有业务部门,大家对于项目无论时间进度、费用和人力的把控都更有预见性,把控的尺度和余量大小还可以协商出一个科学的范围,无论对于业务部门的项目经理还是分公司老总都是有价值的,自然不会一开始就抵触,所以审批项目可以一开始就直接切入业务费用的管理,同时流程的复杂性可以尽可能简化,确保最快速度收集到必要数据,经过分析后见到成果和价值。

上面这一段就是我们设想的解决方案,在任何一个标准的BPM系统上都可以很快实现,客制化的工作量很小。简单地客制化表单,并增加一个将表单数据转入关系型数据库表的步骤(不是在审批完后数据才进入DB,而是在建立表单的第一时刻就录入DB,并随着表单的流转时刻改变着状态,未来还要规定某种类型的费用或某种大小以上的费用要提前不少于多少时间申请或发生多少时间后必须报销,这样后续的分析系统就可以针对应付有很好的预测或预警,为资金的筹措和管理提供支撑),然后在OLAP系统中定制维度和量度,用Excel做多维分析前台,这个系统就算实现了。心里有底后,我说服B把一个原有客户相对复杂的审批流程演示给A看,邀请A的财务总监出面。一方面要见见客户业务部门的人而不只是IT的人,确认我们理解的需求正确和不遗漏,另一方面也是让该项目负责人了解B的实力,增强对B的信心。

Demo很成功,演示的场景很接地气,有一个场景是针对国内的现状,比如有的时候是先有发票后付款,有的时候是发票没到就需要先付款,发票后补再冲销,不过可能一次来的发票也不一定就刚好是申请的金额,还可能要多张发票才能凑足一个金额(有些小供应商不能开大的发票金额)等等不一而足,B以前客户碰到的种种问题都一一在这个场景中演示出来。财务总监及其手下看了Demo,果然提出了自己的具体需求,如:

  • 费用申请人在填写供应商时要再次检查付款账号等以确保信息是最新的,或符合供应商的要求
  • 因为人员的复用,一个人可能同时有几个职务,流程如何设计?
  • 因为领导经常出差,系统能否支持手机审批?能否支持授权委托?授权委托解除后能否有报表让授权领导看一下被委托人期间做了一些什么审批?
  • 审批结束后能否自动生成凭证,导入财务系统做账?
  • 审批每个环节能否设置最长期限?能否有催办机制?能否有报表统计出那些人或环节经常超出审批时限?
  • 表单能否自定义?流程能否自定义?
  • 外地发票或费用单据不能马上送到总部,能否拍照后作为凭据先跑流程,收到实物票据后再比对检查?

B很专业地解答了上述问题并一一演示,可以看出来,通过演示,财务总监心里的石头落地了,B的产品能够满足其需求。不过通过财务总监问的问题,也可以看出一个业界普遍的问题:太多地考虑了操作层和管理层的需求,而没有在决策层的需求方面花大力气。显然,上述财务总监关注的点并不能解决一开始就提出的老大的问题,暴露出来的问题如下:

  • 需求其实是现有的手工流程,或者是自己借鉴的别人的最佳流程,却没有追究其背后的目的和原因。以费用申请和审批流程为例,到底审什么?是费用对不对,和实物发票一致吗?还是费用超没超?科目对不对?这些就够了吗?费用超了你能怎么样,后续费用不付可能吗?费用没超,但你知道后续还有多少项目工作还没做吗?还有多少费用一定会发生吗?现有的剩余预算够支付吗?
  • 过多地站在一个职能的点上来考虑需求,而没有站在其他职能的点上来考虑问题,更没有站在决策者的立场上全盘考虑问题。上述财务总监的问题,钱、发票、帐方面考虑了不少,但显然没有考虑项目工作内容working item,项目经理如何和业主关于合同中基于工程关键节点的收款;项目经理如何判断时间过半,任务过半;采购经理如何汇总各项目经理基于工作内容的物料需求以及当前库存在辅以框架合同决定的采购数量等。
  • 需求过于接地气了,高度不够,不能够为决策层分忧解难。本案例中一个很重要的关键是对于项目的知识管理,将各种项目归类,总结出每一类项目的工作内容working item,需要的时间、费用、人力资源、物料等经验数据,这样每一个项目一旦开工,对于上述4方面的预测数据都是清楚的,一开始老大对于风险的担心就可以在项目过程中持续地监控和提早解决,对于老大想做总包赚利润最厚部分的钱也由于有这种知识管理才可以低风险且高效率地复制到众多项目中去。而对于老大希望战略决策哪些客户是好客户,赚高额利润,哪些客户是跑量,养活一大摊子的人,哪些价值链环节和客户是亏本的,可以考虑放弃等等问题,也可以通过工作流系统收集的数据通过BI系统分析出来。上述这些最有价值的点,显然在财务总监考虑的需求中没有包括进去。

由于上述我们看到的很多问题都不直接包括在B能够提供的解决方案内,所以我们没有在第一时间告知A。接下来应该是进入报价和讨价还价的阶段,A让B报了个价,可能觉得有点贵,又告知B原来他们有一个项目管理的老系统,能否基于其上修改一下满足他们的新需求。决定这样改可能一方面可以利旧,不至于让原有的投入变成沉没成本,老大那里容易说的过去;另一方面可能费用方面可以节省一些。截止写这篇文章,该过程还没有结束,不过我们的感觉是:迄今为止的选型过程都没有抓住价值最大的部分,不能直接解决A企业老大的困扰和问题,一方面B卖不起价,另一方面A如果真投入,未来的系统又可能反应平平,博不了业务和老大的好口彩。


广告:更多案例,请访问我们的网站www.itxqgl.com中的案例分析。2014年,我们推出了基于案例的IT需求管理常见问题的培训。

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");