银行IT的敏捷转身

亿欧网 • 5年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

数字化挑战

过去的3年时间里，笔者作为敏捷转型顾问，合作频次最多的，就是全国大大小小的银行。银行业IT这一波的敏捷转型，很多人会归因为互联网金融的冲击，认为银行业IT被迫从原来的内部职能部门走上前台，迎战外部市场的挑战。也有不少银行从业人员，对此持有不同看法：类似P2P这样的互联网业务，对中国的银行业还谈不上任何的冲击。在笔者看来，真正冲击中国银行业的，是以下两个方面：

服务渠道的变迁——渠道从过去实体的网点向数字化渠道转移。注意，这并不是说所有的服务都变成了移动APP，而是所有的服务都会用某种数字化的形式呈现，比如现在到工行建行网点办卡都是通过一台综合服务机；交行几年前开始试点网点机器人，而招行已经在刷脸取款。由于银行之前是没有数字化部门的，所以这些要求自然跟IT挂上了钩。

FinTech的冲击——技术突破正在改变业务形态。最近火过了头的加密货币（比特币）正是这样的技术案例，它可能对未来银行业务产生颠覆性影响。在欧美很多利用智能技术做征信的平台也快速崛起，替代了传统费时费力的背景调查。对比之前的传统银行科技，FinTech拥有非常大的不确定性，这给习惯于购买成熟软件产品的银行带来了不小的挑战。当然由于又是科技相关，所以这口锅自然也得IT背了。

以上两点带来的变化显而易见，所以，无论提不提敏捷，银行IT都得转型。建立在支撑基础业务、保证业务稳定运行之上的IT部门，不可能自然而然演进成为“以用户为中心，思考服务体验，并保持对业界先进技术洞察”的新型数字化IT部门。下面就结合笔者过去3年中，近10家银行的顾问经历，谈谈这个转型中的挑战和可能的应对之策。

稳与快

我们辅导过一家外资银行，一上来就要求全球范围实施DevOps，“全面”敏捷。作为顾问，感觉很爽，改进起来气贯长虹。半年之后，已经没有不做敏捷改进的项目了，就连基于小型机AS/400的系统也都走上了DevOps的持续发布之路。

中国的银行业可就不是这样一个情况了。笔者和业内熟悉的几个人，经常开玩笑说“‘喝茶’就是悬在中国银行敏捷转型头上的‘达利摩斯之剑’”——高管们心里羡慕着互联网玩法的“小、快、灵”，脑子里却时刻担心着因生产事故被请去“喝茶”。转型需要经历烟斗曲线，当刚好处于曲线下挫点时，很可能因为一次事故而被全面叫停。一位银行科技高管曾经在内部会议上对我直言：“不要以为我不支持敏捷，正是因为我支持，所以才拉着你们跑慢一点”。

团队里有顾问找到笔者说不想做中国的银行了，太纠结，犹抱琵琶半遮面。于是我反问这位顾问，为什么中国的银行不能像外行一样一步到位呢？是因为太保守或者太官僚？一时问得对方语塞。其实，外行比起咱们可能更保守，生怕有一点负面消息，有的机构更庞大，更官僚。那么是什么原因，让我们中国的银行不敢“全面”敏捷呢？

就笔者目前认知，中国银行和外资银行有两点显著不同：一是中国银行集中精力办大事儿的构建方式；二是中国银行IT的历史定位。

如果我们对比中外银行的业务架构，会发现咱们的银行在业务设计上非常集中。这样的集中思路投射到IT系统建设上也是非常明显的：一般会考虑一套系统支持多条业务线。经典的例子是咱们的银行一般只有一套清算、核算平台，而外行每条业务线可能有自己的独立平台。集中建设的好处自然已经体现出来了，短时间我们就构建起来了一个相对完善的金融电子平台，但带来的问题就是系统非常复杂。

银行IT的敏捷转身

在敏捷转型过程中，有两个领域的复杂度是让笔者头疼的：电信和金融。大家可能想象不到，打通一次电话和完成一笔转账都要涉及近亿行代码！一条业务需求动辄要求修改十几个独立应用！咱们集中建设的银行系统显然不是随便就敢改的，早期即使在银行大型机系统上引入迭代开发都是很困难的。而这些系统往往又是银行的核心主干，任何小错误都可能造成致命的连锁反应。

在IT定位上，从国有五大行到各大股份制银行，基本都将IT归到了科技部下面统一管理。从组织结构上，可以看到IT的定位是一个共享的内部服务部门，或者说，是一个成本中心。最初的IT只是管理一些购买的商业软件和平台，并没有作为一个强自研能力的组织存在。银行IT的自有员工和外包人员比例，普遍都在1：6左右，一个主要的IT系统可能也就能投入两三个长期自有员工。到了现代，这个以科技为核心（Tech@Core）的时代，这样的人员配置显然已经捉襟见肘了。

以上两个因素，从技术架构和人员架构两个方面制约了敏捷的大规模推广。所以，银行想要“快”起来，往往不那么容易。各家银行的转型，都会选择相对新的技术领域，或和用户结合比较紧密的应用开始试点。而初期的转型目标，也会设定为“探索在现有约束条件下，如何进行敏捷模式落地”。最终，大多数银行都会走向“双模”：明确哪些系统和应用更看重业务表现的稳定性（采用瀑布模式），哪些更看重市场变化的响应速度（采用敏捷迭代模式）。

银行IT的敏捷转身

（图：源于Gartner总结的双模IT架构基本示意图）

理论上讲，“双模”只是一个过渡状态，这种方式也受到了不少专家的批评。“双模”可能会掩盖掉一些更深层次的问题，比如系统快不起来，根本原因其实是架构质量问题。从科技的发展趋势来看，确实止步于“双模”是不明智的，微服务化和平台化架构的逐步成熟会让以前稳定第一的系统也快起来。但就目前的约束来看，“双模”是已有成型建制银行IT的必经之路，其意义更多是在组织里植入管理不确定性的能力，从而构建对市场变化的快速响应能力。

效率与响应力

“唯快不破”是互联网服务发展的必备条件，而这个“快”其实是被很多管理者误解的。这个误解也造成了银行IT管理者们对“快”的提法有些许反感。这个误解的根源，在于对效率和响应力的混淆。

如果我们正确分析互联网成功服务的特质，就会发现他们根据市场变化推出和改变服务的速度特别快，而这个快很明确是在响应力上。举个日常生活中的例子，作为干洗店的客户，我们其实并不关心干洗店内部的效率问题（例如单位时间处理多少件衣服、干洗机的利用率等），我们关心的是干洗店能多好多快地把我们衣服洗好。

互联网时代给银行业带来的一个明显转变，就是从过去“以自身服务为中心”，到现在“以客户为中心”。从前在以自身服务为中心的时候，我们的管理方法及技术实践都是围绕效率来做的；到了这个时候，显然我们必须用客户的视角来思考问题，所以就需要更加关注响应力。当我们在追求效率的道路上走到一定程度，就有可能伤害响应力。比如为了干洗机的利用率，我们批量分类客户的同类型衣物放一个批次，显然这样的做法在订单达到一定数量的时候，会减缓每个客户的交货时间，让客户等待更久，伤害了对客户的响应力。

同理，这也是为什么在敏捷组织里，我们提倡少分角色、跨职能协作。当我们的分工过于细化时，对外部的变化响应能力就下降了。在传统银行IT系统里这样的情况是很普遍的，一个业务需求需要分解到十几个应用模块完成，而每个模块都只能由一个专人完成。

理解响应力的重要性并不难，但实践高响应力的管理却是相当困难的。银行业是一个重流程管理的行业，银行IT显然也继承了这样的基因。重流程标准化的管理方法，造成大家习惯性地进行自身局部效率的优化，实则增加了端到端的响应时间。笔者经常举一个发生在我们每天日常工作中的例子让大家意识到这个问题的严重性。

你是一位IT管理者，小王是一位认真负责的开发人员。一天他告诉你，现在项目A上他的工作进入尾声了，接下来只需要占用他一半的工作时间。这样的情况下，小王希望请示接下来的工作安排。在实际工作过程中，大家会赶快告诉小王启动项目B的工作，或者分配给他项目C的部分工作。假设小王启动了项目B的工作，很快他发现需要小李协助才能开展分析工作，而小李这个时候正在项目A上忙得不可开交。接下来有意思的事情就发生了，小王显然会要求小李配合，而这事儿如果真正发生了，显然就耽误了项目A的工期，那么项目A的完成时间就要推后了。小王和小李有可能找到你来请示工作优先级，然而，可怕地是，在你的意识里，会觉得这显然是“加加班”就能解决的问题！

于是，整个IT产业陷入了做不完的需求和越来越严重的内耗！

银行IT的敏捷转身

（图：小王工作安排示意，由于项目B的引入工作越来越多，成效却变少了）

实际上，如果我们认识到项目A的关键要素是快速推向市场，那么我们给小王的安排应该是让他继续专注于项目A，看看什么地方能够协助团队尽快完成项目。这个认知的转变是困难的：

作为管理者，要放弃过去对人员利用率的执着，理解利用率和响应力不是正比关系，在一定阶段后甚至和效率也没有正比关系。

作为员工，要放弃一个萝卜一个坑的工作模式，保持持续学习和跨职能工作的能力，把自己构建成一个T型人才。这个案例中，小王要能够帮助项目A的其它工作，就要求他具有开发之外的其它能力，比如测试。

在这样一个时代背景下，银行IT的敏捷转型，实际是基于以用户为中心的根本原则，加强整个组织的响应力。如果大家还在以“一个功能实现是不是更快了”来度量和牵引转型方向，那么请尽快调整到“面向市场和用户的端到端交付指标”上来。

业务与技术

懂业务是银行业人员晋升的关键因素。曾经在一次银行IT中层管理干部的培训上，笔者让大家举手表决是向业务方向发展，还是向技术方向发展，结果是全部都选择的业务方向。不可否认，银行业务的复杂度，要设计一套IT系统需要很强的业务理解。但数字化时代，技术成为了越来越重要的一个支柱，各银行组织如果不能快速构建技术人员的职业通道，必然很难在数字化上取得真正的收益。

我们从两个方面来看看中国银行业技术方面的挑战。

第一点是没有足够的技术封装。经常看到一个有意思的现象是，银行业务人员会看数据库，每一张数据库表就映射一张物理世界的报表。这样的设计结果往往是一张银行数据库表可能有好几百个字段。一段时间内，这样的设计是很流行的，因为沟通需求和最后验收都会相当顺畅，直接看数据库表就完成了技术和业务的交流。隐患就是，数据库根本就没有模型可言，修改任何的数据项都需要波及整个系统，所以大家就倾向于一开始就把所有的数据项全部列好，如果不确定就先留下一些空字段以备后续不时之需。

由于根本没有数据模型封装，看似业务上便于理解的设计，到后来也会因为冗余严重、耦合紧密而变得难于理解，或根本不可维护。只要是在基于如此架构上工作过的IT人员，就特别能理解，“为什么弄懂一个几千行的存储过程，需要花几天时间”。没有封装的结果，就是每个维护修改者都需要理解已有系统的所有复杂细节。这也是为什么我们在银行核心COBOL系统中，会看到大量的冗余代码——与其修改已有的程序，还不如忘记已实现的业务，为新增业务重新开发。

第二点是没有开放的技术生态。银行业经常把基于Java这样现代语言的开发称之为开放平台，与之对比的是传统基于大型机和小型机的封闭开发环境。最近还就开发效率问题和一个老牌银行技术人员进行过讨论。一个观点是，基于成熟封闭环境的开发一旦上手其实效率可以很高，对金融行业来说更加模式化，并且硬件保证了高性能和稳定性。于是笔者也花了不少时间，来研究这样环境下的开发模式，比如在绿色的传统命令界面上完全采用键盘操作，从代码管理到部署都是私有的平台和工具。

从笔者的角度来看，传统封闭开发环境有以下几个致命伤：

技术设计的表现力不够，造成可维护性差。长期下来，系统修改十分困难，成本随时间爬升很快。

不能够利用很多已有资源。从开源到云服务，实际上都是开放生态中的可用资源。开放技术的全球知识库早已超越了任何一家企业可以提供的技术服务。使用这些共享资源的门槛，就是需要加入到这样的开放生态中去，随着环境的发展而持续演进。

难以支撑快速的市场和用户扩张，对基础资源抽象隔离不够。以云服务为例，某种意义上，云是对之前我们计算机硬件资源的封装，让其成为像日常生活中水电气一样的公用资源，它使得我们在数字世界扩张的时候可以不再受基础资源的限制。然而，在银行IT中，这样的基础资源和服务抽象很少。

很多银行已经意识到了上述的问题，在科技发展方向上，决定逐步将系统应用向开发技术平台迁移。但还存在很严重地照搬过去架构设计的倾向，如前述数据库设计问题仍然存在于新系统中。在敏捷转型过程中，会发现即使在开放平台上也很难实现端到端的业务价值交付，其中核心症结之一仍然在技术架构上。去年，笔者花了比较大的精力在领域驱动设计（DDD）的推广上，也是希望通过这个方法让银行IT组织认识到正确的架构设计思想。

未来的银行数字化部门应该在应用设计上达成业务和技术的架构绑定，而在人员任职上形成业务和技术的双通道。

文档与人

曾经一句玩笑话“人走文档留”，引起了笔者对银行IT人才观的深入思考。从较长一个时期看，IT人才观的转变可能是中国银行业的最大挑战。在前沿程序设计会议上，当笔者倾听一家外行科技VP讲函数式编程，看到两家美国银行收购硅谷技术公司的业界新闻的时候，就深刻地意识到，把“文档”当成IT资产的观念，将会严重阻碍中国银行的科技发展。

也许，在国家鼓励下的BATJ合作，可能给咱们的银行IT业带来深层次的冲击。从去年开始，这个冲击已经超越了我们经典意义上的敏捷转型，而是银行组织级的变革。在这个过程中，笔者认为我们要解决三个组织级的定位问题。

IT合作伙伴的战略定位——从现在的人员外包模式，到面向价值共享的战略合作模式。现行包人头的方式，是敏捷转型的障碍，在银行数字化转型过程中必须重视并解决。当IT和数字化成为银行业未来业务的重要支柱，合作伙伴的定位及合作方式就必须相应改变。

IT人员的能力定位——从现行的流程执行模式，到面向业务和技术创新的持续学习模式。随着智能技术在未来几十年的持续渗透，追求效率的金融领域会逐步用机器替代掉重复性工作中的人。这对IT的影响是更深远的，很快我们就会有机器来代替基础的程序员和测试人员，也不再需要管理这些基础人员的IT自有组织。但更为紧缺的是，具备持续学习能力、能够快速响应市场需求变化的数字化人才。

数字化平台的支撑——从过去组织统一流程、检查规范模式，到平台化快速支撑模式。针对未来的不确定性，做细管理流程、强化检查节点的帮助其实是有限的，而提供快速的试验支撑，能够灵活快速地启动小规模多点尝试，则是成功的关键。

人才这个话题上，有一点是确定的：整个组织需要构建数字化人才的能力模型及持续培养体系。去年在国内，笔者也很欣喜地看到，若干家银行的高管们，开始过问大数据人才的招聘和留用问题，关心在现有体系下如何开辟新的渠道来灵活留用人才。