济南商行项目系统架构方案和技术组工作汇报_draft_20061204.pptVIP

目录 济南商行系统现状 总体架构 实施方案建议 技术组工作汇报 系统现状综述 标准支付接口 银联 小额支付 大额支付 行内渠道接入 ATM/POS 柜面通 电话银行 自助终端 中间业务 网通 联通 电信 煤气 电费 供暖 有线电视费 社会保险 水费 物业费 财税库行 前置管理 监管上报系统 反洗钱检测分析系统 结售汇报表系统 个人结算账户上报系统 国际收支统计检测系统 1104金融统计报表系统 内部管理系统 信贷管理系统 绩效考核系统 事后监督系统 新版OA系统 财务核算系统 客户管理 存款业务 贷款业务 借记卡 同城交换 电子联行 代收代发 目录 济南商行系统现状 总体架构 实施方案建议 技术组工作汇报 总体系统架构 功能架构分解－核心业务系统功能架构 功能架构分解－综合前置功能架构 功能架构分解－综合前端功能架构 功能架构分解－综合报表系统功能架构 物理部署架构 总体系统架构－Vision 目录 济南商行系统现状 总体架构 实施方案建议 技术组工作汇报 实施方案建议 第一阶段目标系统架构 第二阶段目标系统架构 目录 济南商行系统现状 总体架构 实施方案建议 技术部分工作汇报 工作计划 下一阶段的工作 渠道前置组 后台管理组 存在的问题 总帐系统方案需要尽快确定 信贷系统与KD系统的方案需要确定 监管类报表需求确认方式需要确定 事后监督系统需要明确未来的定位 绩效考核系统需要明确未来的定位 1104报表的数据确认方式需要多方认同 建议方案 信贷系统与KD系统的方案需要确定 通过专题会议解决关键问题 客户信息如何分布 评级（客户和债项） 抵质押品管理功能分布 产品代码的一致 额度产生和使用规则 主从合同的登记 核心联机放款接口 核心批量数据信息（如还款信息） 与信贷系统的关系－流程分析 建议方案 监管类报表需求确认方式需要确定 需要业务部门提出具体的报表差异分析时间计划 后台管理组已形成了初步任务分配计划，可否参考 1104报表的数据确认方式需要多方认同 首先由后台管理组根据1104报表的要求分析KM的数据 根据分析结果提交需补录数据给业务部门 业务部门根据补录数据信息提出优化改进方案 建议方案 绩效考核系统需要明确未来的定位 目前暂时无法从技术角度进行深入分析 在明确未来的绩效考核方法后再进行深入分析设计 事后监督系统需要明确未来的定位 目前暂时无法从技术角度进行深入分析 需要业务部门明确未来的监督管理模式 信贷调查 信贷审批 贷款发放 贷后管理 资产保全 客户信息 授信额度 放款通知 还款信息 信贷系统改造 为保证新核心业务系统的建设，信贷系统需要在初期就考虑如何与新核心系统进行配合，通过后台管理组的内部讨论，在以下问题上达成了初步设想。 1. 客户管理：信贷客户信息与核心客户信息同步，由于很多报表中需要客户基本信息，信贷系统保存核心客户信息的副本，信贷修改公共客户信息时先修改信贷客户信息，核心提供修改客户信息的接口，信贷系统修改核心客户信息。核心中客户信息被柜面或其他方式改变后，通过异步方式发送通知，信贷同步更新自己系统的客户信息。 2. 额度管理：信贷系统审批通过后，将额度更新到核心的额度设置中，放贷过程中如果信贷系统审批通过，到核心中如果超过额度，提示超过额度，需要授权，经过授权之后可以放款。 3. 放款管理：信贷系统提交放款通知书到核心，核心通过复核后执行放款 4. 还款管理：在核心中处理，每天跑批后将还款信息以文件方式发到信贷系统 商业机密 神州数码金融服务 济南市商业银行核心业务系统项目 系统架构方案 Draft Version 2006年12月1日 济南商行目前已经形成了包含综合业务系统、渠道前置系统、后台管理系统的较为完备的银行信息系统。 济南商行综合业务系统和前置系统中包含了各类渠道业务、中间业务和特色金融产品业务，两系统的替代需要较大的工作，需要按步骤进行平稳的替代。 系统现状综述 －特点 渠道前置系统分析 财 政 厅 系 统 ATM接入 POS接入 小额支付 前置控制 社保系统 服 务 渠 道 银联接入 外围接入 中间业务 电　　话 前 台 柜 面 服 务 渠 道 帐 务 接 口 票款分离 ATM机 POS机 CDM机 查询机 前台柜面 …… 综 合 前 置 系 统 批量代扣 网通话费 电 费 电信话费 联通话费 煤 气 费 有线电视 电话银行 财税库行 自助设备 短信平台 柜 面 通 。。。 回 单 柜 帐 务 接 口 渠 道 接 口 第三方系统 银 联 人行MBFE 帐 务 接 口 帐 务 接 口 综 合