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

主页（http://www.kuwanit.com）：也谈证券行业数字化转型中的业务与IT融合（上）

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

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

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

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

4、《Scrum 精髓：敏捷转型指南》，作者：Kenneth S. Rubin

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

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

二、融合啥？要做什么

一、为啥融合？

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

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

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

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

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

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

在上面这个过程中，业务只是会在初期需求分析阶段及后续的 UAT 测试阶段才会和 IT 有频繁的互动，中间有一段非常长的 " 空档期 "。这样一来，即使业务后续对需求有了更进一步或更清晰的思路，这些明确后的想法即使优先级很高，但是也已经很难及时排入到实施 / 开发进程中，而要等到一堆还不知道是否能用得上的功能开发完之后才能排期。

整个实施或开发阶段的输入都来自于需求阶段和业务的沟通以及此过程产生的需求文档。而柔性需求由于其自身特点，业务方很难一次性清楚地表达出自己的需要，而 IT 方也往往由于缺乏相关经验，如果非要一开始就把需求在名义上确定下来，最终的结果很可能就是照猫画虎反类犬，完成的系统很难满足业务的需求。

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

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

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

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

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

本文系未央网专栏作者 :王和全 发表，内容属作者个人观点，不代表网站观点，未经许可严禁转载，违者必究！

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

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

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