ERP原理 ｜ 业财一体化的几种架构模式

傅一平评语：

采用架构模式2。

正文开始

“业财一体化”是企业信息化领域里老生常谈的话题，本来算是我很熟悉的领域，然而最近我发现随着ERP技术升级换代，业界有厂商推出各种新名词，宣称“业财解耦”是颠覆性的解决方案，甚至还搬出了高深的会计学理论名词，我越来越听不懂。

我在半年前的《业财一体化系列论坛心得 ｜ 数字化和数据驱动的财务转型》文中，系统梳理过随着IT技术发展，企业业务作业的数字化程度提升，在“业财一体化”数字化方面的发展进程。在具体实现架构上，我将该文中提到的“业财横向一体化”的四种模式换种方式表述：

架构模式一：

从业务作业中，依据事先抽象出的标准化作业类型，产生业务凭证，并且根据记账规则自动生成财务凭证，流向总帐报表。这是会计分录（journal entry）的生成（creation）和记账（posting）过程。

到了总帐后，到期末还需经过关联交易处理、固定资产帐处理、手工收入确认（例如采用完工百分比法的项目会计）、对账调整等一系列关帐动作，生成当期的财务报表，即所谓“记录到报表（record-to-report）”的流程。这种业务和财务的自动化记账，就是经典ERP的基本原理。

这种方式适合企业的业务模式较为标准、ERP系统本身的业务模块能够覆盖大多数业务作业，例如制造业、流通业、能源行业等，适合采用这种架构。

架构模式二：

在业务平台方，开发出一个向财务系统“喂数”的平台，即根据业务类型进行抽象，从业务交易中生成标准化的业务凭证；而另一方面在财务系统方，开发出一个“接数”的通用接口，根据会计核算规则生成相应的财务凭证，这个接口也称为“会计引擎”，通过可配置的模版，可以接收各种类型的业务凭证。

这种方式适合业务类型复杂，不断会有新业务类型产生，ERP系统本身的业务模块无法覆盖部份业务作业的企业，例如电商、零售、物流、电信等行业。

架构模式三：

这种方式有个比较“厚”的业财转换机制和系统。早期的国产财务软件采用了一个“会计平台”，来实现手工记账的过程的数字化。

我在90年代做会计时，记账方式就是把一项业务活动的若干原始凭证归集拢，例如发票、出库单或者收款单，手工填制一份封页，把摘要信息、若干条借贷分录等在封页上写好，然后抄到对应科目的帐簿上。

而“会计平台”大多是将手工帐的封页变成了线上表单，做得强大的，可以配置出多种核算方式和核算规则，体现了记账的“灵活性”——既能适应管理水平较低的企业，也可以用来满足业财一体化要求较高的企业的需求。不过由于技术限制，早期这类财务软件的数据库表和界面表单是绑定的，和业务系统集成以及数据追溯的能力较差。

近年来随着技术发展，有些新的解决方案采用大宽表、数据仓库等技术来支持“会计平台”，可以记录更多的业务和财务信息，提高核算效率的同时还满足管理会计的需求，这种方式由于介于业务系统和总帐系统之间，经常被称为“财务中台”。这种架构适用于这样一些场景：1，大型集团总部的财务系统，面对多个组织的业务系统，同时处理核算和合并等需求，2，管理比较薄弱或者业务多变的企业，业务系统的前端数据质量较差，需要由财务人员进行较多的数据加工，才能满足核算要求。

企业在实施业财融合数字化时，应该根据自身业务情况、管控要求，选择合适的架构策略。传统ERP可能不能适应今天不断变化的市场环境，而有些厂商一味强调灵活、创新、解耦，忽视业财融合本身的严谨性，也是不可取的。

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！