毕博太平洋寿险业务财务接口系统渐进改造方案建议书--ciwuz

业务和系统一体化，增强企业竞争力。TM©2004毕博（BearingPoint）拥有庞大的管理资料库概述应用架构项目范围业务处理调整目录银行保险行业3©2004毕博（BearingPoint）拥有庞大的管理资料库项目背景根据CPIC的ITSP规划的整体要求，P07项目应该与P10项目(实施未来寿险应用系统)进行有效地集成以实现寿险业务财务的一体化。CPIC寿险总公司目前经过多年系统建设，已经拥有稳定运行的寿险业务系统(包括柜面出纳系统)、行政出纳系统、财务系统，且业务系统与财务系统之间已经形成了较为完整的业务财务接口系统。由于预计P07项目将先于P10建成，因此未来将有一段时间P07财务系统需要与现有寿险业务系统建立稳定、有效的业务核算接口，以获取财务核算必要的业务信息。但现有的寿险业务财务接口系统的部分功能与数据(主要是财务凭证生成环节与行政出纳处理环节)尚不能支持新旧财务系统的平稳过渡。概述银行保险行业4©2004毕博（BearingPoint）拥有庞大的管理资料库渐进改造目标为未来P07新财务系统的最终上线做好准备，支持未来P07新财务系统上线时系统的平稳过渡;进一步完善与实现寿险业务人员与财务人员对寿险接口系统的功能性需求，统一行政出纳的操作平台，方便和优化业务人员与财务人员的日常操作与业务处理。配合和保障CPIC寿险公司内部SOP的实施和推广，完善业务核算的数据与信息处理要求;概述银行保险行业5©2004毕博（BearingPoint）拥有庞大的管理资料库概述渐进改造原则在寿险业务财务接口系统的渐进改造中，将遵守以下建设原则：平稳过渡原则稳定性原则效用性原则实用性原则银行保险行业6©2004毕博（BearingPoint）拥有庞大的管理资料库概述应用架构项目范围业务处理调整目录银行保险行业7©2004毕博（BearingPoint）寿险财务系统PowerBuilder寿险行政出纳系统Delphi寿险柜面收付模块寿险业务人员/柜面出纳人员寿险财务出纳人员寿险财务人员分公司银行保险行业8©2004毕博（BearingPoint）寿险柜面收付模块寿险业务人员/柜面出纳人员分公司总公司P11P07数据库OracleP07财务系统OracleERP寿险财务出纳人员/财务人员报帐模块OracleInterConnect业务会话层数据表达层消息交换层银行保险行业9©2004毕博（BearingPoint）拥有庞大的管理资料库应用架构渐进改造后寿险业务、财务系统接口架构寿险业务数据库Informix寿险财务数据库Informix寿险业务系统ESQL/C寿险财务系统PowerBuilder寿险柜面收付模块寿险业务人员/柜面出纳人员寿险财务人员/财务出纳人员分公司财务出纳模块总公司P11P07数据库OracleP07财务系统OracleERP寿险财务出纳人员/财务人员OracleInterConnect报帐模块业务会话层数据表达层消息交换层银行保险行业10©2004毕博（BearingPoint）拥有庞大的管理资料库概述应用架构项目范围业务处理调整目录银行保险行业11©2004毕博（BearingPoint）上线平稳过渡彻底分离业务柜面出纳和行政出纳以财务系统中的出纳模块为基础移植现有行政出纳系统。此部分改造工作将涉及对银行日记账、银行对帐单勾帐，银行账户余额查询等功能流程。2配合P07上线平稳过渡增加“报帐”功能改变寿险业务、财务系统的交互方式。此部分改造工作将涉及日结及自动凭证生成等功能流程。3配合P07上线平稳过渡建立业务准备金台帐和应收保费催收台帐属于“报帐”所要实现的功能银行保险行业12©2004毕博（BearingPoint）完善现有柜面收付系统的功能增加解、领款的自动凭证生成在现有业务柜面出纳的财务凭证模块中增加业务出纳解、领款自动凭证生成。5完善现有柜面收付系统的功能应付、实付单独记帐处理主要问题在于是否能从业务数据库中提取相关数据6完善现有柜面收付系统的功能增加特殊收付（集中收付、代理收付、异地收付）方式在渐进改造过程中实现相关入口，待P07上线时启用功能银行保险行业13©2004毕博（BearingPoint）完善现有行政出纳系统的功能实现银行对帐单的自动导入实现电子银行对帐单的自动导入8完善现有会计系统的功能优化业务部门—财务帐套对照设置优化业务部门—财务帐套对照表的设置方法，按照组织机构的层次关系来设定和维护该对照表。9完善现有会计系统的功能各种对照表的统一管理与维护帐套对照表、科目对照表以及凭证模板的集中维护和管理。10完善现有会计系统的功能加强对操作人员银行帐户使用的授权管理银行账户的统一管理及授权。银行保险行业14©2004毕博（BearingPoint）拥有庞大的管理资料库概述应用架构项目范围业务处理调整目录银行保险行业15©2004毕博（BearingPoint）拥有庞大的管理资料库系统交互改造－共用银行帐户余额控制业务出纳和行政出纳共用同一银行帐号不可避免。通过把业务柜面和行政出纳双方共用的银行账户从逻辑上划分为两个子账户，并以配额来代表这两个子账户的余额；在银行日记帐和银行对帐单勾对的时候，这两个“子账户”依然是合并起来成为单独的一个真实银行账户；但对于涉及银行账户的收支操作流程中，业务柜员和行政出纳将观察到其各自“子账户”的配额而非整个账户的余额；涉及到的业务环节：A.日结报帐；B.业务收支；C.行政收支。银行保险行业16©2004毕博（BearingPoint）拥有庞大的管理资料库业务环节：A.日结报帐；B.业务收支；C.行政收支。系统交互改造－共用银行帐户余额控制公用银行账户余额控制日结报帐财务系统资金调度管理财务系统行政出纳寿险业务系统业务柜面出纳报帐统计本期业务柜面出纳银行日记账业务柜面出纳银行账户配额日结统计本期行政出纳银行日记账合并银行日记账行政出纳银行账户配额计算银行账户余额资金调度资金分配规则设置资金划拨银行保险行业17©2004毕博（BearingPoint）拥有庞大的管理资料库业务环节：A.日结报帐；B.业务收支；C.行政收支。系统交互改造－共用银行帐户余额控制公用银行账户余额控制业务收支寿险业务系统业务柜面出纳NoYes调整银行账户配额业务领款或业务转出业务柜面出纳银行账户配额当前配额是否足以支付记录相应流水账记录相应流水账业务解款或业务转入配额不足支付失败配额足够支付成功调整银行账户配额银行保险行业18©2004毕博（BearingPoint）拥有庞大的管理资料库业务环节：A.日结报帐；B.业务收支；C.行政收支。系统交互改造－共用银行帐户余额控制公用银行账户余额控制行政收支财务系统行政出纳模块NoYes调整银行账户配额记录相应流水账行政领款或行政转出配额不足支付失败行政解款或行政转入当前配额是否足以支付配额足够支付成功行政出纳银行账户配额记录相应流水账调整银行账户配额银行保险行业19©2004毕博（BearingPoint）拥有庞大的管理资料库系统交互改造－柜面报帐与凭证生成业务报帐与凭证生成财务系统寿险业务系统YesNo网点日结是否完成凭证生成柜面网点日结报帐清单各种科目对照表凭证模板业务机构—帐套对照表收集交易数据并汇总整理报帐向财务系统发送报帐清单凭证确认与入帐财务凭证业务主管财务会计银行保险行业20©2004毕博（BearingPoint）拥有庞大的管理资料库系统交互改造－报帐清单与凭证模板报帐清单和凭证生成模板的明细表格见业务方案银行保险行业21©2004毕博（BearingPoint）拥有庞大的管理资料库对柜面收付的改造对寿险业务系统的改造采用非常“慎重”的态度，改造将集中在柜面收付模块，对于一般其他的业务系统操作不作改动。对于日常进行业务处理的人员来说，业务处理流程和操作方式的改变主要在后台实现。增加报帐流程增加业务解领款的报帐和凭证生成应付、实付单独记帐处理准备金计提台帐报帐流程银行保险行业22©2004毕博（BearingPoint）拥有庞大的管理资料库对柜面收付的改造－增加报帐流程确认业务系统完成了某个工作时间的工作，下一步可以进行财务处理；将财务核算需要的业务信息提交至财务系统；增加报帐流程增加业务解领款的报帐和凭证生成应付、实付单独记帐处理准备金计提台帐报帐流程报账动作意味着财务核算所需要的业务信息从业务转移到了财务，该过程是不可撤销的，业务柜员的操作错误因尽量在报账之前加以修正。为了两个系统之间数据的一致性，在报账动作完成之后的修正行为均不得直接修改原有数据，而是通过红冲来达成数据差错调整的目的。从形式上来说，业务操作的改变只是增加了报帐环节，其他的计算和运行都由系统完成。银行保险行业23©2004毕博（BearingPoint）拥有庞大的管理资料库对柜面收付的改造－增加报帐流程增加报帐流程增加业务解领款的报帐和凭证生成应付、实付单独记帐处理准备金计提台帐报帐流程业务解、领款的日结报帐是业务柜面日结报帐中的一个组成部分，是本次渐进改造过程中拟增加的内容之一，从本质上是系统后台完成的工作，不会对具体的业务操作产生影响。银行保险行业24©2004毕博（BearingPoint）拥有庞大的管理资料库对柜面收付的改造－增加报帐流程增加报帐流程增加业务解领款的报帐和凭证生成应付、实付单独记帐处理准备金计提台帐报帐流程业务应付、实付的单独记帐处理是业务柜面日结报帐中的一个组成部分，是本次渐进改造过程中拟修正的内容之一。按照权责发生制的要求，经过业务处理完毕的应付款业务，要进相关成本帐，应单独将会计分录转到会计系统，而不管是否实际付款，而目前必须等到实际付款以后，应付款的会计分录才随实际付款分录一并转到会计系统。目前的方式给会计核算带来不便。应付与实付款单独记账处理以后，需要查询应付款的明细，同时，业务处理完毕以后，转入业务出纳，形成应支付的明细，业务出纳可以查询那些要支付的款项。应收、实收的分离更多是在程序后台完成，不会在业务处理流程方面造成很大的改变。