# 马尔代夫银行 - 核心银行系统项目实施建议书 (V1.0)
**服务商：Vive&Best (VNB)**  
**日期：2026年6月**

---

## 目录
1. [前言](#1-前言)
   - 1.1 项目背景
   - 1.2 项目目标
   - 1.3 术语与定义
2. [技术方案](#2-技术方案)
   - 2.1 项目范围
   - 2.2 功能架构
   - 2.3 系统功能列表
   - 2.4 技术架构
   - 2.5 技术栈
   - 2.6 部署架构
   - 2.7 生产环境配置
3. [项目实施](#3-项目实施)
   - 3.1 实施方法论
   - 3.2 项目管理
   - 3.3 建议的项目组织架构
   - 3.4 整体项目计划
   - 3.5 实施流程
4. [知识转移](#4-知识转移)
   - 4.1 知识转移目标
   - 4.2 知识转移策略
   - 4.3 知识转移方法
   - 4.4 培训目标
   - 4.5 通用培训要求
5. [售后服务](#5-售后服务)
   - 5.1 保修期
   - 5.2 保修服务范围
   - 5.3 维护人员
   - 5.4 服务等级协议 (SLA)

---

## 1 前言

### 1.1 项目背景
买方正在马尔代夫申请银行牌照，需要一套核心银行系统来满足业务运营需求并符合当地监管要求。

### 1.2 项目目标
本项目的目标是基于 VNB 的核心银行系统产品 (V-CBS)，实现以下项目目标：
* **满足初始业务运营需求：**
  * 普通交易银行业务
  * 支付，需要与 SWIFT 以及马尔代夫当地清算网络 NPS 进行集成
  * 客户账户与管理
  * 储蓄与活期账户及相关的活动与交易
  * 资金交易 - 外汇、货币市场及其他期货衍生品交易
  * 贷款业务：
    * 针对中小企业（旅游业中小企业等）的营运资金/循环授信
    * 库存/应收账款融资
    * 设备与车辆融资（资产担保）
    * 进口融资 / 贸易担保
* **提供简单高效的 API 或其他集成方法，用于与其他系统无缝连接，包括：**
  * 线上与线下收单系统
  * 外汇与货币市场交易系统
  * KYC (了解你的客户), KYB (了解你的企业)
  * AML (反洗钱)

### 1.3 术语与定义
* **VNB：** Vive&Best，本项目供应商
* **Bank：** 马尔代夫银行 (Maldives Bank)，本项目业主/买方
* **V-CBS：** VNB 核心银行系统产品名称

---

## 2 技术方案

### 2.1 项目范围
本项目范围由以下部分组成：
* **原型产品：**
  * 提供核心银行产品原型 (V-CBS)。详细的功能范围说明请参见 2.3 “系统功能列表”章节。系统用户数不受限制。
* **系统实施服务：**
  * **需求分析服务：** 基于 V-CBS 标准产品，分析和整理银行的业务需求，并制定差距分析解决方案。
  * **产品安装与部署：** 在符合银行信息安全要求及其他标准和规范的前提下，进行系统原型安装和部署，包括开发、测试和生产环境。开发和测试环境由 VNB 准备；生产环境基础设施由银行提供（如服务器等）。
  * **系统集成服务：** 提供与 V-CBS 关联的系统集成服务。
  * **测试服务：** 提供系统集成后 V-CBS 本身的测试服务。如果测试需要由第三方系统发起，则银行负责协调第三方发起测试。
* **产品培训：**
  * 在 UAT（用户验收测试）之前，VNB 向银行提供产品使用培训服务，使银行的业务人员能够更有效、更快速地掌握产品。培训期通常不超过一周。
* **其他支持服务：**
  * 包括 UAT 支持、投产前演练支持及其他支持活动。
* **保修维护服务：**
  * 自正式上线之日起计算，VNB 向银行提供有限的保修维护服务。保修期内的服务包括产品缺陷 (Bug) 解决、定期系统巡检及其他产品维护活动。具体保修期以双方最终合同约定为准。
* **远程技术支持服务：**
  * 用于日常运营中的产品使用咨询。银行可通过 24 小时服务热线或电子邮件将问题提交给 VNB。VNB 在收到问题后，须按照相关规定提供支持服务。
* **增值服务（附加服务）：**
  * 分享相关同行案例的实践经验，并介绍公司的其他产品线及相关解决方案。

### 2.2 功能架构
* V-CBS 的核心银行组件包括以下业务功能模块：CIF（客户信息）、存款、贷款、支付、信用与抵押品、总账，以及业务平台（包括利率管理、汇率管理和费率管理）。
* V-CBS 提供 API 集成平台，用于将核心模块与渠道系统及第三方系统进行连接。
* V-CBS 提供银行用户柜员前端，通过 API 集成平台访问核心银行功能模块以操作系统功能。
* API 集成平台预留了接口，以便未来与面向客户的渠道系统（包括手机银行和网上银行）进行快速集成。
* API 集成平台提供了与第三方系统快速集成的接口。

### 2.3 系统功能列表

#### 2.3.1 CIF (客户信息管理)
* **子模块：维护**
  * 交易：个人客户基本信息维护
  * 交易：企业客户基本信息维护
  * 交易：客户状态维护
  * 交易：客户经理维护
  * 交易：客户关系维护
  * 交易：客户签名维护
  * 交易：客户地址维护
* **子模块：查询**
  * 交易：客户综合视图
  * 交易：客户基本信息查询
  * 交易：客户状态查询
  * 交易：客户经理查询
  * 交易：客户关系查询
  * 交易：客户签名查询
  * 交易：客户地址查询

#### 2.3.2 Deposit (存款管理)
* **联机交易参数维护：** 存款产品参数维护
* **开户 (a/c opening)：**
  * 储蓄/活期账户开户
  * 定期存款账户开户
  * 通知存款账户开户
  * 自定义账号生成
* **账户维护 (a/c maintenance)：**
  * 储蓄/活期账户信息维护
  * 定期存款账户信息维护
  * 资金冻结 (Hold fund)
  * 资金解冻 (Hold fund release)
  * 睡眠账户设置
  * 睡眠账户激活 (Dormant account release)
* **账户查询 (a/c inquiry)：**
  * 账户信息查询
  * 账户余额查询
  * 账户交易明细查询
* **金融交易 (financial txn)：**
  * 储蓄/活期存入
  * 储蓄/活期支取
  * 储蓄/活期转账
  * 定期存款存入
  * 定期存款支取
  * 定期存款部分支取
  * 通知存款支取
* **销户 (a/c closure)：**
  * 储蓄/活期销户
  * 定期存款销户
  * 通知存款销户
* **批量交易 (Batch Txn)：**
  * 利息：应计利息 (Interest accrual)
  * 利息：利息计算 (Interest calculation)
  * 利息：结息/利息结算 (Interest settlement)
  * 定期存款：定期存款到期处理

#### 2.3.3 Credit & Collateral (授信与抵押品)
* **抵押品维护交易：** 抵押品信息维护、抵押品估值维护
* **查询交易：** 抵押品信息查询、抵押品估值查询
* **额度维护交易：** 额度设立、额度修改、额度冻结与部分冻结、额度删除
* **查询交易：** 额度查询

#### 2.3.4 Loans (贷款管理)
* **联机交易参数维护：** 贷款产品参数维护
* **账户管理：** 贷款开户、贷款账户信息维护、贷款账户关闭
* **放款 (Disbursement)：** 贷款放款、贷款放款冲正 (Reversal)
* **还款 (Repayment)：** 贷款到期还款、贷款提前还款、贷款逾期还款、贷款还款冲正
* **贷款维护：** 贷款利率变更、贷款到期日变更、贷款宽限期变更、手动利息调整、暂停计息与恢复计息、利息模拟
* **核销 (Write-Off)：** 贷款核销
* **查询：** 贷款信息查询、还款计划查询、还款历史查询
* **其他：** 保函开立、保函开立冲正
* **批量交易 (Batch TXN)：** 放款还款计划生成
* **利息处理：** 计提利息、利息计算、结息

#### 2.3.5 Remittance (汇款/清算结算)
* **支付网关 (Payment Gateway) 报文通道：**
  * 报文通道发送/接收处理，与 SWIFT 及其他通道对接
  * 报文收发控制：通道状态监控、截止时间维护、网关开关管理
  * 报文收发控制：报文属性维护、简/繁体电码维护与转换、SWIFT Code 维护
  * 入金报文 (Inbound Message)：入金报文解密、解析、格式转换，调用 AML 系统进行反洗钱筛查
  * 入金报文：付款报文清算账户分析、头寸匹配
  * 入金报文：报文路由规则维护、自动/手动报文路由
  * 入金报文：报文确认、报文退回、报文与业务匹配
  * 出金报文 (Outbound Message)：报文合规检查、出金报文加密、出金报文打包
  * 出金报文：报文发送、报文重发、报文状态变更
  * 通用处理：报文存储、综合查询、报文转换
  * 通用处理：参数管理
* **汇入款账务处理 (Inward Remittance Accounting Processing)：**
  * 汇入/转账报文自动识别账务处理
  * 账户名称核验处理
  * 汇入款自动/手动记账 (Posting)
  * 手续费处理：汇入款手续费处理
  * 退汇与止付 (Return Remittance & Payment Stop)：汇入款退汇 (pacs004 / pacs002)、汇入款止付处理
  * GPI 处理：汇入款 GPI 处理
  * 客户收汇通知 (Customer Remittance Advice)
  * 参数管理：汇入款状态维护、客户特殊状态维护
  * 汇入费用报文：入金费用报文处理
* **汇出款 (Outward Remittance)：**
  * 汇出款处理：创建汇出款记录、报文校验处理、发送报文、调用 AML 系统进行反洗钱检查
  * 退汇与止付：汇出款止付、汇出款退汇
  * 手续费处理：汇出款手续费处理
  * GPI 处理：GPI 处理
  * 客户收汇通知
  * 参数管理：汇出款状态维护
* **查询与回复报文匹配 (Inquiry & Reply Message Matching)：**
  * 入金报文匹配、发送止付报文、发送查询报文、发送自由格式报文
* **参数管理 (Parameter Management)：**
  * 路由参数管理、SWIFT Code 管理、SWIFT Code 文件处理
* **手续费管理 (Fee Management)：**
  * 免收佣金客户名单管理、费用信息和费率维护
* **对账管理 (Reconciliation Management)：**
  * 对账处理：拆分对账报文、自动对账、建议对账、自对账、手工对账
  * 参数管理：对账条件设置
* **其他、通用与其他 (Common & Others)：**
  * 其他银行数据管理、通知单查询与下载

#### 2.3.6 General Ledger (总账)
* **内部账户 (Internal Account)：** 内部账户开户、内部账户存入、内部账户支取、内部账户余额查询、内部账户交易明细查询
* **总账科目 (G/L items)：** 会计凭证生成、总账科目设置、总账科目查询、总账科目余额查询、总账科目明细查询
* **对账 (Reconciliation)：** 总账与分账对账

#### 2.3.7 Business Platform (业务平台)
* **利率：** 利率设置、利率查询
* **汇率：** 汇率设置、汇率查询
* **费用管理：** 费用设置、费用查询
* **其他：** 节假日日历设置、节假日日历查询、流水号设置、流水号查询
* **参数：** 业务参数代码设置、业务参数代码查询

#### 2.3.8 Operation Reports (运营报表)
* **CIF：** 日常 CIF 维护审计轨迹报表
* **业务平台：** 利率更新报表、费用更新报表、汇率更新报表
* **存款：** 存款每日账户维护审计轨迹报表、每日开户报表、每日未结透支 (OD) 报表
* **汇款：** 汇入清算异常报表
* **贷款：** 贷款逾期报表
* *注：可根据业务需要提供额外的运营报表。*

#### 2.3.9 API for 3rd-party systems (第三方系统接口)
* **CIF 查询：** 客户信息查询
* **存款查询：** 存款余额查询、存款明细查询、账户状态查询
* **存款交易：** 储蓄/活期存款、储蓄/活期支取
* **贷款查询：** 贷款信息查询
* **贷款交易：** 贷款还款
* **总账交易：** 内部账户存入、内部账户支取、内部账户余额查询、内部账户明细查询
* **汇款交易：** 反洗钱 (AML) 调用
* *注：可根据第三方系统需求提供额外的 API。*


### 2.4 技术架构
本系统采用基于 Spring Boot/Cloud 的分层技术架构，分为五个大层，实现了高内聚、低耦合的设计目标：
* **网关层 (Gateway Layer)：** 采用标准的 Spring Cloud Gateway 服务，支持 HTTP/S 协议访问，以及 Websocket 和 gRPC 等多种协议接口，适应前端页面（Front Page）和第三方系统（Channel 1/2/3）的不同访问需求，实现统一的流量入口、身份验证和流量控制管理。
* **集成层 (Integration Layer)：** 通过 Controller、Function 和 OpenFeign 的标准化流程，对业务请求进行上下文处理、函数路由、流程编排、执行调度和事务管理，实现业务逻辑的分层解耦和灵活扩展。
* **微服务层 (Microservices Layer)：** 由存款服务、客户服务、贷款服务、汇款服务、总账服务和基础服务组成。每个微服务应用提供其独立的业务微服务，由集成层处理流程编排和事务控制。基础服务包括后台管理和报表生成。在应用服务之下，提供用户管理、菜单管理、权限管理和系统参数配置功能；基础服务还提供通用的技术能力，包括数据校验、缓存处理、异常处理、数据脱敏、加密和分页，为上层业务服务提供稳定的支持。
* **中间件层 (Middleware Layer)：** 采用 RocketMQ 作为消息中间件，Redis 作为缓存组件或分布式锁，Nacos 作为整个微服务集群的服务注册中心，S3 作为文件存储，MySQL 作为数据存储，支持前端交互、数据持久化等功能，确保开发效率和运行稳定性。
* **基础设施层 (Infrastructure Layer)：** 如果使用云服务部署系统，可以直接利用云服务基础设施（包括服务器、网络、存储、安全控制等）；如果是自建数据中心，可以在本地服务器上部署 K8S 服务来管理整个微服务集群。

整体架构采用 Spring Boot/Cloud 作为统一的技术基石，实现各层的高效协作，保证系统的稳定性和扩展性，同时为后续的业务迭代和功能扩展提供灵活的技术支持。

### 2.5 技术栈
系统采用前后端分离、基于微服务的分布式架构，基于 Spring Cloud 生态系统构建轻量级、高可用、可扩展的企业级业务中台。前端处理页面渲染和交互，后端通过微服务拆分实现业务解耦，依赖成熟的服务注册中心、消息队列、缓存、对象存储等中间件，保障高并发、高可用和高稳定性。

| 技术类别 | 技术组件 / 框架 | 核心用途说明 |
| :--- | :--- | :--- |
| **前端技术栈** | VUE | 渐进式前端核心框架，实现组件化开发、路由管理和全局状态管理，支持后台业务页面渲染和交互逻辑。 |
| | Vue CLI / Vite | 前端工程化构建工具，处理项目初始化、代码编译、打包与部署、热模块替换，提高前端开发和迭代效率。 |
| | Axios | 统一的前后端通信 HTTP 客户端，实现请求拦截、响应标准化处理及异常捕获，规范 API 交互约定。 |
| | ElementUI | 基于 Vue 的 PC 端 UI 组件库，提供表单、表格、对话框和菜单等常用组件，能快速构建具有统一交互和视觉风格的后台界面。 |
| | ECharts | 开源可视化图表库，支持折线图、柱状图、饼图等，用于业务数据、交易报表和统计仪表盘的可视化展示。 |
| **微服务技术栈** | Spring Boot, Spring Cloud | 后端核心基础框架，提供快速开发、自动配置和微服务标准化能力，构建整个分布式微服务架构。 |
| | Spring Cloud Gateway | 系统统一 API 网关，作为所有外部请求的入口，实现路由转发、统一身份验证、限流、CORS 处理和请求过滤，进行流量集中管理。 |
| | Nacos | 集成服务注册/发现和动态配置中心，无需重启服务即可实现微服务自动发现和配置热更新。 |
| | OpenFeign + Spring Cloud LoadBalancer | 声明式微服务远程调用与内置负载均衡，简化跨服务调用开发，确保服务调用的稳定与均衡。 |
| | Quartz | 分布式定时任务框架，支持周期性任务、日终批量处理及其他自动化作业场景。 |
| | Mybatis | 数据持久化组件，负责将数据持久化到数据库中。支持一级和二级缓存。 |
| **中间件** | MySQL | 核心业务关系型数据库，用于交易、用户及账务数据的持久化存储，支持事务机制以保证业务数据一致性。 |
| | Redis | 高性能内存缓存中间件，用于热点数据缓存、分布式锁、API 幂等性、会话存储和限流计数器，减轻数据库压力并提高系统响应速度。 |
| | RocketMQ | 分布式消息中间件，实现异步业务解耦、流量削峰和事件驱动处理，支持消息推送、异步对账及后续处理，保证最终一致性。 |
| | S3 | 对象存储。存储文档、报表及其他数据文件。同时支持与其他对象存储服务（如 OSS）集成。 |

### 2.6 部署架构
核心银行系统采用**双活数据中心 (Dual-Datacenter Active-Active) 部署模式**，数据中心 A 和数据中心 B 同时提供完整的服务能力，在发生故障时，任何一个数据中心都可以无缝接管所有流量。
* 访问层通过智能 DNS (GSLB) 结合 WAF 进行 DDoS 防护，实现就近路由和负载均衡。流量调度中心按照 50:50 的比例将请求均匀分配到两个数据中心。每个数据中心内部采用 F5/LVS 和 Nginx 的双层架构，通过 Keepalived 确保 VIP 的高可用性。
* 应用层分为三层。顶层是 Spring Cloud Gateway，负责统一路由、身份验证、限流和服务熔断，每个数据中心部署 2 个实例以保障高可用。中层是集成服务，负责编排和链接下游子微服务，聚合存款、贷款、总账、客户管理等业务流程。底层由微服务组成，包括存款服务、贷款服务、总账服务、客户服务、业务平台等，全部以 Kubernetes 容器化模式部署，每个服务维持 2 个副本，并支持弹性伸缩以应对业务高峰。
* 数据层采用多组件双活方案。MySQL 在每个数据中心部署主从架构，通过 Canal 实时解析 Binlog 实现双向数据同步，主键 ID 采用奇偶步长策略以避免写入冲突。Redis Cluster 跨数据中心部署，通过 RedisShake 进行实时数据同步。RocketMQ 采用跨数据中心 Broker 主备镜像机制，确保消息不丢失、不重复。对象存储通过 MinIO Site Replication 维持双数据中心间的最终一致性。两个数据中心通过专用光纤链路互联，网络延迟控制在 2ms 以内，为数据同步提供可靠传输。这确保了系统 7×24 小时无中断运行，满足银行基础设施高可用和灾备合规要求。

### 2.7 生产环境配置
生产环境部署划分为四个区域：核心系统接入区、核心系统区、管理服务区和中间件区。
具体单数据中心资源配置如下：

| 区域 | 容器描述 | 容器集合 | CPU | 内存 | 存储 | 节点数 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **核心系统接入区** | 核心系统网关 | banking-gateway | 2C | 4G | 100G | 2 |
| **核心系统区** | 核心应用服务 | banking-ig | 2C | 4G | 100G | 2 |
| | 账户微服务 | banking-ec, cd, fe, rc, ln, lm, ai, ac, co, rm, ci | 4C | 8G | 100G | 2 |
| | 调度服务 | banking-sh | 1C | 2G | 50G | 2 |
| **管理服务区** | 核心后台管理服务 | banking-admin-core, cp, bat, web | 2C | 4G | 50G | 2 |
| **中间件区** | 路由与解析 | Nginx | 1C | 2G | 50G | 2 |
| | 服务注册中心 | Nacos | 1C | 2G | 50G | 3 |
| | 缓存服务 | Redis | 1C | 2G | 50G | 3 |
| | 数据库 | RDS-MySQL | 8C | 16G | 500G | 2 |
| **总计 (单DC)** | **资源 × 节点数** | | **44C** | **92G** | **2200G** | **20** |

*注：以上为单数据中心部署资源配置。对于双活部署，资源需求需乘以 2。*

备用数据中心（主备模式下）资源配置如下：
| 区域 | 容器描述 | 容器集合 | CPU | 内存 | 存储 | 节点数 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **核心系统接入区** | 核心系统网关 | banking-gateway | 1C | 2G | 50G | 2 |
| **核心系统区** | 核心应用服务 | banking-ig | 1C | 2G | 50G | 2 |
| | 账户微服务 | banking-ec, cd, fe, rc, ln, lm, ai, ac, co, rm | 2C | 4G | 50G | 2 |
| | 调度服务 | banking-sh | 1C | 1G | 30G | 2 |
| **管理服务区** | 核心后台管理服务 | banking-admin-core, cp, bat, web | 1C | 2G | 30G | 2 |
| **中间件区** | 路由与解析 | Nginx | 0.5C | 1G | 30G | 2 |
| | 服务注册中心 | Nacos | 0.5C | 1G | 30G | 3 |
| | 缓存服务 | Redis | 0.5C | 1G | 30G | 3 |
| | 数据库 | RDS-MySQL | 4C | 8G | 300G | 2 |
| **总计 (备用DC)** | **资源 × 节点数** | | **24C** | **46G** | **1260G** | **20** |


## 3 项目实施

### 3.1 实施方法论
建议总体上采用**“产品原型 + 差异化实施”**的方法。主要步骤如下：
1. 银行征求各方意见，确定业务功能的总体范围；
2. VNB 根据业务范围安装和配置其产品，并为每个应用系统建立产品环境；
3. VNB 向用户提供培训和演练，使其了解如何在产品系统上执行各种业务操作；
4. 在产品培训和演练过程中，用户根据银行的实际情况提出需要修改的产品功能；如果用户已经准备了需求文档，还应整理需求与产品之间的差距分析，作为需要修改的功能；
5. 根据紧急程度对所有需要修改的产品功能进行优先级排序；
6. VNB 和用户共同参与讨论，最终由银行确认要发布的定制化产品功能；
7. VNB 进行产品定制开发和各种测试（包括与外围系统的接口集成测试、技术性能测试等）；
8. 银行用户对系统功能进行验收测试，银行对系统集成测试和技术性能测试进行总体验收；
9. 银行制定产品系统的相应用户操作规程和 IT 运营规程，并开展上线演练，VNB 提供支持；
10. 系统上线与运营。

### 3.2 项目管理

#### 3.2.1 进度计划管理 (Schedule Management)
为了在预定时间内实现项目目标，必须制定切实可行的计划。合理的计划应指导每项具体任务按时完成，同时向项目管理人员提供项目时间表和进度的清晰视图。
* **里程碑分解：** 制定项目计划时，首先应列出不同项目阶段的主要任务（或里程碑任务），然后在每个里程碑下进行任务分解。
* **滚动细化 (Roadmap)：** 任务分解往往不能在单一时间点完全完成。因此，项目团队的初始成果应该是高层级的任务清单（也称为路线图 Roadmap），然后在项目实施阶段进行细化，形成详细的项目计划。
* **计划变更控制：** 项目计划不得随意变更。路线图 (Roadmap) 的修改需要获得项目指导委员会的批准。详细项目计划中的里程碑任务必须与路线图任务保持一致，项目经理须确保详细计划不被随意修改。通常的做法是允许在任务细化过程中进行修改，而在计划执行过程中，则采用特定的审批程序来防止随意变更。
* **任务分配：** 详细项目计划中的任务必须分配给每个项目成员。最底层的实施任务（如文档编写、编程、单元测试、内部系统集成测试）必须细化到一周以内。特殊情况需经项目经理确认。通过项目管理团队评审后，将其纳入配置库。

#### 3.2.2 实施进度管理 (Progress Management)
为了确保项目按计划实施，实施进度管理是关键组件，也是一个长期的持续管理过程。
* **进度跟踪：** 计划制定完成后，必须将项目实施计划传达给所有成员。项目团队成员每周更新实际任务完成进度。项目管理人员根据交付物核实任务完成情况，并确认任务进度。如果出现延误，必须了解并说明实际原因，提出切实可行的纠正措施。这些信息应反映在每周的项目状态报告中。
* **计划调整：** 此活动与进度管理相结合。在实施过程中，如果项目任务需要调整，除某些情况（如项目经理授权或任务细化阶段）外，均需获得批准。审批包括无需修改路线图的项目经理批准，以及涉及路线图修改时的指导委员会批准。
* 以上进度和计划调整的收集、更新和分析定期进行（通常为每周）。

#### 3.2.3 质量管理 (Quality Management)
按照 ISO 9000 标准，通过质量计划（评审计划、QA 计划）、质量控制（评审、QA 执行）和质量保证（分阶段测试、性能优化）来满足客户期望。具体包括：
* **项目评审 (Project Reviews)：** 在实施过程中，在每个项目阶段安排并执行评审计划，以便尽早发现问题，并指导项目团队成员设计和开发符合功能要求、结构清晰、规范的标准应用软件。例如：需求分析阶段的差距分析报告评审，功能设计阶段的功能规格书评审，详细设计阶段的数据结构和公共接口评审。
* **项目 QA：** 进入各阶段前，要求建立相关标准和规范（经客户核实和确认，建立时间表反映在实施计划中）。在每个阶段根据标准或规范进行项目 QA 检查，对不符合项进行跟踪和监控，直至所有不符合项关闭。
* **分阶段测试 (Phased Testing)：** 在提交用户验收测试前进行详细测试。具体包括：
  * **单元测试 (Unit Testing)：** 开发人员根据详细设计文档系统地对单个功能点进行功能调试测试，并出具可提交给客户的单元测试报告；
  * **集成测试 (Integration Testing)：** 业务团队成员根据功能设计文档对整个系统系统地进行多轮集成和系统测试，并出具可提交给客户的集成测试报告；
* 以上活动均会产生跟进事项，应记录发起人、负责跟进的人员和跟进结果。

#### 3.2.4 风险管理 (Risk Management)
从项目启动到完成，从人员、进度、质量和问题等方面对风险进行识别和分析，并及时实施减缓措施。
* **人员风险：** 人员分配是否合理、团队是否稳定、员工积极性是否得到有效发挥，这些都是人员风险因素，需要相应的减缓措施。
* **进度风险：** 从进度管理的角度看，尽管有完善的机制，但仍需进行严格的进度审计和跟踪，并在计划中建立必要的缓冲区，以应对影响项目整体的局部延误。
* **质量风险：** 除已建立的 QA 和评审机制外，还需要严谨的测试态度和方法，以及经验丰富的业务和技术专家提供监督，确保全方位质量。
* **问题风险：** 出现的项目问题严格按照问题管理机制进行跟进。
* **风险管理流程：**
  1. **风险识别 (Risk Identification)：** 包括确定风险源、产生风险的条件、描述风险特征以及识别哪些风险事件可能影响本项目。风险识别不是一次性活动，应在整个项目生命周期中定期进行。
  2. **风险分析 (Risk Analysis / Quantification)：** 涉及评估风险及其相互作用，衡量风险发生的概率以及对项目目标的影响程度。风险量化的基本内容是确定哪些事件需要采取应对措施。
  3. **风险应对 (Risk Response)：** 根据风险量化结果，制定风险应对策略和技术措施，以减少项目风险的负面影响。风险应对计划基于风险管理计划、风险优先级和风险认知，产生风险应对计划、残留风险、次生风险及其他过程的输入。
  4. **风险监控 (Risk Monitoring)：** 在整个项目管理过程中对风险做出响应。该过程的输出包括针对风险应对的纠正措施和风险管理计划的更新。

#### 3.2.5 需求变更管理 (Requirement Change Management)
开发过程中产生的需求变更，一方面将遵循需求、设计、编码、测试和发布阶段，另一方面会引起基线变更。因此，一旦确立了需求基线，就将建立严格的需求变更流程（包括申请、审批、确认、实施和管理监控的完整流程（采用工具进行每周监控）），并配合严格的版本控制（包括文档和产品本身）。

#### 3.2.6 项目问题管理 (Project Issue Management)
建立项目问题管理机制，对问题进行分类和优先级排序，指定专人跟进，要求所有项目问题必须关闭，并定期报告问题状态。问题管理流程通常包括：问题升级、问题跟踪、问题解决、问题转移和问题关闭。

#### 3.2.7 沟通管理 (Communication Management)
为确保妥善收集和传输项目信息而实施的一系列措施：
* **沟通计划：** 建立定期会议机制（定期会议的主要目的：检查项目范围、进度、质量和成本指标是否达到预定目标，作为主要的沟通渠道之一，是项目监控和风险防范的重要活动）。定期举行项目例会，包括项目状态会议和 PMO 会议。必须指定会议记录员，会议纪要须在会后分发给所有参会人员，并对会议决议和行动项进行跟进。
* **信息传输：** 通过定期会议、专题讨论和小组活动传输信息，采用电话、电子邮件和网络等媒介。
* **项目报告：** 项目经理每周向 PMO 提交项目周报，PMO 每月向指导委员会提交项目月报。
* **沟通模式：** 项目沟通可归纳为垂直（管理层自上而下的沟通）和水平（同行之间的沟通）两种模式。


### 3.3 建议的项目组织架构
项目的成功运作取决于参与项目实施的所有各方的有效协作。各方必须了解各自的任务、目标、职责和权限，从而形成一个关系明确、目标和任务共担的组织架构，确保行动一致、资源有效配置并提高工作效率。
建议的组织架构职责如下：
* **项目指导委员会 (Project Steering Committee)：** 由银行高级管理层和 VNB 高级管理层组成。
  * 对项目进度做出决策
  * 监督项目整体实施
  * 协调和分配各种资源
  * 负责协调和解决双方合作中的重大问题
  * 确定项目组织人员及职责
* **PMO (项目管理办公室)：** 由银行和 VNB 项目管理人员组成。
  * **项目经理 (Project Manager)：**
    * 制定项目管理章程，并根据项目目标和资源制定有效的项目计划
    * 确定项目组织架构和工作流程
    * 建立项目管理政策和规章制度
    * 识别项目执行中的重大风险并制定全面有效的应对策略
    * 组织和协调项目资源
    * 与所有相关利益相关者进行协调
    * 负责确认项目交付物模板
    * 分配项目任务
    * 主持或参与 PMO 例会
    * 负责监控和管理项目整体进度
    * 负责向指导委员会报告项目状态
  * **项目助理 (Project Assistant)：**
    * 负责协助项目经理进行项目管理
    * 负责收集项目进度和问题跟进状态
    * 负责根据公司 QA 要求协助项目经理进行质量管理，包括 QA 标准发布、QA 活动调度、QA 问题跟进和评审活动组织
* **业务支持团队 (Business Support Team)：** 由 VNB 业务专家领导，银行业务专家协助。
  * 负责业务需求分析、差距分析和集成测试用例准备
  * 负责 UAT 期间的业务支持
* **系统架构团队 (System Architecture Team)：** 由 VNB 技术专家领导，银行技术专家协助。
  * 负责系统架构设计和搭建
  * 管理开发、测试和生产环境的系统平台和网络
  * 为系统平台和数据库提供技术支持
* **开发与测试团队 (Development & Testing Team)：** 由 VNB 开发人员和测试人员领导，银行协助。
  * 负责差距设计、开发和单元测试
  * 负责系统集成测试 (SIT)
  * 支持系统上线割接 (Go-Live cutover)
  * 跟进业务测试中提出的系统问题

### 3.4 整体项目计划

#### 3.4.1 项目计划 (Project Plan)
由于 NPS（国家支付系统）集成时间表存在不确定性，项目分为两个上线阶段：
* **第一阶段 (Phase 1)：** 交付除 NPS 以外的所有功能，在 **4 个月**内完成；
* **第二阶段 (Phase 2)：** 交付 NPS 集成功能，在 **6 个月**内完成。

两个阶段同时启动，采用不同的实施计划和功能，但任务内容相似，说明如下：
* **启动 (Kick-off)：** 所有项目团队成员（包括银行 IT、银行用户和 VNB）共同举行启动会，确保各方详细了解项目目标、项目计划和各自职责。
* **需求分析（第一阶段）：** VNB 业务专家向银行用户介绍 V-CBS 系统功能和操作，银行用户提出差异化需求。VNB 根据差距需求评估工作量和实施时间表，双方共同确认实施优先级。VNB 负责准备本阶段的功能规格说明书，经双方共同确认。
* **需求分析（第二阶段）：** 银行协调 NPS 和 VNB 团队进行需求分析，并提供接口文档。VNB 负责准备 NPS 功能规格说明书，经双方共同确认。
* **系统设计：** VNB 实施团队根据确认的差异化需求，对系统修改进行详细设计，并提交银行 IT 确认。
* **编码：** VNB 实施团队进行定制化需求开发、单元测试和内部系统综合测试。
* **SIT (核心内部测试)：** VNB 负责进行 V-CBS 的内部集成测试。
* **SIT (包括第三方测试)：** 银行组织 V-CBS 与其他关联系统（如核心银行系统、汇款系统等）之间的集成测试。VNB 团队提供支持。
* **SIT (包含 NPS 测试)：** 银行协调 NPS 和 V-CBS 进行集成测试。VNB 团队提供支持。
* **UAT：** 银行用户负责 V-CBS 的验收测试，VNB 团队提供支持。
* **上线 (Go-Live)：** 系统上线。

#### 3.4.2 项目关键点 (Project Key Points)
项目有以下关键点：
* **业务范围界定：** 业务范围将影响产品选择、基础设施选择及所有后续计划。范围一旦确定，应尽量避免更改；如果变更不可避免，必须经过所有项目参与者的共同评估，充分考虑对各方的影响。
* **差距需求确认：** 由于项目时间紧迫，对于用户提出的差距需求，必须彻底评估其紧急程度，进行合理的优先级排序，定制化工作必须严格控制在可接受的范围内。
* **外围系统协调：** 由于外围系统受外部因素影响较大，需要尽早联系和安排。接口定义和集成测试计划应提前与对方确认，并预留较为宽松的时间缓冲区，以防意外情况影响整体项目计划。

### 3.5 实施流程

#### 3.5.1 项目启动 (Project Kick-off)
* 制定项目计划。
* 建立日常管理政策。
* 制定文档计划。
* 建立开发标准，包括编码规范、程序和变量命名约定等。

#### 3.5.2 需求分析与功能确认 (Requirements Analysis & Function Confirmation)
* 基于产品原型，银行主导需求讨论，明确要实现的功能。
* VNB 根据银行业务人员的需求编制目标功能规格说明书。
* 银行组织业务人员对目标功能规格说明书进行确认。

#### 3.5.3 定制化（设计与开发）(Customization - Design & Development)
* 根据目标功能规格说明书，对产品原型之外的定制化需求进行详细设计，明确每个功能需求的实现方法。
* 针对关键方案组织设计评审。
* 完成程序编码和单元测试。
* 协助银行制定系统测试计划和策略。

#### 3.5.4 系统集成测试 (SIT - System Integration Testing)
* **V-CBS 内部集成测试：**
  * 制定系统测试计划和策略。
  * 编写系统测试用例。
  * 进行系统功能测试。这主要涉及在测试环境中创建测试数据并进行端到端系统集成测试。
  * 解决并完善测试中发现的问题。
  * 提交 SIT 分析报告。
* **端到端跨系统集成测试：**
  * VNB 协助银行技术人员在现有系统测试基础设施内调整项目环境；协调相关系统项目团队连接实际的前后端测试环境。
  * VNB 与银行项目团队共同制定系统测试计划和策略。
  * 与银行项目团队共同开发系统测试用例。
  * 与银行项目团队共同进行系统功能测试。这主要涉及在测试环境中与其他相关系统（包括核心银行系统）进行端到端测试。
  * 解决并完善测试中发现的问题。
  * 提交 SIT 分析报告。

#### 3.5.5 用户验收测试 (UAT - User Acceptance Testing)
* 银行组织业务人员进行 UAT，VNB 提供支持。
* 支持完成压力测试和性能测试，包括安全容错、系统启停、安装/卸载、互操作性、兼容性及其他技术测试活动。
* 提供培训材料，并向银行技术和业务人员交付技术和业务培训。

#### 3.5.6 上线与维护 (Go-Live & Maintenance)
* 银行主导制定试运行计划、上线计划、应急计划和资源需求建议书。
* VNB 协助银行系统安装；
* VNB 提供培训材料，并向银行技术和业务人员交付技术和业务培训。
* VNB 协助银行准备系统生产环境，包括软硬件安装、配置和集成服务。
* 银行主导完成试点分行所有功能模块的业务运营。
* VNB 提供现场业务和技术支持、运行监控维护以及故障排查与解决。

#### 3.5.7 项目交付物 (Project Deliverables)
* 产品功能规格说明书 (Product Functional Specification)
* 产品用户手册 (Product User Manual)
* 产品安装与部署手册 (Product Installation & Deployment Manual)
* 测试报告 (Test Report)
* 双方约定的其他文件（如适用）

---

## 4 知识转移

### 4.1 知识转移目标
知识转移的主要目标是将知识传授给银行的业务和技术人员，使其掌握系统的业务功能、技术架构、定制方法和相关的业务知识，最终使他们能够独立使用和维护系统。
* 通过产品功能和实施方法论的知识转移，确保银行相关部门在项目实施过程中提供有效的配合；
* 通过系统配置知识转移，确保相关维护人员具备对系统进行重新配置的能力；
* 通过对最终用户的操作培训，使操作人员能够熟练进行业务处理。

### 4.2 知识转移策略
根据供应商过去的实施经验，知识转移策略建议遵循**业务优先、技术在后，培训优先、实践在后，关键人员优先、后续推广在后**的原则，循序渐进地完成系统知识的转移。
* **业务优先，技术在后：** 知识转移（特别是对技术人员）从基础业务知识开始，然后再过渡到技术方案的知识转移。对于业务人员的培训，同样也是从业务功能开始，逐步涵盖系统操作流程、标准和基础技术背景知识。基础业务知识培训有助于技术人员更好地使用和维护系统。
* **培训优先，实践在后：** 知识转移从培训开始，开发相应的培训课程。在课堂教学达到一定程度后，安排实践活动。对于技术人员的技术转移实践，可采用协同开发或指导开发的方式，使技术人员在开发过程中掌握整个开发流程，包括设计标准、文档规范和实施技能。通过实际参与实施，完成系统全面的技术转移。
* **关键人员优先，后续推广在后：** 许多知识转移实践证明，首先对指定接收人中的关键人员（业务/技术骨干）进行培训，然后由这些骨干将知识传播给更多需要掌握相关知识和技能的人员，是最有效的知识转移方式。
* **知识转移范围考虑因素：**
  * 原产品功能的知识转移；
  * 定制化工作的知识转移；
  * 项目执行管理流程的知识转移，包括开发、环境、测试、优化、质量和版本控制；
  * 生产维护知识转移。
* **资源储备考虑因素：**
  * 人力资源储备，包括运营、生产支持和系统开发生命周期运营；
  * 规划和行动协调准备，包括各阶段的目标、计划和策略（包括应急计划）；
  * 其他储备准备，包括产品、技术文档、环境、质量和版本控制准备。
* **交接与过渡考虑因素：**
  * 安排系统交接准备，执行交接、过渡并转向独立运行；
  * 利用试运行期进行交接和接管工作，提高交接过程的质量。

### 4.3 知识转移方法
根据银行项目具体情况，知识转移可分为：面向业务人员的系统使用知识转移、面向技术人员的开发与维护知识转移、以及面向运维人员的生产运行监控知识转移。针对不同的目标人群，将采用不同的知识转移方法。
建议的知识转移方法如下：

| 知识转移类别 | 课堂培训 | 专题研讨会 (Workshop) | 提供文档 | 岗前培训 (OJT) | 导师指导 | 技术咨询 |
| :--- | :---: | :---: | :---: | :---: | :---: | :---: |
| **业务人员** | √ | √ | √ | | | √ |
| **技术人员** | √ | | √ | √ | √ | √ |
| **运维人员** | √ | | √ | √ | | √ |
| **管理人员** | √ | √ | √ | √ | √ | √ |

### 4.4 培训目标
在项目实施和应用过程中，需要对银行的业务和技术人员进行针对性培训，以确保银行各层级的员工能够有效使用本项目实施的系统。

### 4.5 通用培训要求
* VNB 负责提供培训材料。
* 培训内容应涵盖产品安装、使用、维护、操作、监控、常见问题及解决方法。
* VNB 负责提供一线支持和维护文档。

---

## 5 售后服务

### 5.1 保修期
系统保修维护服务期为 **12 个月**，自系统上线之日起计算。

### 5.2 保修服务范围
将提供以下支持渠道：
* 电话技术支持热线
* 电子邮件技术支持
* 现场技术支持（如果需要）

### 5.3 维护人员
VNB 提供经客户批准的合格系统维护人员，按照服务等级协议 (SLA) 提供业务和技术维护服务；
VNB 提供单一联络点服务热线，以解决系统运行期间的所有问题，包括业务、技术和商务事务。热线配备主（A 角）和备（B 角）顾问，作为彼此的资源备份。

### 5.4 服务等级协议 (SLA)

#### 5.4.1 一级事件 (Level 1 Incident - 紧急 Critical)
* **事件定义：**
  * 系统无法操作或使用，或发生严重功能错误，导致全行范围内的业务中断（例如：整个银行、多个部门、多个分行、柜台或渠道）
  * 影响范围广泛
  * 直接影响银行客户
* **服务承诺：**
  * **响应时间：** 收到事件电话后 **15 分钟内**做出响应，并立即启动根本原因调查
  * **根本原因提交时间：** 收到事件电话后 **1 小时内**提交
  * **可行规避方案 (Workaround) 提交时间：** **3 小时内**提交规避方案，将事件降级为二级事件，确保银行能继续运营
  * **最终解决方案提交时间：** **24 小时内**提交最终解决方案，排除故障并恢复所有系统功能和原有性能

#### 5.4.2 二级事件 (Level 2 Incident - 高 High)
* **事件定义：**
  * 系统无法操作或使用，或发生严重功能错误，导致部分业务中断（例如：单个部门、单个分行、柜台或渠道）
  * 影响范围中等
  * 直接影响部分银行客户
* **服务承诺：**
  * **响应时间：** 收到事件电话后 **30 分钟内**做出响应，并立即启动根本原因调查
  * **根本原因提交时间：** 收到事件电话后 **2 小时内**提交
  * **可行规避方案 (Workaround) 提交时间：** **12 小时内**提交规避方案，将事件降级为三级事件，确保银行能继续运营
  * **最终解决方案提交时间：** **48 小时内**提交最终解决方案，排除故障并恢复所有系统功能和原有性能

#### 5.4.3 三级事件 (Level 3 Incident - 中 Medium)
* **事件定义：**
  * 系统无法操作或使用，或发生功能错误，导致有限的业务中断（例如：单个用户或银行客户）
  * 部分功能不可用
  * 影响范围较小
  * 直接影响少数银行客户
* **服务承诺：**
  * **响应时间：** 收到事件电话后 **30 分钟内**做出响应，并立即启动根本原因调查
  * **根本原因提交时间：** 收到事件电话后 **24 小时内**提交
  * **可行规避方案 (Workaround) 提交时间：** **48 小时内**提交规避方案
  * **最终解决方案提交时间：** **5 个工作日内**提交最终解决方案，排除故障并恢复所有系统功能和原有性能