银行大总账.docVIP

关于银行总帐/财务系统的思考 银行总帐系统是银行后台管理系统的核心内容，对于其定位、规划和发展，各家银行基本上有一定的共识：将其从核心系统中独立出来，成为银行财务报告、财务分析的唯一数据源，并为银行管理会计提供明细、精准的数据基础。但对于如何实现上述目标，由于系统、业务现状不同，IT发展战略各异，所以各家银行都有自己的规划和线路图。下面我想结合SAP银行业解决方案的设计，探讨一下银行目前及未来总帐/财务架构的设计。 首先先明确个基本概念：“瘦总帐”和“胖子帐”（是“胖-子帐”，而不是“胖子-帐”哦）。这种提法直译自“Thin General Ledger”“Fat Sub Leger”，应该是SAP特定的说法，至少国内银行传统上不这么说。传统说法的“小总帐”是指银行内部帐，“大总帐”包括了业务账和内部帐。而“瘦”“胖”二帐，主要针对业务账。粗略的讲，“瘦”“胖”是指维度的多少。 总帐方案1 国内原有的核心银行系统大多都有总帐功能。除了业务账的核算，大多不能提供完整的财务系统功能，如固定资产卡片账管理、费用管理流程等，而是只开放界面供财务人员手工或批量登帐。这种情况下财务部门就需要使用单独的财务系统，管理小总帐。有些核心系统即使有比较完整的财务功能，但在将总帐从核心中剥离的大趋势中，有些银行采用比较稳妥的方式，先将小总帐独立出来，那么也需要单独的财务系统。 这种方式下，业务账的核算还是核心系统中，财务系统将科目级数据传入核心总帐，所以核心系统中有完整的财务数据，日余额表、资产负债、损益表等都从核心系统中出。有些行为了给独立总帐做准备，也将核心总帐的科目级数据传入财务系统（下图的核心系统和总帐系统中的虚线表示）。 总帐方案2 和方案1类似，业务账的核算还是核心系统中，但是将核心总帐的科目级数据传入财务系统，财务系统中有完整的财务数据，日余额表、资产负债、损益表等都从财务系统中出。财务系统相当于一个瘦总帐系统。 客户帐等明细账从核心或者从数据仓库/报表系统中出具。 虽然方案2比方案1只前进了一小步，但带来的提高是一大步。 n 减轻核心系统的运行压力，提高系统性能 n 在并购、调整等组织结构变更时，利于迅速实现财务整合 n 实现多维度分析和管理 n 为管理会计提供支持 后两条是针对SAP产品的，SAP的管理会计和财务会计的关系非常紧密，如果做好了SAP的财务会计，就相当于给管理会计的成本分摊和多维度分析打下了很好的数据基础，管理会计就可以专注于构建成本分摊体系和FTP了。 总帐方案3 本方案的关键就是把业务总帐从核心中分离出来，核心成了纯粹的交易系统，专注于提供高效、精确的前台服务，而和帐相关的工作全部独立出来。实现的方法就是把交易级的数据从核心导出，通过会计核算引擎进行账务处理，过账到总帐（瘦）。会计核算引擎里保存了明细总账（胖）。这种方式是核心和总帐系统的发展趋势。 下图中还加入了数据仓库。这是根据目前大多数银行的系统规划总结的。其实总帐系统需要的是稳定、准备、高效的数据源，至于采取什么方式（采取数据仓库技术or 直接从核心取数），取什么名字（数据仓库or数据平台or Staging or …），就看各自的选择了。不过数据仓库是趋势。 总帐方案- SAP SAP完整的总帐方案中包括了总帐（瘦），子帐（胖），还提供报表分析平台和ETL，也就是下图从ETL（含）以上的方案SAP都提供。用户可以根据自己的需求来选择。 SAP的子账是集成的风险和财务架构（Integrated Risk and Finance Architecture）中的一部分，也就是说SAP将财务子帐、管理会计、风险管理（信用风险RWA、经济资本、ALM等）统一考虑和设计，将上述计算分析功能构建在同一个数据源/数据集市上，保证了财务会计、管理会计、风险管理的数据来自同一的数据源，基础数据可以重复利用而且保证统一，不同目的结果数据可以分开保存、相互对账，大大提高分析的准确性、一致性和效率。这是SAP产品非常独到的地方。现在SAP还在致力于推出基于in-memory 计算的方案，届时运算速度将得到大幅提升。