技术经济学概论 第2版 教学课件 作者 陈立文教学案例 技经案例——可行性研究报告案例.docVIP

技术经济学概论 第2版 教学课件 作者 陈立文教学案例 技经案例——可行性研究报告案例.doc

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
、 中国农业银行XX分行 中间业务系统金融平台改造项目 可行性研究报告 文档编号:CG-C03-DLNH-200801-PBL01 编 写 人:XXX 审 核 人:YYY 丹东市启东信息工程研究所 2008-3-16 引言 1.1 编写目的 说明中国农业银行XX分行中间业务系统金融平台改造项目的实现在技术上、经济上和社会条件方面的可行性;评述为了合理地达到开发目标而可能选择的各种实施方案;说明并论证所选定的方案的理由,从而为公司领导决策提供参考。 1.2 背景说明 项目名称 中国农业银行XX分行中间业务系统金融平台改造项目。 任务提出者 中国农业银行XX分行。 软件运行的网络 中国农业银行内部网。 同其他系统往来 本项目涉及到与第三方系统报文交换的地方较多。 1.4 参考资料 序号 文档标题 1 中国农业银行XX分行竞争性谈判邀请 对现有系统的分析 目前面向交易的农行应用系统根据处理逻辑的不同分为三个层次:渠道层、金融产品层、核算层 中,核算层及传统金融产品主要部署在ABIS系统中,为银行客户提供传统的金融产品服务,并为其 他金融产品提供帐务逻辑处理的服务,而各种新型金融产品的应用逻辑(帐务逻辑除外)则根据业务 的不同分别分布于AIPS、中间业务平台、投资业务平台、第三方后台服务等应用系统中。这样,根据 应用部署的不同又可以按照渠道层、前置层、后台服务层等三个层次划分,如下图: 随着全国数据集中项目的稳步进行及ABIS系统的日趋稳定和完善,各分行的工作重点正逐步向 渠道层和前置层转移,渠道整合、ACBS两个项目的实施为渠道层的应用逻辑统一处理打下了坚实的基 础,而前置层上的应用处理则处于相对混乱的状态,主要有以下一些问题: 一方面,不同的业务在不同的应用系统中实现,就要求渠道层必须根据业务的不同判断其对应的后台并组装该应用系统所定义的报文,从而加重了渠道层应用处理的复杂度;另一方面,各级分行科技人员面临着总行开发推广的各种金融产品和各个不同的应用系统,还要应对各种本地化的新型金融产品,而总行开发推广的产品,大都由不同的产品组开发,有着不同的设计思想、不同的开发习惯、各种不同的工作流程、各种自定义的数据库表、不同的报表生成方式,大量的程序维护、大量的系统维护、各种不同的管理规则……,从总行到分行都在疲于奔命应付各种项目的开发、测试、推广以及技术支持。最终的结果是对业务需求的反应速度慢;技术人员进行着大量重复性的开发工作,各种低级的应用错误重复出现;同一个应用层上不同的业务归属于不同的技术人员负责,很多人做着相似的工作,从而造成人力、财力资源的严重浪费…… 金融服务平台的技术可行性分析 3.1简要描述 随着商业银行发展的需要,银行电子化建设也正向着更深的层次发展,银行的应用系统明显地呈现以下三个发展趋势:数据趋于集中、处理趋于统一、系统趋于开放。我行的全国数据大集中正在稳步实施,在前置层上建设一个开放的、处理逻辑统一的金融服务平台已是大势所趋。 随着银行间的竞争加剧,各级业务部门设计的新型金融产品越来越多,而这些新型金融产品的大部分业务逻辑都是在前置层上实现的,在此层次上的应用从业务角度上分析是千差万别、难于归纳的。但是如果将各产品的逻辑拆分成具体的功能单元,则可以发现千差万别的金融产品其实是由可归纳总结的一个个功能单元拼装而成的。我们可以对现有金融产品所涉及到的功能单元进行系统地分析、归纳和总结,统一其处理方法,而具体逻辑则通过可配置的参数体现出来。这样,产品逻辑的实现过程就是平台对产品所涉及到的各功能模块的调度过程,产品的开发则由原来的编写程序改变为对各功能单元以及功能单元的调度流程的参数化设置,产品的维护则由原来的程序维护变化为对配置参数的维护。这样,处理方法统一了,产品开发方法统一了,产品管理方法统一了,产品的维护方法统一了,产品规范统一了,前面所提出的各种问题自然迎刃而解。 事实上,在中间业务平台中已经对大部分的功能单元进行了总结和实现,并在实践中得到了认可,所以我们认为金融服务平台的实施和实现是完全可行的。 金融服务平台的应用布局 在农行面向交易的应用系统架构中,金融服务平台应当是前置层上的唯一应用处理系统,如下图所示: 在省域数据集中和全国数据集中两种模式并存的情况下,金融服务平台的应用布局如下所示: 如上,金融服务平台负责渠道的接入、后台服务的调用、本地应用处理等三部分功能的实现,在级连模式下,两个金融服务平台之间互为后台服务。金融服务平台只在各一级分行的数据中心部署,采用集中式管理和应用、分布式开发和维护的架构,全国数据中心部署的金融服务平台还可以有全国业务统计、分析、管理等功能。 金融服务平台的系统架构 金融服务平台是

文档评论(0)

时间加速器 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档