也谈证券行业数字化转型中的业务与IT融合（上）

（原标题：也谈证券行业数字化转型中的业务与IT融合（上））

数字化转型中业务和IT如何融合真是个头疼的问题。有些公司在业务部门内设IT团队，有些组建“业务+IT”的特别行动小组，目的都是希望业务和IT能够深度融合起来，但是如果只是组建了团队，其他什么改变都不做，领导们也只是说两句鼓励、加油的话，然后扔给业务和技术小朋友们自己去对接，就能自己融合了吗？

近期看到一篇名为“金融机构怎样才能让业务与IT人员更好的融合？”的文章，大意是业务与IT人员必须融合成为团队，并且列举了一些如何打造真正团队的方法。这是从方法论的角度教了我们一些技巧，但是感觉仍然不够。

我们知道，对一种做法进行改变，必须了解其背景和原因，还要对改变结果进行衡量，看是否达成了我们最初的设定目标。所以说，如何才能让业务和IT更好地融合其实是要回到我们为什么需要让两者融合这个原点上来。

一、为啥融合？

1、业务+IT融合是打造敏捷组织的必经之路

如火如荼的数字化转型，需要对企业的组织架构、文化、人力资源及领导力进行重构。像过去那样，企业通过组建一个单独的IT部门来提供企业所需的技术支持，已经远远无法满足数字化建设的需要。

如今，企业的数字化战略和企业的商业战略已密不可分。麻省理工学院的韦斯特曼博士在2017年10月曾发表了一篇名为“你的组织不需要数字化战略”的文章¹，曾引起很大的争议。个人非常认同文中的观点，我们做数字化转型，不能再沿用原来的老思路，不是看IT或最新的数字化技术能够如何更好地支持业务，而是要思考数字化技术是如何改变组织本身、产品、服务、流程以及重塑业务的，也就是对之前业务的所有基础假设都要重新梳理一遍，看数字化技术或能力能改变什么、优化什么甚至创造什么之前没有的，最终的结果是一个数字化加持的新的业务战略。而不能是旧的业务战略下的所谓单独的数字化战略。

因此，融合也就是大势所趋，就好比那些原生的数字化企业，根本没有所谓的业务部门和IT部门一说，IT即业务，业务即IT。对于传统企业来说，这里面是需要做很多的工作才能扭转这个固有印象的。正因为如此，融合不利也越来越成为了数字化转型的核心障碍。

哈佛商业评论总结了数字化转型的十大障碍，其中之一就是“IT与业务线之间的合作不足”。

根据阿里研究院副院长安筱鹏博士的演讲实录整理

既然数字化战略和企业战略已然是一体，那么是不是可以通过业务+IT项目小组的形式来制定公司的数字化战略，然后不同的部门就按照这个战略去具体执行呢？这条路也行不通了，在当下VUCA时代，企业希望能制定出一个三五年的长期战略已成为奢望，企业在长期变动环境中应对变化最有利的武器就是敏捷性，《数字跃迁》²更是断言敏捷是现代化组织的关键核心品质之一，而数字化的终极目标就是敏捷的组织。

你能拥有的唯一可持续的优势就是敏捷性，仅此而已。因为没有别的东西是可持续的，你创造的一切，其他人都能复制出来。

——杰夫·贝佐斯（Jeff Bezos）

而敏捷组织的打造，业务与IT的深度融合是它的基础和前提。

2、业务+IT融合是IT“提高身价”时对价值从何而来的回答

除了上述大的时代背景，业务与IT融合还有一个实际问题，也就是IT变得越来越重要，也越来越贵，因此IT价值从何而来也成了一个无法回避的问题。

虽然证券行业的数字化转型还在摸索之中，怎么做没有一个统一的认识。但是需要持续加大IT的投入这个基本上已经是共识，但是很多人会发现自己所在的公司经常是空喊口号，一旦真的涉及到真金白银的投入就畏畏缩缩了。问题出在哪呢？

IT部门之前就好比一个不怎么重要的清水衙门，一年投入个1千万，500万保障基础的运维不出问题，然后500万刨去一部分现有系统的升级和各类license费用，然后象征性地启动几个新项目。至于项目实施效果如何，其实公司也不怎么关心，只要不出大的问题，然后年终总结时PPT做得漂亮点，日常嘴甜点、身段放得低一点，请业务领导多美言几句，这一年也就这么对付过去了。

但是，现在你说要大幅提高IT投入，一年至少要1-2亿，10亿，甚至是营收的10-20%。好家伙，要这么多钱，你想干嘛？现实的问题就来了，以前一年一千万有没有效果无所谓，就当扔水里听个响声了。但是现在这个账怎么算？如何说服强势的业务领导们以及说服自己？把这些钱省下来多发点奖金不香吗？

我们看到很多公司对于这个问题没想清楚，或者没有在公司层面达成共识，就一阵操作猛如虎，不管三七二十一，先把队伍拉起来再说，每个业务部门都建一个IT团队，而且还指名道姓要互联网大厂背景的，要贵的。然后，一个个项目都火速上马。但是，一阵折腾下来，发现除了PPT里项目列表长了一些之外，好像业务层面并没有感觉到IT的作用，自然而然反对和质疑的声音就出来了。

因此，IT与业务的融合与其说是通过抹平业务与IT之间的鸿沟来更好地支撑需求的实现，倒不如说是IT在“提高身价”前要做的一道必答题。就好比一支平时只能喝汤的队伍，如果想吃锅里的肉，那么就必须证明自己，最好的办法就是参与前线打仗，不仅对队伍有帮助，而且能够帮助队伍打胜仗。当然，这个问题的回答不应该只是IT或金融科技部门的事情，而是应该整个公司一起来回答的问题。

二、融合啥？要做什么

很多人会说，你讲的大道理我都懂，我们也建议公司要组建融合团队，但是经常会遇到一道送命题不知道怎么回答：你们IT天天说要融合，请问要做什么才能实现这个所谓的融合？和之前作为一个单独的IT部门做的事情有什么不一样？

先不急着回答，我们先看看数字化转型背景下，需求侧都有哪些变化。

1、柔性需求和创新性需求

随着证券行业前些年的信息化建设，一些监管等外规要求、或者是展业必备的系统基本上都已建设完毕，虽然还会存在一些版本升级或替换供应商的工作，但是这类需求基本上比较明确，也可以较多地从其他券商或产品服务商进行借鉴。这个时候需求出现了一些变化，第一类是行业同仁定义为“柔性需求”的需求：以个性化需求、客户服务、体验类需求为代表，特点在于这些内容很多是第一次做，市场上基本上没有成熟的做法可以借鉴参考，相当一部分需求开发的目的就是为了服务客户，揣摩贴近客户的需求和喜好，然而很明显，人的喜好不是那么容易一次挖掘出来的³。虽然这类需求存在着诸多变量，但是好处是这类需求在类型上还是存在一些通用之处的，且基础的逻辑还是差不多的，实施这类系统能达成的功效及存在的障碍也是相对有共识的。比如CRM系统，其核心理念及构成系统的主要模块是确定的，包括客户分类分级管理、360°视图、商机管理和销售覆盖等，难点无非是该系统和公司的管理风格和希望通过CRM来解决什么问题这个诉求是高度相关的，所以需要做的就是如何把这部分变量确定下来。

而第二类需求就完全不一样，可能最开始的时候只是有一些想法和大致的方向，而且和现有的业务流程和商业模式完全不一样，我们称之为创新性需求。这类需求我们已知的可能只有一个存在的用户痛点，到底是不是一个痛点还只是痒点？解决方案应该是怎么样的？需要包括哪些核心功能？都需要快速地进行试错和验证，然后在尽可能短的时间窗口里去推向市场。对于这类需求，就需要业务和IT深度融合，组成一个企业内的“创业团队”，去完成一次从0到1的“创业”过程。

2、柔性需求：敏捷响应，尽早交付价值，经常提供价值

对于柔性需求，我们先来看看目前IT和业务的交互模式可能存在哪些问题。

传统的方式下，IT更多的是支持的角色，业务部门有一些什么需求，IT会由相应的业务分析（BA）人员和业务进行对接，细化相应的需求并形成对应的需求文档（比如BRD等形式，或原型+文档），然后以此作为需求和第三方实施商对接制定相应的解决方案，或者交由公司的自研团队进行设计、开发。然后在后续的实施或开发环节，业务方基本很少参与，顶多是定期有一些项目进度上的沟通，最后等实施/开发完成后，会邀请业务部门排期进行相关UAT测试，验证通过后择期进行相关系统的上线流程。上线后，业务使用过程中遇到的问题，会再进行汇聚，然后形成下一个版本的升级或迭代（具体响应情况视不同的研发模式而不同）。

上面这种偏瀑布式的模式使得业务和IT之间有很清晰的界限，泾渭分明，支持起柔性需求来说问题是显而易见的，主要体现在两个方面：

整个实施或开发阶段的输入都来自于需求阶段和业务的沟通以及此过程产生的需求文档。而柔性需求由于其自身特点，业务方很难一次性清楚地表达出自己的需要，而IT方也往往由于缺乏相关经验，如果非要一开始就把需求在名义上确定下来，最终的结果很可能就是照猫画虎反类犬，完成的系统很难满足业务的需求。
在上面这个过程中，业务只是会在初期需求分析阶段及后续的UAT测试阶段才会和IT有频繁的互动，中间有一段非常长的“空档期”。这样一来，即使业务后续对需求有了更进一步或更清晰的思路，这些明确后的想法即使优先级很高，但是也已经很难及时排入到实施/开发进程中，而要等到一堆还不知道是否能用得上的功能开发完之后才能排期。

导致结果往往是业务和IT互相抱怨，业务觉得IT“慢、贵、难”，IT抱怨业务讲不清需求、朝令夕改。有的人看到这里肯定会说，你这描述的不对，我们公司早已采取了敏捷实践，这种业务和IT之间的鸿沟已不存在了。但是，你以为实施敏捷后IT与业务的交互会像下图中的直线那样：

随着时间的推移，客户或业务方参与情况的对比⁴

实际上却演变成了以下这种特殊的开发模式：Water-Scrum-Fall模式。虽然实现阶段实现了迭代增量开发，但是需求分析之前还有业务的规划和产品的定义，测试验收之后还有方案实施和验证。从更大的角度看，项目从想法到交付的过程仍然是瀑布的。

部分阶段的迭代，无法更早交付价值⁵

可见，缺乏真正的IT与业务的融合，即使IT内部采取了Scrum等敏捷实践也很难从根本上解决上述问题。那应该怎么做呢？

软件行业有一句行话：Garbage In, Garbage Out，意思是输入的是垃圾，输出的还会是垃圾，因此，需求阶段对于一个项目的成功是非常关键的，其价值也是大家公认的。因此，业务与IT融合的首要任务就是优化需求阶段的产出。但是，柔性需求的特点就是开始无法把需求确定下来，因此，以敏捷、精益思想为代表的实践提倡通过“尽早提供价值”来解决这一问题。

首先，我们要承认和接受这一现实：就是我们无法从一开始就把需求给明确下来，我们能做的就是加快需求交付速率和迭代周期，通过实际运行的系统让业务基于这个基础之上进一步细化或具象化他们对系统的期望和要求，然后通过迭代、增量的方式不断地完善系统。

为使得这种方法能正常运转，IT需要和业务深度融合，在理解业务的基础之上，把一些初步的想法进行分解，看哪些是核心功能，哪些是“锦上添花”的附加属性，然后围绕核心功能推动尽早交付，然后业务基于这之上来进行验证。具体如何做，后续会展开详细介绍一些最佳实践。

3、创新性需求：企业内创业，定义产品，验证产品

而对于创新性需求，可能是基于现有业务模式的优化或改进的渐进式创新，也可能是对现有业务模式进行彻底改变的颠覆式创新。所以，第一步就是要把这个创新对于最终用户来说是否有足够的价值明确出来，也就是定义产品，然后证明它是一个好产品。第二步，有了一个好的产品还不行，每个产品有其适用的用户群体和市场，比如一个对于私募来说的好产品你把它推销给公募来使用，效果自然也不会好，所以在定义了好产品之后，还需要有一个PMF（Product/Market Fit）的过程，就是在具体用户群及特定市场里去验证这个产品。

而这个过程，离不开对业务的深刻理解，也少不了对数字化技术和能力的熟练掌握，所以说离不开业务和IT的深度融合。这个时候可以借鉴创业团队的做法，业务和IT采取类似于内部创业团队的方式，一起通过不断地尝试把这个产品给定义出来，也就是产品给它的核心用户提供了什么独一无二的价值，然后在实践中进行学习，不断地获取“经证实的认知”，最终找到增长黑客中定义的产品“啊哈时刻”。定义了产品之后，还需要借助业务人员对行业及用户的深刻认知，去找到相对于已有产品/服务的差异性，然后制定出针对性的打法/策略，整个过程中，也需要依赖IT人员必备的增长黑客、运营等技能，方能实现产品的持续运营、迭代升级。