银行产品签解约的企业级业务架构设计(银行解除合同有违约金吗怎么算)
文丨中国银行软件中心深圳分中心 唐丽娟
近年来,在数字化转型的大背景下,如何设计满足业务动态变化和流程银行需求的信息系统架构,以提升产品研发和服务效率,在激烈的市场竞争中谋得发展成为银行业需要思考的一个重要课题。
产品作为银行收益的来源和服务客户的纽带,其签解约关系的信息化是银行实现数字化管理和服务的重要抓手。然而,当前银行产品琳琅满目,通常由不同的业务部门管理,其签解约在数据上无统一规范、在流程上无相关标准,信息共享难度极大。银行要进行数字化转型,必须站在企业级的全局高度,审视所有的产品签解约问题,打破部门边界,实现全行产品签解约信息集约共享和互联互通;从基于部门级需求的单一产品架构分析、设计模式,向建立统一、规范、标准的企业级架构设计转变,设计企业级的产品签解约业务架构方案。
一、银行产品签解约存在的问题
银行向客户提供的产品服务由各业务部门进行独立管理,在产品签解约服务上存在以下主要问题:
一是各部门系统签解约信息共享难度极大或不能共享,缺乏客户总签解约信息视图。基于产品之间是相互独立又联系的矛盾关系,客户签解约时,柜员需向其他业务部门逐一核查不相融的签解约信息,既存在误漏查风险又降低了服务效率。
二是各业务部门的签解约流程各自为政,各环节集成难度高,客户需要多次提供相似的签解约信息,反复签字、反复确认,导致场景生态内核能力不足、推陈出新困难。
三是各部门的签解约关系名同实异,客户、产品、介质、渠道、账户、合约之间的定义不清晰,特别是合约与账户的概念混为一谈,签解约关系的表达方式错综复杂,对内对外口径不一。
综上,商业银行亟需产品签解约企业级业务架构方案,以使产品签解约流程清晰化、信息共享化和管理标准化。
二、产品签解约企业级业务架构设计
根据《企业级业务架构设计方法论与实践》一书中的概念,企业级业务架构是以实现企业战略规划为目标,构建企业整体业务能力规划并将其传导给技术实现端的结构化能力分析方法,是企业级架构(包含业务架构和IT架构)最重要的组成部分。
企业级业务架构关注对银行业务的企业级描述,其设计起点为战略规划,通过深入剖析业务痛点发掘企业目标能力需求,再通过业务建模逐层细化能力需求以形成业务架构解决方案。业务建模主要从活动、资源和能力三个不同维度来细化方案,其表现形式为企业级的流程模型设计(活动)、数据模型设计(资源)和业务组件设计(能力)。产品签解约企业级业务架构设计包括以下几个方面。
1.战略规划设计
战略规划是业务架构的“DNA”,决定业务架构的骨骼和形态,企业级业务架构的“DNA”依赖原组织内部问题梳理和根源分析,并形成指导信息。下文对前述的银行产品签解约问题进行分析,并在此基础上形成战略规划。
(1)产品签解约问题根源分析
产品签解约问题的外在表现各不相同,但其根源在于产品签解约在业务上无组件化、标准化的共识表达。信息共享难度大的本质是数据标准不统一,场景生态缺乏发展竞争力的本质是流程标准不统一,签解约关系表达混乱的本质是业务概念标准不统一。
(2)产品签解约战略能力实现方向
基于以上根源剖析和未来银行场景生态的发展战略,企业级的产品签解约在流程、信息规范和集约共享三方面的能力亟待提升。
在签解约流程方面,应明确企业级的产品签解约、介质签解约和渠道签解约的流程以及数据之间的访问层级。
在信息规范方面,应首先对产品签解约的主体信息进行企业级定义,明确产品、客户、合约、账户、介质、渠道的概念和范围;其次解构它们之间的业务关联关系。
在集约共享方面,建立企业级的签解约信息谱系,从客户和管理等角度提供各维度的签解约信息及签解约的层级关系。
2.企业级概念共识
企业级概念共识的形成是业务架构细化建模的基础,引用FSDM模型中的金融企业数据九大分类概念,给出企业级的产品签解约主体定义如下。
渠道:银行通过信息网络或物理网点提供服务的通道,如银行网点、自助设备、网上银行、手机银行等。
产品:是银行为获得利润而销售或提供给客户的可市场化的服务或组合服务,包括代理或代销合作伙伴及竞争对手的服务。
客户:有意购买银行产品或签约银行服务渠道的个人或组织,不包括纯粹的银行合作伙伴。
合约:客户购买银行的产品,并针对此产品的规则和约束进行协商后确立的条款,包含双方权利、义务以及违约后的处理条款等信息,按银行的三类业务性质(负债类业务、资产类业务、中间类业务)逐层细分。
子合约:合约的附属依赖协议,依附合约而存在,是对合约信息的补充和丰富,如定期存款的下期约转、贷款的担保承诺等。
账户:客户购买银行产品后的资金信息载体。
介质:证明、记录、核实合约的实体物,如银行卡、存折和定期存单。
3.流程模型方案设计
流程模型表达业务活动的任务步骤和规则,产品签解约主要涉及客户购买产品、绑定介质和签解约渠道三个活动,围绕对合约、客户、账户、介质、渠道、子合约等主体信息建立的任务步骤和规则阐述,可形成标准化的签约流程模型(如图1所示)。
图1 标准化的签约流程模型
客户可单独或依据场景需要一次或分批次进行产品签约、渠道签约以及介质签约。产品签约的载体是合约,签约活动首先要进行合约户籍登记,其次建立具体的产品合约,最后建立账户(仅金融类产品存在账户)和子合约(依场景需要)。介质和渠道签约的载体不是合约,在流程上是建立产品合约与介质,以及渠道与客户的关系。
产品签解约是复杂的业务,因为产品与产品之间相互联系,单个产品签解约可能是反复建立合约以及确认产品合约之间关系的过程。
账户依赖合约建立,在流程上,访问账户必须通过账户所属的合约,而之后账户不再与介质、渠道以及非所属的产品合约存在关系。
4.数据模型方案设计
数据是一种资源,流程活动使用资源实现对外服务,资源的分门别类和关系清晰程度决定了服务的数字化效率。签解约流程使用了七大类资源,其中最主要的是合约,以合约为中心形成签解约的资源关系地图(如图2所示)。
图2 以合约为中心的签解约资源关系地图
建立产品合约需要建立各种不同类型的合约,合约自上而下逐层细分门类,共性信息逐层递减,聚类抽象后的共性信息被视为合约户籍,包含合约的名称、类型、签订日期、状态;各产品签解约的协议内容被视为该产品的个性信息,如图2中的存款合约。
合约与其他相关资源共同协作创造对外价值,主要存在以下关系。
合约与账户及子合约的关系是以合约为主导的强关系,子合约与账户均不能脱离合约而单独存在;客户与渠道的关系,合约与介质的关系,是提供客户体验的资源。这些关系在以合约为中心的体系中受关注度较弱。
合约与合约之间有因产品套餐而绑定的弱关系,也有因产品服务依赖而建立的强关系(如贷款合约依赖存款合约),是产品服务的数字化支持资源。
合约与客户之间是显性的权责关系,单个合约由多少个客户拥有、客户所占比重大小以及每个客户拥有的合约数目,是为场景化提供客户洞察信息的资源。
客户为购买产品而签约,合约依赖产品建立,故合约与产品之间的关系是产品竞争力强弱的分析资源。
5.业务组件设计
流程模型和数据模型完成企业级签解约方案的流程设计和信息标准设计,企业级签解约方案的任务和资源如何进行管理,还依赖业务组件方案从功能聚类的角度进行设计。
因具体的产品合约(如存款、贷款,贸易融资、借记卡合约等)原本由各业务部门分开管理,且资源数据差异显著,在业务和系统上均无集中意义,所以在业务组件的设计上,各产品合约随各产品服务一起独立门户,有利于企业级业务架构的稳定。对于子合约和账户,因其并不独立,在业务上依赖主产品合约,其聚类应与具体产品合约一致。
综上考虑,业务组件的设计如图3所示。
图3 业务组件设计
合约谱系组件是企业级的合约户籍和合约关系管理中心,是着力于客户或产品维度的合约画像,管理合约户籍以及合约与合约之间、合约与产品之间、合约与客户之间的关系。各业务组件的协作关系如下:产品研发组件依据客户、监管、市场和风险等各种情况研发出可售产品,客户签约前依据可售产品和自身情况选择产品进行签约,合约谱系组件登记客户何时购买了何种产品后,各产品类组件进行具体的产品签约,各产品服务业务组件提供具体产品的签约能力,管理各产品的具体产品合约、介质关系。
合约谱系组件在IT系统实施上通常有两种方案:方案一是作为联机交易系统,在签约或建立合约关系时实时向合约谱系对应的系统进行登记;方案二是作为后线数据分析管理系统,签约完成或建立合约关系后,再向其登记信息。
方案一完整承接业务组件的能力,但是合约谱系组件会成为热点瓶颈系统,存在系统压力。某些银行的核心系统部署在大型主机上,这对主机性能要求极高,而外调其他系统在性能上不可接受。
方案二在业务组件的能力承接上进行了妥协,合约谱系组件的数据不是实时的,可能存在不一致的情况,在产品签解约前向合约谱系组件查询的客户或产品维度合约画像信息不一定准确,故存在一些业务风险。
建议综合运用以上两种方案,对于性能要求极高的签解约采用事后报送的方案二,而对于风险容忍度较低的签解约采用方案一,在满足业务功能的同时兼顾客户体验。
本文针对商业银行存在的签解约流程和签解约数据杂乱无章问题,从企业级的高度进行了战略规划,并按企业级业务架构设计方法分别从数据、流程和组件的角度给出了解决方案。在数据层面上,对于签解约信息定义不统一,签解约关系错综复杂、不分主次的问题,通过模型设计转化为合约、产品、介质以及关系等清晰明确的实体概念以及简捷的联系。在流程层面上,对签解约流程和服务规则较为随意的问题,在模型设计后,拆除违规路径,依原则签解约。在组件层面上,在通盘考虑战略规划、业务现状和IT功能聚类等维度后,设计出复杂度最低、业务价值最大、IT功能聚类程度最高的合约户籍管理组件。对于IT系统实施方案,针对性能和风险之间较难平衡的问题,笔者也提出了解决办法。
本文来源于《中国金融电脑》2023年第1期