ERP原理 | 业财一体化的几种架构模式
“业财一体化”是企业信息化领域里老生常谈的话题,本来算是我很熟悉的领域,然而最近我发现随着ERP技术升级换代,业界有厂商推出各种新名词,宣称“业财解耦”是颠覆性的解决方案,甚至还搬出了高深的会计学理论名词,我越来越听不懂。
我在半年前的《业财一体化系列论坛心得 | 数字化和数据驱动的财务转型》文中,系统梳理过随着IT技术发展,企业业务作业的数字化程度提升,在“业财一体化”数字化方面的发展进程。在具体实现架构上,我将该文中提到的“业财横向一体化”的四种模式换种方式表述:
架构模式一:
从业务作业中,依据事先抽象出的标准化作业类型,产生业务凭证,并且根据记账规则自动生成财务凭证,流向总帐报表。这是会计分录(journal entry)的生成(creation)和记账(posting)过程。
到了总帐后,到期末还需经过关联交易处理、固定资产帐处理、手工收入确认(例如采用完工百分比法的项目会计)、对账调整等一系列关帐动作,生成当期的财务报表,即所谓“记录到报表(record-to-report)”的流程。这种业务和财务的自动化记账,就是经典ERP的基本原理。
这种方式适合企业的业务模式较为标准、ERP系统本身的业务模块能够覆盖大多数业务作业,例如制造业、流通业、能源行业等,适合采用这种架构。
架构模式二:
在业务平台方,开发出一个向财务系统“喂数”的平台,即根据业务类型进行抽象,从业务交易中生成标准化的业务凭证;而另一方面在财务系统方,开发出一个“接数”的通用接口,根据会计核算规则生成相应的财务凭证,这个接口也称为“会计引擎”,通过可配置的模版,可以接收各种类型的业务凭证。
这种方式适合业务类型复杂,不断会有新业务类型产生,ERP系统本身的业务模块无法覆盖部份业务作业的企业,例如电商、零售、物流、电信等行业。
架构模式三:
这种方式有个比较“厚”的业财转换机制和系统。早期的国产财务软件采用了一个“会计平台”,来实现手工记账的过程的数字化。
我在90年代做会计时,记账方式就是把一项业务活动的若干原始凭证归集拢,例如发票、出库单或者收款单,手工填制一份封页,把摘要信息、若干条借贷分录等在封页上写好,然后抄到对应科目的帐簿上。
而“会计平台”大多是将手工帐的封页变成了线上表单,做得强大的,可以配置出多种核算方式和核算规则,体现了记账的“灵活性”——既能适应管理水平较低的企业,也可以用来满足业财一体化要求较高的企业的需求。不过由于技术限制,早期这类财务软件的数据库表和界面表单是绑定的,和业务系统集成以及数据追溯的能力较差。
近年来随着技术发展,有些新的解决方案采用大宽表、数据仓库等技术来支持“会计平台”,可以记录更多的业务和财务信息,提高核算效率的同时还满足管理会计的需求,这种方式由于介于业务系统和总帐系统之间,经常被称为“财务中台”。这种架构适用于这样一些场景:1,大型集团总部的财务系统,面对多个组织的业务系统,同时处理核算和合并等需求,2,管理比较薄弱或者业务多变的企业,业务系统的前端数据质量较差,需要由财务人员进行较多的数据加工,才能满足核算要求。
企业在实施业财融合数字化时,应该根据自身业务情况、管控要求,选择合适的架构策略。传统ERP可能不能适应今天不断变化的市场环境,而有些厂商一味强调灵活、创新、解耦,忽视业财融合本身的严谨性,也是不可取的。