商业银行信息管理系统

商业银行信息管理系统（精选6篇）

商业银行信息管理系统 第1篇

商业银行管理信息系统开发方法浅探

我国加入WTO后，国家最终将放弃对国有商业银行提供无限量的信用支持，金融机构必然会在市场经济的“大海”中按自然规则“物竞天择”。要想在激励的竞争中立于不败之地，国有商业银行必须加快金融电子化的步伐，采取有效措施，迅速建立以决策支持系统为核心的管理信息系统，高效地处理和利用信息，提高信息化水平，增强竞争实力。如何根据开发系统的规模、技术复杂的程度、管理水平的高低、技术人员的素质及开发时间的要求等不同要素，确定管理信息系统开发方法，确保以较小的投入取得最优的效果，这一直是管理信息系统开发人员所关注的课题。笔者根据开发实践，将管理信息系统的开发方法，归纳为以下几种：

一、周期法 该方法是由结构化系统分析和设计组成的一种管理信息系统开发方法， 图1结构化生命周期法的开发过程 亦称结构化生命周期法。其基本思想是将系统的生命周期划分为系统调查、系统分析、系统设计、系统实施与转换、系统维护与评价等阶段。应用系统工程的方法，按照规定的步骤和任务要求，使用一定的图表工具，完成规定的文档，在结构化和模块化的基础上进行管理信息系统的开发工作。结构化生命周期法的开发过程一般是先把系统功能视为一个大的模块，再根据系统分析设计的要求对其进行进一步的模块分解或组合。基本做法如图1所示。 结构化生命周期法主要特点是：

⑴开发目标清晰化。结构化生命周期法的系统开发以“用户第一”为目标，开发中要保持与用户的沟通，取得与用户的共识，这使管理信息系统的开发建立在可靠的基础之上。

⑵工作阶段程式化。结构化生命周期法每个阶段的工作内容明确，这便于开发过程的控制。每一阶段工作完成后，要根据阶段工作目标和要求进行审查，这使阶段工作有条不紊，也避免为以后的工作留下隐患。

⑶工作文件规范化。结构化生命周期法每一阶段工作完成后，要按照要求完成相应的文档报告与图表，以保证各个工作阶段的衔接与系统维护工作的便利。

⑷设计方法结构化。结构化生命周期法采用自上而下的结构化、模块化分析与设计方法，使系统间各个子系统间相对独立，便于系统的分析、设计、实现与维护。 结构化生命周期法被广泛地应用于银行管理信息系统的开发中。该方法适合于银行业务工作比较成熟、定型的系统，如作为银行管理信息系统信息采集的自助银行、企业银行、电话银行、销售点服务系统、多媒体查询系统等为客户提供金融服务、信息咨询的系统。在管理系统开发方式上，银行根据系统的复杂程度以及自己的人力、资金等状况，可在独立开发、合作开发、委托开发、购买现成软件这四种模式中选择其一。 二、原型法 该方法是一种根据用户需求，利用系统快速开发工具，建立一个系统模型，在此基础上与用户交流，最终实现用户需求的快速管理信息系统开发方法。 原型法开发过程包括系统需求分析、系统初步设计、系统调试和系统转换、系统检测与评价等阶段。用户仅需在系统分析与系统初步设计阶段完成对应用系统的描述，开发者在获取一组基本需求定义后，利用开发工具生成应用系统，快速建立一个目标应用系统的最初版本，并把它提交给用户试用、评价、根据用户提出的修改补充，再进行新版本的开发，反复这个过程，不断地细化和扩充，直到生成一个用户满意的应用系统。 原型法的开发过程如图2所示。  目前,我国市场上的管理信息系统快速开发工具有：POWER BUILDER、VISUALBASIC、VISUALFOXPRO、DELPHI等。利用这些面向对象的开发工具，可使开发者的精力和时间集中于分析应用问题及抽取反应应用系统实质的事物逻辑上，而不再拘泥于应付处理繁琐的开发实现细节，节省了大量的编程工作，并且使系统界面美观，功能较强。 原型法具有开发周期短、见效快、与业务人员交流方便的优点，被广泛地应用于银行的财务报表系统、信贷管理系统、工资人事管理系统、固定资产管理系统等的开发中。 三、综合法 综合法是将周期法和原型法两者结合使用，采用结构化生命周期法的设计思想，在系统分析与系统初步设计上采用原型法作出原始模型，与用户反复交流达成共识后，继续按结构化生命周期法进行系统详细设计及系统实施与转换、系统维护与评价阶段的工作。 综合法的优点是它兼顾了周期法开发过程控制性强的特点以及原型法开发周期短、见效快的特点。商业银行在管理信息系统开发中，可针对不同的实际情况，合理采用综合法，使开发过程更具灵活性，往往会取得更好的开发效果。 四、实例 今年上半年笔者采用原型法，开发了交通银行南通分行计划信息管理系统，下面就以该系统为例具体介绍一下原型法的主要开发过程。

（ 1）系统需求分析、系统初步设计。通过与计划处交流，明确了本系统的设计目标，即通过对财会处人民币和国外部折美元会计月报表、资产负债表、损益表及计划处信贷收支表数据进行收集、存储、检索、传输、加工、分析，为计划处及其它管理部门的科学决策服务。并根据确定的设计目标初步完成系统基本数据流图、主要功能模块图、网络结构图的设计。

（2）系统模型的确定。为实现不同部门间信息资源的共享，本系统的基本模式设计为典型的Client/Server体系结构，在分行计划处设立数据库服务器，作为数据处理中心，计划处及其它管理部门的客户机，通过局域网与服务器相连，进行操作。Server端采用Sybase数据库作为数据库系统，Client端采用PowerBuilder 6.5作为开发工具，网络协议采用TCP/IP的通讯协议。

（3）系统模型的实现。使用面向对象的PowerBuilder 6.5设计界面快速且美观，因此本系统的Client端设计重点不是在界面设计上，而是在提高系统的通用性上。由于计划处报表统计条件改变频繁，这给生成报表数据带来一定的难度。本系统设计上采用?quot;参数表驱动法“，使数据与程序相分离，即基于通用报表结构的报表程序，极大地减轻了报表的编程工作量。Server端设计主要是建立帐务类、字典类、控制类系统数据库表。

（4）用户审核。将本系统的最初版本提交给计划处使用，笔者根据计划处在使用过程中提出的修改意见，不断完善系统，如此重复，直至计划处满意为止。

（5）系统维护与评价。本系统提交给计划处正式投入使用，为维护方便，笔者建立系统开发档案，至此，本系统的开发过程基本结束。 电子商务网站访问量的统计 南通航运职业技术学院 王建华 内容提要：作者就电子商务网站建设中的一个实际问题--网站访问量统计，介绍了电子商务网站访问量统计信息和方法。 关键词：点击数；页读数；访问人数；访问量 我们的主页的页读数是多少？有多少人在访问我们的网站？这往往是电子商务网站迫切需要知道的实际问题。 遗憾的是，大多数电子商务网站建立初期，往往只考虑网站的内容和版面，并没有想到某

一天会要跟踪网站的访问量。当广告客户询问网站的访问量，想知道有多少人访问网站，浏览网页时，为跟踪访问量忙得疲惫不堪的工作人员往往拿不出令人信服的统计资料。本文就此问题，谈谈电子商务网站访问量的统计信息和方法，目的在于抛砖引玉。

一、点击数和页读数 Web服务器能记录它得到的每次请求的信息。对我们有用的请求的信息包括：点击的日期和时间 、主机名 、请求 、被授权的访问者的登录名、Web服务器的反应码、涉及者、访问者的user agent、访问者的IP地址、访问者的主机名（如果其IP地址可以被翻译出来）、传输的字节数、被访问的文件的路径、访问者发送的Cookies 、Web服务器发送的Cookies 。 上述能收集到的访问量数据不多，而且得到的信息也不可靠。可用的信息不准确，但不是完全不可用。虽然数据不精确，但仍然可以知道有多少人在用我们的网站。正如我们知道的，用计数器可以很容易地知道有多少点击数，但对于更精确的分析，我们将不得不存储得到的点击数。一个简单的办法是把信息存储在Web服务器的log文件中，然后定期地加载数据库的table或直接把信息写到数据库的table中。 点击是我们的服务器收到的任何文件请求，包括图像、声音文件和任何出现在页面上的东西。如果直接加载数据到数据库中，我们需要一个已经实现这种功能的Web服务器（如MicrosoftIIS），或需要源代码。也可以用第三方的API，如Apache的DBILogger。实现了这样的功能，就可以收集失败点击的次数（只需计算状态码为4xx的点击的数量）。 页读数更准确些，因为它把一页当作一个整体 ，而不是它的各个部分。计算点击数不如计算页读数得到的信息量大，而且点击数计算的结果与其它网站很难进行比较。页读数就不同了：按时间块的页读数，可以查看每5分钟的页读数变化；按访问者的域名分类的页读数，可以确定他们是在工作时，工作前还是工作后访问我们的网站；按登录用户的页读数和非登录用户分类的页读数，可以确定允许用户登录是否值得；按信息来源分类的页读数 ，可以确定访问者进入页面是通过一个连接还是一个旗帜广告？他们从哪里来？这些信息可以帮我们了解访问者的兴趣，可以确定往哪儿投资，与哪些人合作；按访问者的硬件平台、操作系统、浏览器及其平台统计的页读数 ，可以确定 Mac用户和PC用户的比例各为多少？Netscape和IE的用户各为多少；按访问者主机统计的页读数 ，可以确定访问者中有多少人用AOL？有多少人用Earthling? 总之，页读数的统计，也就电子商务网站访问量的统计鼻子

二、页读数的统计 为了计算页读数，需要制定一些把页读数从点击数中区分出来的方法。下面是电子商务网站经常考虑到的一些因素：文件名、文件类型（HTML、GIF、WAV等）、Web服务器的反应码、访问者的主机。一旦确定了哪些点击是页读数，哪些不是，就可以计算网站的页读数了。我们按照文件的路径确定页读数算在哪个具体部分，如www.hotw.com/web/99/13/index0a.html算做Web的页读数；www.hotw.com/sys/99/12/index3a.html则算做Sys的页读数。如果这种标准在网站的各个层次上实行，可以得到网站的详细统计。我们有时希望把一个页读数算在某一部分，在其它部分算在另一部分。 电子商务网站页读数的统计方法通常有如下几种。

1．远程数据跟踪 页读数增长的速度是多少？年底的时候我们期望的页读数是多少？网站的哪部分页读数增长得最快？哪部分最慢？ 各种浏览器的比例随着时间变化的趋势是怎样的？ 人们过多久访问我们的网站一次？ 从其它网站的旗帜广告第一次进入我的网站的人，他们随后读了多少页？ 一旦我们看到可用的各种类型的信息，我们就会得到需要长距离回答的各种问题。如果我们对回答这些问题感兴趣，那么多天的跟踪就会有用。 进行远程数据跟踪，可以考虑使用数据库。我们可以编写程序从点击数日志中提取想要的信息。如果数据库设计得合理，查询信息的时间比用程序从日志文件中提取信息快好多倍。数据量越大，这种差别越明显。 如果只存储感兴趣的点击，可以节省大量的数据空间。 也可用SQL从数据库中提取数据。SQL是一种小型的`、简练的只需学很少的命令和语法的语言。而且，其命令结构简单明晰，好的程序员建立一个SQL查询比编程做同样的事快得多。而且其结果错误更少，更容易理解。 如果不想用SQL，可以用一种数据库访问工具如MS Access 或 Excel。这些工具都很好用，而且是图形界面。

2．计算访问时间 电子商务网站的市场部和广告部都喜欢统计访问时间，即某人在离开我们的站点前停留了多长时间。但是，用HTTP是不可能确定这个数值的。 假设一个客户在正午时访问Hot的一个页，然后该客户在12:28 p.m.访问Hot的另一页，那么该客户对Hot的访问时间是多长呢？该客户可能在这28分钟内一直盯着第一个Hot页，但是该客户也可能在这28分钟内新开了一个窗口，浏览另一个网站。 但是，我们的用户确实需要这种信息，那么该怎么告诉他们呢？ 我们可以去Internet Advertising Bureau，它定义了一个访问为”没有连续30分钟的不活动的访问者的一系列页面请求 “。当有人问起我们的网站的访问时间时，我们也可以在IAB的定义的基础上告诉他们。

3．计算访问来源 如果访问者点击某个连接或某个旗帜广告到达我们的网站，他的浏览器会随着这个请求发送他刚离开的站点的URL，这个URL称为”referer"。 Netscape和IE对访问的来源的处理方式不同。如果我们点击原始页到一个有frame的页，Netscape将把原始页作为对包含frame的页和每个frame中的页的来源；IE把原始页作为包含frame的页的来源，这个包含frame的页反过来把它本身作为各个frame页的来源。进一步，我们可能还会得到每页的页读数的数据。如果把网站分成频道或部分，则可能得到每部分的数据。 需要注意的是，上述方法计算出的页读数不是我们的网站的实际页读数。这是因为我们统计的是在Web服务器的访问日志中计算访问记录，而很多请求从不在访问日志中留下痕迹。因为没有十全十美的方案，所以使用哪种统计方法取决于网站的实际情况。

三、计算访问人数 计算访问人数比计算页读数难得多，而且没有绝对可靠的计算访问者人数的方法。 基本上有三种信息可以用来跟踪访问者：IP地址、成员名（如果网站使用成员注册）和cookie。 最简单的办法是计算log文件

中的唯一IP地址的数量。但是，最容易的办法通常不是最好的办法。这种方法是可用的最不准确的办法。大多数人在每次连接时得到不同的IP地址。这是因为很多ISP为用户赋予动态的IP地址，例如，当一个AOL用户上网时，AOL给他一个IP地址，当他断开连接时，AOL把这个地址赋给另一个用户。这样，当我们进行统计时，我们不知道这是两个用户。 如果要求用户使用成员身份登录，统计将很容易和准确。但很多人不喜欢需要登录的网站，这就使得跟踪成员名的统计没有实际意义。 最后，可以使用cookies。为每个访问者定义一个包含唯一值的cookie，我们把它称为机器ID。如果某人访问我们的网站时没有提供机器ID（可能她是第一次访问，或者她的浏览器不接受cookies），把她当作新用户，并为她访问的页发送一个cookie。 使用这种方法要注意的是：

1． 很多人关掉了cookies的功能；

2． 可以用浏览器删除旧的cookies；

3． cookie存储在访问者的机器上（ 访问者可能用不只一台机器访问我们的网站）；

4． 多人公用一台机器；

5． 代理服务器对cookies的处理不同。 考虑到以上因素，我们在电子商务网站这样做： 如果计算一天的访问者数量，我们计算成员名；对于没有成员名的点击，我们计算cookies； 对于既没有成员名，也没有cookies的点击，我们计算IP地址；如果计算多天的访问者数量，我们只用cookies；如果只关心某一天的数据，可以用处理log文件的程序，如果希望得到多天的数据，应该把它存储在数据库中。 如果不能准确记录每个单一请求，当然就不能得到网站的访问者的完整数量。 前面没有讨论的一个问题是cookie和新的访问者。假设我们想计算昨天的访问者人数，就要用我们前面讨论的方法。当某人第一次访问我们的网站时，他还没有cookie，我们的Web服务器随着被请求的页发送给他一个新的cookie。现在，假设这个访问者然后请求第二页，这时的请求有一个cookie，访问者的点击记录将有一个cookie。 当我们用Perl脚本（或别的什么）计算访问者数量时，如果允许认证，我们首先计算成员名；对于没有成员名的点击，可以计算cookie；对于没有成员名或cookie的点击，可以计算远程IP地址。但这种方法重复计算了新的访问者。一个访问者的第一次点击没有cookie或成员名，所以IP地址被计算在内。这个访问者的随后的点击将用成员名或cookie计算。 在电子商务网站中，我们记录cookie被发送的次数，虽然我们没有收到cookie。每一个夜晚，我们寻找包含被发送cookie的点击。对于每一个，我们检查等于那个被发送的cookie的被接收的cookie的其它点击。如果能找到，我们在把这些点击数装载到数据仓库之前把发送的cookie值转移到接收的cookie的字段。当使用我们的计算方法时，此人将只被计算一次。注意我们不只是简单地把发送的cookie和接收的cookie进行合并。这么做会重复计算屏蔽cookie的人。 假设我们有不止一个计算点击数的域，例如，123.com和abc.com。我们可以计算到123.com和abc.com的访问者数量，但是总数肯定不会与这两个数的和相等。 为什么会这样呢？假设一个访问者访问123.com，他没有cookie，于是我们的Web服务器发送一个给他。然后他又访问abc.com，访问者的浏览器不会发送123.com的cookie给xyz.com的Web服务器。这样，abc.com的Web服务器发送另一个cookie给访问者，对于一个访问者有两个不同的cookie。解决这个问题的办法是使用一个主域名，如123.common.com和abc.common.com，这样可以有一套cookie。

商业银行信息管理系统 第2篇

（五）设立一个由来自高级管理层、信息科技部门和主要业务部门的代表组成的专门信息科技管理委员会，负责监督各项职责的落实，定期向董事会和高级管理层汇报信息科技战略规划的执行、信息科技预算和实际支出、信息科技的

（六）在建立良好的公司治理的基础上进行信息科技治理，形成分工合理、职责明确、相互制衡、报告关系清晰的信息科技治理组织结构。加强信息科技专

（七）确保内部审计部门进行独立有效的信息科技风险管理审计，对审计

（八）每年审阅并向银监会及其派出机构报送信息科技风险管理的报

（九）（十一）确保本法人机构涉及客户信息、账务信息以及产品信息等的核心系统在中国境内独立运行，并保持最高的管理权限，符合银监会监管和实施现场

（十二）及时向银监会及其派出机构报告本机构发生的重大信息科技事故

（十三）配合银监会及其派出机构做好信息科技风险监督检查工作，并按

（十四）（一）业务战略和信息科技风险管理

（二）确保信息科技战略，尤其是信息系统开发战略，符合本银行的总体

（三）负责建立一个切实有效的信息科技部门，承担本银行的信息科技职责。确保其履行：信息科技预算和支出、信息科技策略、标准和流程、信息科技内部控制、专业化研发、信息科技项目发起和管理、信息系统和信息科技基础设施的运行、维护和升级、信息安全管理、灾难恢复计划、信息科技外包和信息系

（四）确保信息科技风险管理的有效性，并使有关管理措施落实到相关的

（五）（六）

（二）信息系统开发、测试和维护。

（三）（四）

（五）（六）

（七）

（三）（四）

（六）（七）

（五）域的性质，如生产域或测试域、内部域

（二）系统日志。系统日志由操作系统、数据库管理系统、防火墙、入侵检测系统和路由器等生成，内容包括管理登录尝试、系统事件、网络事件、错误

商业银行应保证交易日志和系统日志中包含足够的内容，以便完成有效的内部控制、解决系统故障和满足审计需要；应采取适当措施保证所有日志同步计时，并确保其完整性。在例外情况发生后应及时复查系统日志。交易日志或系统日志的复查频率和保存周期应由信息科技部门和有关业务部门共同决定，并报信息科

操作风险、财务损失风险和因无效项目规划或不适当的项目管理控制产生的机会

术人员和承包商，尤其是从事敏感性技术相关工作的人员，应制定严格的审查程

（三）充分审查、评估外包服务商的财务稳定性和专业经验，对外包服务

（四）考虑外包协议变更前后实施的平稳过渡（包括终止合同可能发生的

（五）关注可能存在的集中风险，如多家商业银行共用同一外包服务商带

（三）（四）应将涉及本银行客户资料的外包作为重要外包，并告知相关客户。

（五）严格控制外包服务商再次对外转包，采取足够措施确保商业银行相

商业银行信息管理系统 第3篇

容量管理致力于根据业务发展需求, 在恰当的时间 ( 在需要的时候) 以恰当的成本协调地提供所需的信息系统资源。通过不同层面、不同手段的容量管理方法的研究已成为国内外研究的热点, 而信息系统性能容量管理是其中重要一部分, 其在确保信息系统容量经济合理、服务可用性、业务可满足性等方面有重要作用。精细化的容量管理可以合理的对基础设施资源进行评估, 满足当前及可预期时间的业务需求, 避免由于业务增长、促销活动等原因引起的信息系统不足以支撑业务运行, 进而出现业务缓慢或终止的风险。

制定适合的信息系统性能容量管理策略, 对有效监控、管理信息系统资源有重要现实意义。对此, 从信息系统的角度对容量管理进行讨论和研究, 从数据中心现有的运维环境出发, 建立适合的信息系统容量管理策略, 实现有效的容量分析、测量和风险识别, 提高日常容量管理工作的合理性和有效性, 确保能够经济、合理地满足商业银行生产系统在容量方面的各项需求。

1 引言

信息系统容量是指信息系统以及支持其运行的信息系统基础设施可以提供的最大能力、空间或吞吐量。对于信息系统来说, 业内常使用单位时间处理事务数、响应时间和并发量这些指标来衡量其容量。

容量管理通过监控分析信息系统资源的使用状况, 进行必要的优化调整, 制定容量计划, 保障信息系统正常运行, 支持业务发展。也就是说, 对于信息系统, 通过一定的手段对其依赖的信息系统资源的使用情况进行监控, 如CPU利用率情况, 结合信息系统容量来判断目前运行所用资源是否合理, 并给出管理计划。

因此在信息系统性能容量管理的研究中, 涉及到如下关键概念:

事务处理能力 (TPM) :每分钟事务处理量。交易类系统中常代表“每分钟系统处理完成的交易量”, 批量类系统中常代表“每分钟系统处理完成的任务数”, 或其他可适用于代表信息系统处理能力的指标。通常在习惯上业内以“交易”代称“事务”。

响应时间:信息系统从接收一个事物到处理完成该事物的耗时, 通常以单位时间或指定事物处理总量的总响应时间来计算平均响应时间。

并发量:信息系统单位时间处理的事物量, 一般以同时点TPM、响应时间、时间长度计算平均并发量。

CPU利用率:信息系统所在逻辑服务器的CPU资源使用率, 对于集群部署的信息系统, 会通过一定算法得出集群逻辑服务器的整体CPU利用率。

2 信息系统容量测量

商业银行信息系统在开发阶段做性能测试、压力测试, 分别从投产前和投产后两个角度对信息系统性能容量测量方法进行介绍, 目的是为了解决“如何获取投产前的信息系统性能容量基线”和“如何对已投产的信息系统性能容量进行测量”。

2.1 信息系统的性能测试

信息系统在投产上线前, 需要尽可能准确地进行容量测量。通过非功能测试和孤岛环境测试, 为建立信息系统容量基线提供测试数据。

测试环境通常按一定比例分配相应系统资源进行测试, 然后按照线性比例对容量进行评估。通过测试验证信息系统是否满足容量需求、发现性能拐点, 形成上线参数、测试报告, 指导信息系统建设容量管理基线。

孤岛环境测试又称为准生产测试, 是在信息系统正式投产前, 通过网络隔离等手段预防生产影响, 在其实际投产使用的系统资源中进行测试, 以得到更加准确的信息系统性能容量指标。

测试过程采用负载发起机和挡板程序模拟交易的渠道端与服务端, 测试场景采用联机交易模型进行配比, 每组场景单独测试, 按照并发用户数梯度等差设置;按照设置的场景逐步增加压力, 直到满足测试出口条件 (满足资源阈值、达到性能拐点或其它约束条件) , 结束测试。通过这种方式, 可得出如下容量指标:事务处理能力 (TPM) 、响应时间、业务成功率、系统资源使用率等。

为了尽可能准确的测试出信息系统性能容量, 在进行环境准备、案例设计和测试过程中总结出以下需要注重的环节:

2.1.1 测试环境

(1) 测试环境的部署方式应与生产环境的部署方式一致, 如同为集群方式部署;

(2) 测试环境应与生产环境服务器品牌保持一致。生产环境若为物理服务器/ 虚拟服务器, 测试环境应与生产环境保持一致;

(3) 测试环境软件配置应与生产环境或目标投产环境相同, 如测试环境的操作系统、数据库、中间件等版本与补丁应与投产要求的主推版本一致;

(4) 应提前分析测试环境与生产环境的基础设施差异, 包括网络带宽、存储性能等;

(5) 对于重要信息系统, 当服务器配置无法与生产环境保持一致时, 需保证测试结果达到设计要求。

2.1.2 测试案例设计

(1) 涉及客户端的测试应尽量模拟完整的客户行为;

(2) 测试环境数据库中的数据量、数据分布应与生产环境保持一致;

(3) 设计单交易测试场景时, 应选取对响应时间要求苛刻的交易和典型交易;设计组合交易测试场景时, 应尽量模拟生产环境中的交易配比。

2.1.3 测试过程

(1) 性能测试应能验证软件性能是否满足设计中的相关需求、能识别系统瓶颈, 必须测到信息系统性能拐点;

(2) 性能测试开始的必要条件是信息系统已处于一个比较稳定的状态, 系统架构、主要代码、中间件、数据库等都不再有较大变化;

(3) 性能测试应尽量包含所有交易路径应, 并避免前/ 后端信息系统对测试结果产生影响。

2.2 信息系统的压力测试

压力测试在本文中专指实际生产环境中, 通过一定手段对信息系统服务器进行加压, 收集服务器在大压力情况下的操作系统、中间件、应用等的运行数据并进行分析, 以验证服务器容量、性能拐点、资源瓶颈等是否与预期相符, 提供系统优化、资源调整的依据。与上面性能测试不同, 压力测试使用已投产的生产环境, 真实交易数据, 因此通过压力测试得到的容量指标更加准确。

压力测试方法:测试时间应选在交易量相对较低并平稳的时段, 且应通过预估判断交易量可达到测试目的;在进行压力测试的过程中, 逐步减少目标部署单元的服务器数量, 将压力逐步引向少数服务器;当系统容量接近理论临界值时, 应以最小粒度减少系统容量, 以便于测试结果分析。

为了尽可能准确的测试出信息系统性能容量, 在进行案例设计和测试过程中应关注以下各个环节:

(1) 在设计压力测试时, 应明确测试的目标信息系统、模块、部署单元, 避免前后端信息系统、模块、部署单元对测试结果产生影响。

(2) 在设计生产环境压力测试场景前, 应全面评估可能对性能、容量产生明显影响的软硬件配置, 在测试场景设计过程中设计不同配置的测试场景。

(3) 若在生产环境中同时存在软、硬件配置不同的服务器, 应优先设计低配服务器的测试场景, 避免系统在大压力的情况下出现木桶效应。

(4) 设计的测试场景应充分利用测试时间窗口。在每个场景中, 应至少保证10 分钟以上的系统稳定运行时间。

(5) 应针对每个测试场景设计应急预案及应急预案的触发条件, 避免测试影响安全生产。

(6) 一旦测试人员发现系统异常或出现系统告警, 数据记录员记录异常情况内容及时间点, 测试指挥员应根据异常和告警内容判断是否继续进行测试或是否进入系统应急流程。

3 信息系统容量评估

从计算资源和并发能力两个方面对信息系统性能容量的日常监控和评估进行介绍, 解决“如何分析信息系统的容量是否合理”。

3.1 数据收集

数据是研究的基础。对性能容量管理实践验证主要在三个方面的数据进行收集与分析, 上线前的容量数据主要是非功能测试的结果, 通过测试报告方便的获取;压力测试通过实验对数据进行收集整理;日常运行数据通过监控平台采集数据收集整理。

3.2 信息系统计算资源

信息系统的计算资源是信息系统处理业务的基础, 通常用CPU利用率代表。通过对信息系统数据的观察, 可以判定TPM与CPU利用率之间存在关系, 尤其对于一个依赖于计算资源的业务系统, 在一定的边界限制内, TMP与CPU应基本保持相同的比例关系, 当实际数据符合这个比例关系时, 可以依此推测预期TMP与CPU相互的对照值, 当实际数据脱离比例关系一定范围时, 认为测试数据已失去参考意义。为直观观测他们之间的关系, 通过TMP与CPU观测值进行容量监测及预警, 本文提出收集TPM与CPU对应数据, 设计绘制TPM-CPU关系图, 示意图如图1 所示。

Mk (xk, yk) :通过性能测试获取不同压力下的相关数据, 按照生产配置比例换算后的TPM和对应的CPU利用率, 其中Mkm (xkm, ykm) 包含测试得出的性能拐点值。

Mi (xi, yi) :为每天信息系统TPM峰值与对应时刻的CPU利用率。

Mj (xj, yj) :为每天信息系统CPU利用率峰值与对应时刻的TPM值, 该指标作为参考可用于分析信息系统TPM-CPU是否峰值关系对应, 可间接验证信息系统是否属于计算资源消耗型、是否存在其他资源消耗任务 (例如批量任务等) 。当出现系统故障时, 应对噪点数据进行处理。

F1:TPM与CPU利用率存在一定函数关系, 从原点出发经过Mk1…Mkm拟合的一条曲线F1作为TPM-CPU的理论关系线 (绿线) 。

F2:取F1线上每一点的y值 ±k1, x值不变, 拟合一条曲线F2作为关系失效预警线 (黄线) 。

F3:取F1线上每一点的y值+k2 (k2>k1) , x值不变, 拟合一条曲线F3作为关系失效警告线 (红线) 。

Fa:CPU利用率生产安全线, 根据逻辑服务器的高可用部署方式决定, 其中

Fb:CPU利用率低效线。如果CPU利用率长期低于Fb, 则代表逻辑服务器资源过度分配, 应分析资源降配方案。

x=c:为预期时间业务需求的指标值, 也是性能测试的目标值。当TPM>c, 则代表生产系统业务处理量已超过预期, 性能测试存在失效风险, 应沟通业务部门重新分析业务需求, 分析信息系统架构, 并重新进行性能测试。

F11 (压测修正) :由于生产环境与测试环境存在着基础设施差异, 所以生产压测的数据在反应信息系统性能容量方面更为精准。在进行生产压测后, 根据不同压力场景下的数据, 对F1进行修正。

监测及预测方法 (以Mi (yi<Fa) 为例) , 存在三种情况:

情况1:如果 (F1 (xi) -k1) <yi< (F1 (xi) +k1) , 则TPM-CPU关系偏差在允许范围内, 基本符合预期规律。可以通过F1判断预期TMP与系统计算资源的对照关系, 进而对容量规划给出可靠依据。

情况2:如果yi< ( F1 ( xi) - k1) o r (F1 (xi) +k1) <yi< (F1 (xi) +k2) , 则TPM-CPU关系可能存在失效风险。表明脱离了测试所得的关系模型, 虽然没有性能容量风险, 但是不能通过F1判断预期的关系数据。

情况3:如果yi> (F1 (xi) +k2) , 则TPM-CPU关系与预期规律出现极大偏差, 无法预测的同时, 信息系统存在随时突破计算资源使用率限制的风险。

尤其在一些版本上线之后, 如果出现了情况2 或情况3, 此时应当分析关系失效原因, 并重新发起性能测试。

3.3 信息系统并发能力

信息系统的并发量代表瞬时的业务处理能力, 是其性能容量管理的重要指标。但并发量属于瞬时数据, 通常并不会进行统计日志的输出, 也很难直观地对并发量进行容量评估, 但并发量与TPM和响应时长 (RES) 之间存在一定关系, 根据相关指标设计一种模型估算并发量及其趋势。通过对信息系统并发量估算值进行容量监测、预警及预测, 本文提出收集每日并发量对应数据, 设计绘制并发量预警观测图, 如图2 所示。

F1 (x) :每个信息系统在设计初期都有拟定的最大并发量, 通常由进程数、程序限制、参数配置等决定, 绘制一条最大并发量曲线, 作为并发量理论峰值线。

F2 (x) :取系统容忍的最大并发量的一定比例 (k) 作为并发容量预警线, 其中0<k<1。

Ci (xi, yi) :为日并发量峰值, xi为对应日期, yi为对应日并发量峰值。

通过TPM值和对应的平均响应时长约算平均并发量, 公式如下:

其中ti代表xi对应的最大TPM, ri代表ti对应的平均响应时长, 以毫秒为单位。按照业内经验, 对系统最大并发量估值为:

当yi<k·a, 并发量容量处于合理状态;

当k·a<yi<a, 并发量容量出现风险, 应进行评估并准备扩容方案;

当yi=a, 并发量容量已不足以支撑全部业务处理需求, 将发生流控或交易堵塞。

可通过简单函数拟合并发量趋势曲线, 通过拟合函数初步预测未来信息系统并发量趋势。根据信息系统特性, 如周期性波动较大, 在预测趋势线时, 应对噪点数据进行处理。

4 结论

容量管理对于支撑信息系统的服务水平达到既定目标, 保证系统安全稳定运行具有至关重要的作用。信息系统的性能容量管理分为容量测量和容量评估两个方面, 容量测量中的性能测试指导上线前对信息系统的性能容量进行测量并建立容量基线, 而压力测试则是在信息系统上线之后, 通过一定的手段在生产资源环境下对信息系统性能容量进行准确测量并修正容量基线。在容量评估中, 本文提出两种对信息系统资源进行监控和评估的模型, 通过对生产系统日常运行数据的收集整理和分析, 得出容量状态, 并给出容量规划建议。

摘要：通过监控、跟踪、分析信息系统的资源使用状况, 对信息系统资源进行调整、分配、优化, 确保业务处理的顺利开展, 对于保障信息系统的稳定运行具有至关重要的作用。本文基于商业银行信息系统的性能、容量管理领域, 旨在建立合理的信息系统性能容量测量和评估方法, 通过实践分析结合根据不同方面的容量研究结果, 对信息系统的容量状态进行判断, 建立合理的信息系统性能容量评估模型。

商业银行的信息科技风险管理 第4篇

关 键 词： 商业银行；信息科技；风险管理

中图分类号： F830.33 文献标识码：A 文章编号：1006-3544（2013）05-0031-02

一、商业银行信息科技风险

在信息技术与银行业务深度融合的今天，信息科技风险事件往往涉及范围广、客户多、金额大，在给银行造成经济损失的同时，也会带来很大的声誉损失。银监会前主席刘明康曾表示：“如果银行系统中断1小时，将直接影响该行的基本支付业务；中断1天，将对其声誉造成极大伤害；中断2～3天以上不能恢复，将直接危及其他银行乃至整个金融系统的稳定。”因此，可以毫不夸张地说信息科技安全运行和健康发展是银行业务正常开展的重要保障和基本前提， 关乎银行声誉、金融安全和社会稳定。表1显示了近年来商业银行发生的几起典型信息科技风险事件。

根据中国银监会发布的《商业银行信息科技风险管理指引》，信息科技风险是指信息科技在商业银行运用过程中，由于自然因素、人为因素、技术漏洞和管理缺陷产生的操作、法律和声誉等风险。在巴塞尔新资本协议体系中，信息科技风险被视为操作风险的一种。它具有区别于一般操作风险的特殊性：（1）风险因素复杂，大量使用外包和新技术使得风险控制的复杂度大幅提高。（2）潜伏性、偶发性和不确定性突出。比如，通过充分风险论证的生产系统，短期内无风险隐患，而随着生产环境的压力逐步扩大， 系统的脆弱性就会逐步暴露；一个具有很高安全性的电子银行，随着病毒的不断变种，黑客技术的提高，新的安全问题就会出现。（3）信息科技风险一般不直接造成经济损失，其造成的间接损失难以计量且极可能引发声誉风险。（4）影响范围广。单个信息系统的故障就可能影响银行多项业务。 在银行数据大集中的形势和背景下，信息科技风险也趋于集中，成为惟一能使银行瞬间瘫痪的风险。

从国内的监管导向看，笔者认为信息科技风险管理有两个重要的目标：一是保证银行业务的稳定和连续；二是保护客户信息安全。如果不能实现这两个目标，则可能引发直接或间接的经济损失以及声誉风险和法律风险。

二、信息科技风险的影响因素

从前述信息科技风险管理的两个目标出发，可以通过分析影响目标实现的因素来了解引致信息科技风险的原因。影响银行业务的稳定和连续的因素主要有软硬件故障、人员误操作、关键人员离岗、系统超负荷运行、网络瘫痪、电力中断、病毒传播、应用系统及版本出现异常、数据缺失或丢失、外包服务不到位、自然灾害或人为损坏设备、缺少业务连续性计划、灾备基础设施不健全、日常应急演练不充分，等等。影响客户信息安全的因素主要有内部人员利用流程、权限漏洞盗用客户数据；外部人员运用技术手段侵入系统盗用客户信息；内外勾结盗用客户信息、外包服务商泄密等等。

以上这些因素在巴塞尔新资本协议中也有相关的描述。巴塞尔新资本协议对操作风险的损失事件形态分为7个类型，吴博（2010）将其中与信息科技风险的损失事件有关的三个类型整理后大致覆盖了引发信息科技风险的因素，见表2。

当然，上述这些影响信息科技风险管理目标实现的因素仍只是引发信息科技风险的中间变量，其本身也可被视作信息科技风险的表现形式。透过这些表现可以很容易发现管理不到位才是导致信息科技风险的最根本原因。

从实践来看，近年来信息科技快速发展有力支持了商业银行各项业务的快速扩张。但同时，管理、运行维护跟不上的矛盾也日渐突出，“重建设、轻管理、重开发、轻运维”的现象较为普遍。有监管部门研究表明，近年来发生的信息科技风险事件中，多数事件发生都源于制度不健全、流程不完善、落实不到位，很少有纯粹技术原因引发的事件。因此，可以说管理到位是防范信息科技风险的关键。

三、信息科技风险管理措施

信息科技风险管理应贯穿于信息科技工作的全流程，涉及到信息科技风险管理的“三道防线”，需要由信息科技部门和各业务部门共同完成。具体管理措施如下：

1. 完善风险治理架构，各司其职。构建和完善信息科技风险管理的三大防线，即信息科技管理、信息科技风险管理、信息科技风险审计，从三个不同角度、不同纬度，对风险进行立体防控。需要注意的是三大防线的安排不应是简单的对应信息科技风险管理的事前、事中、事后三阶段，风险管理部门、审计部门应积极参与到业务连续性计划制定、应急演练、系统开发、外包管理等信息科技日常风险管理工作中，实现风险管理的前移。

2. 健全管理制度体系，重在执行。建立、健全信息科技管理制度和业务操作流程并认真执行。制度建设要从新产品上线或新系统投产前开始，要建立完善的上线或投产方案以及上线或投产后相关的管理制度和业务流程，并制定回退机制或应急预案以应对意外情况。同时，要积极研究各类信息安全风险案例，总结归纳新的风险点，有针对性地完善制度。要建立制度执行的监督评价机制，商业银行的董事会、监事会、高级管理层以及审计部门要切实监督评价信息科技各项制度的执行情况，对制度执行不到位的责任人要进行问责或处罚。

3. 合理规划系统资源， 未雨绸缪。（1） 纵向规划发展进度。在系统规划设计阶段就要评估能否满足未来较长时间的业务需求，合理安排系统升级、版本切换等工作。（2）横向匹配系统资源。在系统资源短期内不变的情况下，合理分配资源，通过系統分级，将资源优先分配给等级高的系统以保障重要系统的稳健运行。

4. 密切监测系统运行，防患未然。通过技术平台对信息系统的运行状况进行全程监控。一、二级骨干网是否畅通、网点终端和自助设备是否运行正常、应用系统是否正常服务、是否有异常交易、网络是否遭到非法入侵等，都必须纳入实时监控范围，以确保在第一时间发现问题和风险点，及时采取应对措施，防患于未然。

5. 落实业务连续计划，加强演练。要在全行层面建立和完善可操作性强、覆盖各信息科技系统的业务连续性计划和应急预案，包括业务恢复机制、风险化解和转移措施、数据备份以及应对媒体的统一策略等。针对新发生的突发事件以及新发现的薄弱环节，要及时对预案进行总结更新。加强应急预案演练，以保障银行在突发重大事件面前，能从容应对，迅速恢复生产运营，尽可能降低损失。

6. 推进科技队伍建设，提升能力。首先，要明确岗位职责，因岗定人，岗位匹配，并落实岗位制衡。其次，要完善激励约束机制，以激发员工的主观能动性，并使科技队伍保持基本稳定。最后，要加强培训，培养员工风险防范意识和风险防范能力，提高员工的信息科技业务水平。

浅析银行信息系统开发与管理 第5篇

对于现代化商业银行来说，数据是基础，信息是依据，决策是关键，效益是目的。分析银行业务的信息流和信息系统建设，具有重要的社会意义，信息系统的建设和发展策略已经成为现代化银行经营策略的重要组成部分。我国银行应逐步完善数据的应用，使之能适应业务数据大集中的优势，提供经营决策功能，从而为银行业务的发展提供有强有力的支持。

（一）银行信息系统建设中存在的问题

1、系统建设 缺乏整体规划

我国银行信息系统的开发工作缺乏科学系统的指导方法，长期没有统一的发展规划，统一的标准规范以及统一的实施方案，很多商业银行在进行软件开发时，没有做详细量化的可行性研究与分析，不进行仔细的系统调研，不能从技术、经济环境等方面论证并研究软件项目的可行性，并准确确定工程规模，具体目标及对建设系统进行仔细的成本效益分析。目前多数银行采用的项目开发方式为：业务部门根据市场需求提供需求书，与科技部门讨论，科技部门或者开发公司根据需求完成功能设计，然后由业务部门确认反馈意见，继而进入开发阶段，项目开发后期业务人员进行相应测试和上线验收。

在实际运作中发现普遍存在以下问题：一是项目方案缺少充分论证。二是由于开发时没有整体考虑，往往顾此失彼。三是业务部门的随意性给科技部门项目协调带来很大困难。这种现象还表现在各银行在计算机工程人员上配臵上偏重于程序人员，没有考虑系统分析人员的重要性。在务部门管理人员配臵上，偏重于业务，没有考虑技术和项目工程人员的重要性。致使银行信息系统建设队伍缺乏一批既懂业务又懂技术的人员。

2、数据采集规范性低，查询不方便

目前，从业务网点至总行的各个环节，数据、信息的传递仍然以书面报表和报告为主，各部门单一业务系统为辅，信息采集中存在各部门多头采集的问题，没有进行积极有效的沟通，也没有统一的指标体系，使得各系统的数据口径，报送时点等不一致，既导致各个系统的信息无法共享，造成管理资源利用的低效率，也无法保证数据的真实性，或者各部门都不采集，形成管理上数据的的死角。系统在采集数据时和业务联系的精密度低，未考虑业务的发展，以及未来的相关模型建立所需要的基础信息数据。

另外，管理信息系统的查询功能不尽完善、不直观，无法满足监管和管理上灵活多变的查询要求，统计工作存在大量的手工。一个好的信息系统应当避免信息的采集的重叠、遗漏以及滞后的情况，同时需要和业务精密联系，加强信息真实性的检验，完善基础查询和灵活查询功能，为银行统计、风险信息暴露、管理模型提供可靠的及时的信息来源。

3、缺乏科学的分析方法和手段

我国目前正在运行的银行信息系统一般都只具有比较简单的分析处理功能，不支持复杂的数学模型，无法对金融风险进行有效的测评，使得一些潜在的金融风险无法通过系统及时发现，银行管理仍然停留在依赖管理人员自身的业务素质和直觉判断的基础上。

4、信息系统对操作风险的防范不够完善

信息技术的发展推动了商业银行服务质量和服务效率的提高，但接踵而至的是风险的明显增加，除信用风险和市场风险外，操作风险已成为银行最重要的风险之一。操作风险反映在信息系统方面主要是指不完善或有问题的内部程序、系统权限的篡改、操作员使用的混乱、角色权限不及时的调整、离职调岗人员操作编号的不及时停用等等，导致了信息系统对操作风险防范的遗漏。

另外，问题出现在风险信息的及时反映上面，银行的有些损失就是由于有关不正当活动的信息本应该及时反映的，但却没有及时反映在高级管理层的提醒界面，或者信息系统中的风险信息不完整，因而尽管银行已经事实上出现问题，但给人留下的印象仍然是运转正常的假象，从而造成问题日益严重。

5、信息系统的结构不尽合理

我国银行信息系统是以综合业务系统作为核心系统，对后台最为关键的决策系统的开发不够重视。同时由于各子系统的标准化程度低，包括信息报送格式的标准化，数据接口的标准化等，使得整个信息系统框架中信息的收集，存储，传递和加工，利用等各个部分还不能循环互动，造成了银行系统的辅助决策支持功能得不到有效发挥，从某种意义上来说，目前还没有真正建立起一套完整的决策支持系统。

6、银行信息系统不应过于依赖外包

随着我国银行信息系统全面快速发展，不少银行认为外包有益于跟踪最新技术动态，加快新技术的应用，且信息系统的外包可以降低成本。而事实上一个信息系统的成本核算不仅仅是开发成本，这是一部分可见的成本，后期维护成本还占有很大的比例，甚至超过开发成本。如果没有一个真正懂系统的内行服务，往往事倍功半。而且银行通常会遇到一个问题，开发公司往往没有对行内科技人员进行培训，或者培训十分简单，即所谓的‚黑盒‛培训。加之后期开发公司的维护人员不连续，衔接性不够，后续维护人员对前期开发人员或者维护人员的程序不了解，造成维护版本混乱。

另外，银行的安全性也是一个非常值得关注的问题，银行对系统的安全性是非常敏感的。在开发公司主导的系统中，由于没有银行内部科技人员的全程跟踪和控制，难以发现程序中存在的重大漏洞。其次，在后期的维护过程中，为了解决问题，有时银行需要提供足够的信息（如信用评级模版、五级分类模型、企业规模测算模型、风险指标体系、客户信息、贷款信息等），这些信息可能就会在无意中形成对资金安全的隐患。

（二）银行信息系统建设的对策与建议

1、尽快制定银行信息系统的总体规划

银行信息系统亟需解决的问题是制定银行信息系统的总体规划。在银行内部，应该成立专门的银行信息系统建设领导小组机制，组织科技部门、业务部门和开发公司就信息系统的基本业务需求、业务流程、关键技术需求、系统的框架结构，应该遵循的各个标准，业务数据采集体系（包括数据采集的内容、方式、方法和途径），银行内部信息的管理及建设系统所涉及的规章制度、资金等重大问题进行系统科学的规划，成立相应需求组、网络组、技术组、制度组、保障组等，各司其职并密切协调，以保证未来各管理子系统之间的有效集成和有效共享。在制定总体规划时，应充分考虑国际金融发展趋势对银行未来管理所带来的影响，如金融的混业经营，新巴塞尔协议要求，IT技术在金融业应用方面的业务创新以及银行管理的最终有效形式‘实时交易和管理’等，使建设中的管理系统具有一定的前瞻性、开放性和兼容性。

2、借鉴成功跨国银行经验，完善银行信息系统的结构 银行信息系统的体系结构：

第一个层次：业务处理系统。包括综合业务系统、财务系统、信用卡系统、电子银行系统、信贷业务系统等，到目前为止，大部分银行业务处理系统已趋于将全行各种业务处理系统集成到统一的平台上，银行业务处理系统平台已经初步搭建。

第二个层次：管理信息系统。包括客户信息系统、人力资源系统、风险控制管理系统等。从银行目前管理信息系统的建设情况来看，尽管业务处理系统比较完善和先进，但由于内部缺乏统一的‘沟通’机制，信息有效利用率低。

第三个层次：决策支持系统。主要包括综合统计系统、商务智能系统、决策支持系统。该系统可以通过运用全行内外信息资源，建立各类模型库，方法库，并进行基于全行范围的客户、产品、财务、员工情况等的综合分析，实现对全行的各项资源和创新能力的最优化配臵。目前，很多银行还没有形成一个完整的商务智能决策支持平台。各业务处理系统和管理信息系统只反映了决策支持系统中可以结构化的一部分，反映了全行经营情况的某一侧面，真正意义上的决策系统还没有建立起来。这个层面的信息系统建设是银行信息系统的未来发展方向。

3、加强信息系统对操作风险的防范

加强对银行信息系统内部程序的检查，做充分的内部测试，试点上线测试，以及对系统正式上线过程中的程序问题，及时了解和收集，及时进行完善；同时做好压力测试，对一定操作量和业务量的压力下，系统的承受能力有充分的预估，确保系统稳定正常运行。加强对信息系统权限的控制，定期进行排查，如人员岗位的调整必须及时上报、角色权限的申请必须备案，同时需要加强对系统管理员的控制，系统内权限的调整需要进行复核。

采用安全系统平台通过密码定期更新、手纹识别等控制等手段进行系统安全登陆的控制。

对信息系统风险的识别、分析和控制,除了加强事后监督和稽核为主，还应对系统进行长远的规划和建立成熟的预防控制体系，加强对异常操作信息以及异常业务量信息的及时预警，同时要有强有力查询的支持，加强风险的暴露非现场检查提供支持，一旦发现问题，及时的进行现场检查，排查风险点，检验操作上是否存在违规现象。

4、运用数据仓库技术以实现其智能化的决策支持功能 数据仓库技术是近年来发展迅猛的一种新技术。所谓数据仓库，就是把一个银行的历史数据收集到一个中央仓库以便于处理，他是支持决策过程的、集成的、随时间而变的，持久的海量的数据集合。就银行而言，其大量的历史数据和当前数据都存在着重要的决策信息，如何管理这些浩如烟海的的数据以及如何从中提取有用的信息是决策系统必须要解决的问题。数据仓库的最大有点就是他能把全行不同信息岛上的信息集合到一起，存储到一个单一集成关系的的关系型数据库里面。利用这种集成的信息，可方便对信息的访问，更可使决策人员对一段时间内的历史数据进行研究分析，研究事物发展的走势。

5、建立相关模型库、方法库和知识库，逐步形成分析决策支持平台 数据库、模型库、方法库构成了决策支持系统最基本的内容，其中，数据库是银行决策支持系统建立的先决条件。模型库是决策支持系统的核心部分，方法库是各类模型必不可少的工具。同时，成立专门的模型库，需要培养一批专业的分析人员。决策支持系统技术含量高，综合性强等特点，决定了该系统需要大批的丰富的数理统计、计算机技术、管理经验的专业人才的支持。因而培养吸收这样的分析人才就显得非常迫切和重要。由于决策系统中的各模型库具有一定的独立性。因此，银行可以组建专门的技术开发小组来开发模型库和方法库，开发过程可以采用项目管理的办法管理，这对尽快建立银行信贷决策支持系统，提高信息系统决策支持功能具有深远的影响。

6、尝试‘借力外包’模式

银行信息化发展运用外包应该是一种必然，中国银行业面对的竞争是国际化的，银行IT部门有限的人员已经显得有些力不从心。但是银行信息系统外包应从哪些角度切入？在多大规模上实施？如何控制外包成本？如何保证安全性？这些应该是银行慎重思考的问题。银行内部在金融信息专业化的应用方面有自己的优势，和开发公司两方面结合，可以使信息系统应用更加完善。但银行必须在保证系统稳定性、完整性、可维护性和安全性的前提下，提高行内科技和业务人员素质，才能考虑外包。目前的情况下，银行内部可以充分发挥科技人才资源，调动其主动性，在外包公司的辅助配合下开发信息系统。

海信商业信息管理系统操作报告 第6篇

本学期的管理信息系统课程中我们接触了海信商业信息管理系统的操作平台，在使用该操作平台的过程中我们对企业日常运营中的信息管理有了深刻的认识。海信商业信息管理系统4.0共分24个子系统，子系统又分为基本子系统和增强子系统。

我们最先接触的是系统管理，在系统管理页面下我们可以完成用户的注册，这相当于现实中我们在某家公司的身份注册，有了我们自己的用户名称后，我们可以在自己的用户名下进行接下来的管理信息系统操作，同时系统管理相当于位于各系统之上的一个总控系统。

假定我们每个人都有一家企业，我们首先可以在编码管理页面中编辑我们的部门、品类、供应商、商品等编码信息。不管是批发还是零售，都离不开企业各部门之间的协同合作。在编辑部门编码时每个人脑海里都有自己的经营模式，所以部门的种类也是都有自己的特色的。在部门编码完成后，我们要进行的是品类的设置。品类设置的操作与部门设置的操作大致相同。不论是批发还是零售的企业都要有稳定的供应商，在供应商的设置和注册时，要求我们要选择合适的供应商，这与后来的合同管理的设置关系密切。一个完整的供应商信息才能为以后的进货管理等各项管理系统提供有效的操作保障。在编辑商品信息之前，我们都要与供应商签订一份合同，在合同管理界面下完场一份合同的签订。合同管理界面下我们可以签订经销合同、代销合同和联销合同三种合同。在此我们也了解了经销、代销和联销的区别。1.经销是指在国际贸易中经销商按照约定条件为国外供货商销售

商品编码时每个商品都要有自己的供应商以及对应的供销合同。

经过一系列部门、供应商、合同、商品的设置后，接下来我们要进行的就是商品的采购，这里我们系统地接触了海信商业平台的进货系统。

进货管理系统下，我们分别学习了三种进货方式。1.制作采购申请单→自动生成采购单→采购商品验收。2.手工制作采购单→采购商品验收。3.商品验收。

其中商品验收是相对于采购验收的，商品验收不需要指定的商品采购单。而制作采购申请单然后在生成采购单的方式是相对于手工制作采购单的，这两者均为采购商品验收。此外，在商品验收之前要核对单据中的数据与所需采购的商品数量是否相符。所有单据在保存后均要入账完成设置。在采购商品时如果在仓位选项选择为空，则采购的商品直接进入柜台库存。学习进货管理系统的同时，我们也学习了商品的退货和库存初始化。其中商品退货分为两种类型：一种是退货返厂，一种是冲红作蓝。而库存初始化是仅适用于无分码总码和分码的商品。库存初始化分为正常商品库存、负数库存和应付数为负数三种。

商品采购完成后需要进行商品价格的管理，因此我们进一步学习了海信商业平台中的物价管理系统。在物价管理系统下，我们主要研究了进价采价、售价采价、进价调整和售价调整。在企业的现实运营中，企业是要对市场上的各类商品的进价和售价进

同时也满足了不同顾客的需求。此外我们还重点学习了多条形码管理和销售方案的设置。所谓多条形码管理是指一个商品编码对应多个条形码的情况。在实际应用中，主要有两种情况要用到多条形码管理。一种是一个同样的商品同时有多个条形码，另一种是类似的商品有着不同的编码，而商场要作为同一种商品进行管理。学习完多条形码管理后，我们着重学习了销售方案的制定。

首先是定时方案管理，增加定时方案可以帮助商场在促销活动中有可以利用的时间条件，还可以应用于远程查询系统中远程查询用户访问时间条件限制。

其次是促销管理。促销管理中我们可以制定不同的促销方案。其中包含批量促销方案、限量促销方案和普通促销方案。

1.在批量促销方案的设置中，我们可以实现批量促销的数量参数设定。其中可以设置最小数量，最大数量和优惠率。当然也可以选择以优惠价格的计算方式进行批量促销方案的设置。

2.在限量促销方案的设置中，我们可以选择优惠类型为限量优惠并且选定限量优惠促销方案后，对限量优惠方案进行设置。同样在限量促销方案的设置中我们也可以进行数量参数的设定。限量促销的数量参数设定中也可以根据优惠价和优惠率两种方式来进行设置。

在学习销售管理的时候我们也简单地学习了会员管理，进行会员注册和会员引进以及会员卡的发行操作。

到此为止，我们从一开始对用户注册到后来的部门、品类、合同、商品信息的设置，以及到进货管理、销售管理、仓库管理、物价管理、销售管理和库存管理这一系列管理系统的学习，对商场的整个销售运作有了进一步的认识，同时也有了一个系统的学习。不论是什么类型的企业，它的日常运作都是要有一个成熟的管理信息系统在其后台进行操作。当然每个管理信息系统也都有其不完善的地方。如今随着网络的飞速发展，很多商品逐步的进行网络销售。在管理信息系统中也应当加入网络营销中的具体操作系统，使这一商业平台变得更加完善。