哈尔滨理工大学学士学位论文
(2) 银行的部门或机构分为经营机构和非经营机构两大类，经营机构所有业务部门或机构；非经营机构包括管理部门、会计部门、财务部门等；对机构代码的编码规则由银行自身确定，并尽量与银行业务系统尽可能地一致。
(3) 对于机构信息的修改，可以修改上级机构代码、机构名称、机构属性(经营机构/非经营机构)、机构人数、机构级别、独立核算标志，当修改上级机构代码时，其业绩相应划归新的上级机构；对机构信息的删除时，其下的机构或行员的业绩划归其原有上级机构业绩的自然增长。
(4) 对于使用权限的设定，由系统通过权限控制表来进行，本功能的使用权仅属于人事管理人员。
2．行员基本信息管理
(l) 行员信息管理是指对银行的所有职员基本信息的管理，提供对各职员的基本信息的录入、修改、删除、查询功能，本功能是属于基础数据的维护管理。
(2) 银行所有人员分为营销人员和非营销人员，对行员代号的编码规则以银行职员代码基本保持一致。
(3) 对行员基本信息的修改，只能修改行员的所属机构代码、行员属性、姓名(行员名称)，修改行员基本信息时，其相应业绩不变(不进行修改)，当进行行员的所属机构代码的修改时，其业绩跟随其统计到新的机构，但调整前的业绩不变；对行员进行删除时，删除行员的基本信息，并进行其相应业绩的调整，即把删除行员的业绩划归为其原机构的自然增长。
(4) 对于使用权限的设定，由系统通过权限控制表来进行，本功能的使用权仅属于人事管理部门。
3．业绩相关数据管理对业绩账户与行员的关系数据进行建立和修改，如：业绩账户与行员对应关系以及业绩比例等。经营机构的业绩账户=E(所属行员的业绩账户+所属行员业绩账户以外的自然增长的业绩账户)，非经营机构的业绩账户=E(所属行员的业绩账户)。业绩比例是指当某业绩账户是两个或两个以上的同机构或不同机构行员共同拓展而来时，每个行员所占的初始业绩账户比例。无论账户余额增长或减少，各行员的业绩比例维持不变，除非通过授权修改。同一账户的行员业绩比例总和必须等于100%。业绩账户实际数是指行员或机构实际拥有的业绩账户数目。
(1) 业绩指标数据表包括：各种业绩考核指标。 (2) 提供对业绩指标数据表的修改功能。
(3) 其中：当月业绩统计之前的修改无效(会被统计数据覆盖)，统计之后的修改永久有效。
- 24 -
哈尔滨理工大学学士学位论文
4．绩效考核查询
查询相关个人或机构的任务与业绩情况。
(1) 各种业绩考核指标见附录的业绩考核方法。业绩考核指标包括效益指标、质量指标、综合考评指标。
(2) 业绩查询内容除各项考核指标外，增加行员的业绩账户实际数、机构职员数的查询，业绩账户实际数针对个人/机构查询，而机构职员数只针对机构业绩查询。
(3) 各种业绩账户计算方式
行员业绩账户数目=E(某行员拓展的所有企业存款、储蓄存款、同业存款、保证金存款以及各项贷款的账户)，经营机构的业绩账户数目=E(所属行员的业绩账户+所属行员业绩账户以外的自然增长的业绩账户)，非经营机构的业绩账户数目=E(所属行员的业绩账户)，业绩账户实际数是指行员或机构实际拥有的业绩账户数目。
5．绩效考核分析
通过多种表现形式(如：柱状图、饼图、趋势图)分析个人/机构业绩排列名次情况、同期比较情况、计划完成情况等。
3.3 系统性能需求
对于一个系统来说，可扩展性，安全性，可管理性是几个很关键的因素。 1．可扩展性
可扩展性是指系统能保证可持续增长以满足用户需求和业务复杂性要求，前端Web系统为动态变化的模型：它们通常一开始很小，但随着需求的增长而呈指数级增长。这种增长非常迅速，不仅表现在支持的用户的数量上，而且表现在提供的用户服务的复杂性和集成性方面。对于本系统的前端展示而言，这种扩展性就显得尤为重要，因为前端展示功能完善是一个渐进的过程，我们目前开发的这个系统需要随着用户的要求和技术的发展而需要不断改进。所以可扩展性是非常必要的。
2．可靠性
服务质量的一个重要方面是能够在期望的响应时间内访问信息。对需要通过Internet的应用程序或信息的单位用户来说;还意味着必须在用户期望的时间内为用户提供其需要的信息。试想一个同时有几百甚至几千人访问的系统，一旦服务器发生阻塞或者崩溃，会带来怎样的不可想象的麻烦。另外太长的延迟时间也会
- 25 -
哈尔滨理工大学学士学位论文
给用户带来不便。
3．安全性
安全性是指系统能够保护数据或基础结构避免受恶意攻击或者盗用。安全性是通过为信息的机密性，完整性和可靠性提供充分的保护来预防风险，保障系统安全，是任何系统成功的基本要素。
4．可管理性
可管理性是指可以很方便地对系统进行管理，确保系统的正常运行管理和运作涉及以下几个因素:维护系统服务及其服务正常工作所需的基础结构，工具以及管理员和技术人员。系统的主机是放在银行运行机房中，但是对系统的管理员也许并运行机房中，因此，系统的管理和监控必须能够远程完成。
3.4 本章小结
需求分析是设计的起点。需求分析的任务是通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。需求分析的结果是否准确地反映了客户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。本章在进行实际调查研究及对业绩考核认真分析的基础上，对业绩考核统计查询系统系统作出了相关的需求分析和功能分析，为以后的系统设计与实现提供必要的前提条件。
- 26 -
哈尔滨理工大学学士学位论文
第4章 系统总体设计
系统总体设计工作是自顶向下地进行的。首先设计总体结构，然后逐层深入，直至进入每一个模块的设计。总体设计主要是指在系统分析的基础上，对整个系统的划分、机器设备(包括软、硬件)配置，数据的存储规律以及整个系统实现规划等方面的合理安排。
4.1 系统技术构架
根据银行绩效考核的具体需求和结构分布特点，采用MVC架构模式，合.NET技术，设计了整个系统的技术架构。该系统在结构上采用基于因特网的B/S三层应用体系结构，分别为表示层、业务逻辑层和数据访问层，采用此模式的目的是使系统结构更清晰，分工更明确，灵活易用，操作方便，有高度的扩展性和可维护性，如图4-1所示：
IE用户 IE用户 Windows用户 Web Forms Web Forms Windows forms Web服务器 ASP.NET Web Services 应用组件服务器 管理业务层 基本业务层 数据访问层 数据访问层 ADO.NET 数据库 图4-1 基于因特网的B/S三层应用体系结构
- 27 -
哈尔滨理工大学学士学位论文
4.2 系统数据流程
通过上面的功能需求分析，根据部门和员工绩效考核办法，可以分析整个系统的数据流程：
1．由银行综合业务系统下载员工和部门的业绩原始数据，并把原始数据导入银行绩效考核系统的Oracle历史表空间。
2．根据不同地区分行的具体考核方法，从历史表空间抽取原始数据到Oracle当前表空间，形成统计数据表。
3．根据对公存储蓄交易日志的分析，以交易代码为识别标志，和每笔业务中的网点号，把统计数据表中的各种业务相关信息归类到部门业绩统计表中。
4．由部门业绩统计表分类计算出不同的部门业绩统计报表，并进一步作出分析产生部门业绩报表分析图；通过考核前输入的考核指标数据，计算出部门各种绩效，形成部门业绩考核表。根据每日录入员手工录入的业务员代号与业绩账号对接数据，从部门业绩统计表中抽取出员工个人办理的业务，并添加手工输入的一些代理业务及其中间业务，最终形成个人业绩统计表。
5．根据部门目标管理考核办法，对部门业绩考核表进行分析计算，对其产生的绩效考核结果进行二次分配，形成员工目标管理考核表。在个人业绩统计报表中，通过科目管理和价格管理数据，对个人业绩进行计价考核，形成员工业绩考核表。
4.3 系统总体结构
银行绩效考核系统分为五个模块：前台参数配置模块、前台业绩录入模块、前台数据浏览模块、绩效考核报表管理模块和后台数据模块。
前台参数配置模块分为：部门信息管理、员工信息管理、业绩账户管理、考核项目管理、会计科目管理、考核指标管理；前台业绩录入模块分为：个人分管账户管理、个人分管综合账户管理、银行卡业绩管理、代理业务营销管理、营销业绩手工录入管理、个人营销业绩二次分配管理。
前台数据浏览模块分为：业绩排行榜、员工绩效考核、部门绩效考核、营销业绩汇总、基础数据查询；绩效考核报表管理模块分为：绩效考核报表生成、绩效考核报表查询、绩效考核报表分析；后台数据管理模块分为：大机数据下载、大机数据导入、业绩考核计算、后台数据备份。系统总体功能结构，如图4-3所示：
- 28 -