从一个案例看信息化项目中的财务与业务衔接的关键点

意外翻几年前做一个供应链项目时的调研总结思维导图，准确说只是一个类似的架构，大概还不算一个完整的思维导图。那是我第一次作为项目经理做一个完整的供应链项目。正是这次项目经历让我较为清晰地理解了信息化项目中业务与财务的关键衔接点。

今天再看那张稚嫩的思维导图，仍能想起当时做项目的脉络。因为是升级项目并不涉及全部重新实施，只是扩大项目范围，增加组织和上线模块。在前期的需求调研结束后我重点关注了三个点。


采购环节的三单匹配
重点是将采购流程从原来的只做入库延伸到采购订单管理，增加质检环节，在系统中实现采购订单、入库、发票的三单匹配。较大的改变是将发票匹配前移，由最先拿到发票的采购部门在系统中进行发票预制，财务进行过账前的检查确认。直接与供应商对接的是业务部门，由采购部来维护发票信息，间接让开票更及时和规范，采购和财务的工作量都被减轻。没做到的是采购价格管理，询价比较流程是基于系统外流程，但实现了采购过程的实时跟踪。


销售应收账款管理功能完善
在交货环节增加财务收款审批节点，完善了系统里的应收账款管理，这后来也成为了项目验收的亮点。该企业主营业务既有产品销售也有项目施工，同时有应收和预收，回款也毫无规律可言，所以往来对账一直很复杂，账龄表就更不准了，当然坏账比例也不低。这些问题成为升级时对方项目经理非常关注的问题，这其实也是销售与财务对接时常被重视的问题。


细节实现方案记不太清了，大体的思路是用系统的标准功能进行往来核销，但通过增强区分了销售和施工两大业务。主要是借助k3对开发的支持，在标准单据增加了字段，然后又借助后台的增强实现单据间的信息继承。最后报表的显示是用了k3的报表开发功能，直接通过存储过程取数。最后应收账款就非常清晰了，账龄也基本是以系统为准。


从系统出账龄表对软件系统本身而言并不是难题，难得是让业务按照系统的逻辑去做，比如回款与发票一一对应，及时进行预收与应收清帐，要达到好的实施效果，通常是需要先实际业务入手进行梳理，然后才是系统实现。


简化备品备件管理
库存管理在这次项目升级前就已经有在用，主要的困难在于前期遗留的库存账实不符。所以重点是结合采购重新梳理了出入库的流程。因为该公司备品备件量非常大，采购业务又非常频繁。最后的实现方案也比较特殊，针对用途和价格接近物料名称也一样只是规格型号不同的备品备件，在系统里只定义了一个物料编码，采购环节通过描述区分详细规格，库存管理和存货计价不再细分


关于这个方案，当时反复讨论过多次，进行了一定的数据测试评估对成本的影响，也多次与事务所沟通。在实际操作中对于哪些备品备件可以通过这种方式处理有严格的界定。


库存管理的abc分类法在系统信息化实现时着实值得权衡。对于金额小量大的物资，如果耗费太多的精力去进行管理，应该是很不划算的。


这个项目还有一个亮点就是工程项目收入成本分析，或者叫做获利能力分析。在SAP系统了，这几乎是属于标准功能，但在当时的K3供应链系统，要实现非常有难度。最终的解决方案是，从采购到入库到出库，全关联到项目编号，该编码作为分析的Key值把收入成本费用回款全部串联起来，然后用存储过程抓出来一张大表。可以说是用最简单**的方式实现了按订单生产的分析。


现在想来，供应链的信息化项目与财务有关的环节其实也就是这些，即使是现在在做的SAP，其核心控制点也是如此，即使变也是看企业管理的重心在哪。我当时在这个项目里的优势并不在于对业务的理解和系统的熟悉，全依赖有开发基础，能快速将业务逻辑转换为系统实践，当然也源于K3系统本身的灵活性。


对信息化项目实施顾问而言，我觉得业务和技术是两面，缺一不可。理解业务是为了有能力提供更最优的解决方案，而技术是为了能让实现方案有更多的易用性，或者更多选择的可能。