查看原文
其他

【招商银行研发中心副总经理夏雷】技术业务关系思考

夏雷 技术琐话 2022-07-13

招商银行研发中心副总经理 夏雷


银行科技圈一谈起工作,“技术与业务的关系”几乎永远是第一话题,之后才是科技队伍管理、系统建设等事项。这个特点不奇怪,因为这正是国内商业银行和互联网企业显著不同的地方,也是银行科技管理难以直接借鉴互联网巨头经验、需要独自探索的领域。技术与业务的关系说到底是技术队伍和业务队伍的管理问题,而考核是队伍管理的关键因素之一,因此,笔者结合自身的实践,谈谈对商业银行技术与业务关系的思考,以及为保障双方关系的考核方案的设计逻辑。



一、银行技术部门与业务部门的关系

有什么问题?



银行的技术与业务的关系很明确,“技术服务业务”,似乎没什么问题,这大概也是大部分银行从业者不假思索就能给出的答案,笔者也认可这个答案,技术当然要应用于业务才能产生商业价值。但如果我们再沿着这个问题追问下去,“技术服务业务”是否等价于“技术部门服务业务部门”?答案就未必如此明显了,下面进行简要分析。


(1)组织设计的基本原则是责权利匹配,有责才有权,有权必有责,给承担责任的人相应的权利,再给予相应的利益,否则这个组织设计是不稳定的,会矛盾丛生。商业银行传统的业务部门和技术部门间的组织设计恰恰是这样的不匹配结构(如图1所示)。


图1 传统银行业务部门、技术部门关系示意


这样的组织设计又可分为两大类:


  • 一类是业务部门不直接承担研发费用,技术部门的成本由银行列支。在这样的双方结构中,业务部门有权利有利益,技术部门则承担各种责任,且双方的责权利不能流动,矛盾丛生,例如业务部门不关注技术成本,提出低价值需求挥霍IT资源,业务收益再大也难以转化为IT研发资源,技术部门不关注业务紧迫性慢条斯理地开发,等等。


  • 另一类是业务部门承担研发费用,技术部门的项目都由业务部门计价后发起,或者研发完成后对成本内部计价分摊到业务部门。在这样的双方结构中,技术部门实质上退化为类似外包公司的角色,失去建设技术基础设施的动机,业务部门不提不做,乱提乱做,“技术引领”“技术驱动”流为空谈,银行技术基础能力贫弱,在金融科技趋势下越来越失去竞争力。


(2)银行的业务部门不代表银行的整体利益。一是国家对银行的技术有严格监管,如服务连续性、信息安全、基础设施建设等等,专业性极强,很难把这些职责交给业务部门去承担;二是银行的业务部门众多,难免受制于本部门的考核指标、短期利益,提出的很多需求连客户都代表不了,更无法代表银行的整体利益;三是业务部门由一个个具体的人构成,难免受制于个人的能力和格局,提出的低价值甚至无价值需求比比皆是。


(3)银行的科技成分在价值链中占比越来越大,科技部门本身即可产生重大业务价值。传统的银行竞争主要是比拼金融产品,而金融产品的复杂性主要是业务逻辑,其价值链中占比较大的确实是业务需求和业务部门。但现在的银行竞争主要比拼的是服务、场景、生态,加上普遍的互联网化,对系统的服务连续性、信息安全、性能容量、终端设备等相应的技术有着极高的要求,而这些是业务部门无法提出需求的。以微信为例,新增“业务”功能并不多,但其启动速度哪怕快上一秒,其业务价值就可能远大于无数个“业务”需求;再以淘宝为例,其强大的技术基础支撑“双11”天量抢购的业务价值,远大于淘宝上的“业务”功能。如果银行的科技部门满足于“服务”业务部门,其产品只有“业务”逻辑形成的业务价值,而缺乏“技术”能力形成的业务价值,将在竞争中越来越边缘化。


(4)银行不缺服务业务部门的外包公司。真正服务业务部门的科技队伍其实早就有,这就是广泛存在的外包科技公司,他们的收入来自业务部门,当然对业务部门言听计从,但这样的外包公司真的可以支撑起商业银行吗?业务需求怎么提怎么做,不提不做,乱提乱做,这个模式在一些对技术不讲究的领域仍然有存在价值,但一旦对系统的高可用、信息安全、技术先进性有要求,这个模式几乎没有竞争力。这样的外包公司在市场上很多,如果银行科技部门也和外包公司差不多,存在的意义就要存疑了。


可见,“技术部门服务业务部门”明显是“技术服务业务”的偷换概念,把“技术”偷换成“技术部门”,把“业务”偷换成“业务部门”。业务部门只是从他们的专业角度服务业务,技术部门也需要从自己的专业角度服务业务,彼此都是服务业务,而不是部门间谁服务谁的关系。如果一定要把技术部门的服务对象具体化,“技术部门服务客户”“技术部门服务市场”“技术部门服务银行”是更准确的陈述。这个误区能够存在很多年,至今仍然盛行,我想可能是有以下几个原因:


一是传统的商业银行以批发业务、线下业务、金融产品为主,基本上在数据库上根据业务部门的需求实现数据处理逻辑即可,而数据库又是成熟产品,技术部门无需在底层技术上做过多投入,价值链中科技占比确实不大。即使是今天,缺乏大规模线上零售业务的银行在技术上普遍落后,技术压力不足仍然是重要原因。


二是利益方的故意误导也是重要原因。商业银行业务部门众多,争取IT资源为部门利益、短期利益服务的动机很强,技术部门言听计从自然对达成这些目的有利,实践中很多业务部门把“服务”作为对技术部门的要求。科技外包公司和咨询公司也是利益相关方,较弱的银行技术部门有利于外包公司和咨询公司承揽更多的合同,曾经有一段时期,咨询公司鼓吹“银行的技术都可以买到”“银行聚焦自己的业务,让专业的公司做专业的事”,大抵也是这个原因。


三是部分科技管理者知道自己的“服务”角色不太合适,却仍然甘之如饴,躲避责任是重要原因。无权即无责,自己完全服务业务部门,系统的业务价值、技术基础带来的业务竞争力等等当然也就无需自己操心。一些银行的科技部门甚至主动把科技队伍的考评权部分单向转让给业务部门,名为“科技队伍往前站”,实则“科技队伍往后站”,向外包公司靠拢。


从上面的分析可以看出,“技术部门服务业务部门”的关系是不恰当的,很难适应当前金融科技的要求,其他形式不同但实质类似的表述同样如此,如“前后台关系”“甲乙方关系”等等。不少银行已经清醒地意识到这个问题,提出了“技术业务双轮驱动”,甚至“科技引领业务”等新型关系,但如何使新型关系制度化又是一个新课题。这个课题非常庞大,从全行战略到组织文化,从组织设计到薪酬激励,都需要大动干戈,一时难以指望。


在国内商业银行体制难以改变的情况下,银行科技工作者是否就无所作为?我们在实践中发现,技术队伍和业务队伍的考核设计是其中相对微观的一个环节,但影响不小,尤其是对形成新型组织文化有非常大的帮助,且相对容易改革,有可能成为建立新型双方关系的突破口,下面具体谈一下笔者对这个微观环节的思考过程。



二、如何通过考核机制稳定双方的关系?



很多银行其实早就意识到技术和业务的关系存在问题,也提出了很多要求和口号去纠正这些问题,尤其是操作性较强的考核领域,已经有银行尝试过一些措施,下面我们对这些措施作分析和比较,最后形成我们落地实施的办法。


1.指定对方指标


这是一个比较容易想到的办法,既然双方都对彼此有合作要求,那就把这些要求以考核指标或关键事项的形式固化下来,赋予一定的权重加到对方头上,促使双方兼顾全局收益、成本和风险。例如,给技术部门指派业务指标,给业务部门指派研发成本指标等等(如图2所示)。


图2 指定对方指标示意


这个方案的优点很明显,它改变了技术部门单向服务业务部门的传统定位,技术部门获得了一定的权力,也增加了一定的责任,而且以制度的形式固化,对打破双方长期形成的甲乙方观念有较大作用。但是这个方案的缺点也很明显,一是双方都对对方指标缺乏专业能力,压到自己头上也没用;二是业务指标或关键任务易使IT人员过于关注短期的、表层的业务需求,忽视对系统先进性、安全性、稳定性至关重要的基础设施建设,动摇产品长期发展的根基;三是事先制定的指标或关键任务难以适应现代金融科技的快速变化。


2.公共合作考核


这个方案的思路也比较朴素,既然目的是促进双方融合,那就对融合的公共合作部分作考核,而且双方考核内容一致,如合作态度、合作能力、对方满意度等等(如图3所示)。


图3 公共合作考核示意


这个方案的优点在于:一是考核的是公共的合作部分,可避免双方对彼此指标缺乏专业能力的情况;二是合作部分的指标或任务相对稳定,可避免因具体技术或业务指标的固化而导致不适应金融科技的快速变化。


但这个方案的缺点同样显著,主要原因来自双方的专业性毕竟有差异,能作为公共合作内容考核的只能是一些非专业的工作态度、合作态度等比较“虚”的指标,评价依赖当事人主观判断,得分高的人往往是“老好人”,缺乏担当,甚至牺牲全局利益迎合对方换取个人评分,因私废公,结果有可能成为负向指标。


3.内部市场化


这个思路借鉴外包合作建立双方的关系,业务方根据需求价值估算愿意付出的费用,技术方估算实施成本并报价,双方达成一致即可实施(如图4所示)。


图4 内部市场化示意


这一做法看似能平衡整体收益、成本和风险,但实质上缺乏市场化的前提:双方都处于垄断地位,都无法选择对方,业务方不认可技术方报出的成本,技术方不认可业务方报出的费用,并且因涉及计价问题,双方会很计较,保障公允的流程也很复杂,不利于快速响应市场。


4.考核指标互换


根据以上方案的利弊,我们提出第四种方案:考核指标互换。这个方案操作起来很简单,不论业务团队、技术团队自身如何考核,把一方的结果乘一个权重加给对方,形成双方的最终考核结果(如图5所示)。


图5 考核指标互换示意


这个方案的优点在于,考核简单,利益一致,易于协作,且不论外部环境如何快速变化,不论双方本职指标如何调整,双方始终是利益共同体。缺点在于,如果技术团队和业务团队的关联性不强,如一个技术团队对口很多业务团队,则考核指标难以简单互换。因此,这个方案比较适合技术和业务对口关系比较简单的领域。


总结以上四种方案,我们可以获得的对比结果见表1。


表1 四种方案的比较结果


招商银行的手机银行承载了“手机优先”战略,技术队伍和业务队伍都是专属资源,双方对口关系简单,根据表1,这种情况下“考核指标互换”有明显优势,我们很自然地选择了这个方案。自2016年4月技术和业务的融合团队成立以来,招商银行手机银行各项指标均有大幅增长,原先担忧的一些考核衍生问题也比预想的要轻微,成员团结协作,士气高昂,证明我们的考核机制是经得起实践检验的,可以作为经验分享。当然,我们的思考亦有局限性,这一实践也是我们特殊环境下的产物,未必普适,只是希望抛砖引玉,为国内商业银行有效推进金融科技工作提供一定借鉴。


原文转自:

夏雷 中国金融电脑 2019-10-28


往期推荐



技术琐话 


以分布式设计、架构、体系思想为基础,兼论研发相关的点点滴滴,不限于代码、质量体系和研发管理。




您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存