如何在数字化转型中融合业务和IT，真的很头疼有的公司在业务部门成立IT团队，有的公司成立业务+IT专项行动小组，都是为了业务和IT的深度融合但是，如果只组建团队，其他什么都不改变，领导只是说几句鼓励和勉励的话，然后丢给业务和技术的孩子自己去连接，让他们自己去融入

我最近读了一篇题为金融机构如何更好地将业务与IT员工整合起来本文的主要思想是业务和IT人员必须整合成一个团队，并列出如何建立一个真正的团队的一些方法这从方法论的角度教会了我们一些技巧，但还是不够

我们知道，要改变一种做法，必须知道它的背景和原因，并衡量改变的结果，看看我们是否达到了我们最初设定的目标因此，如何更好地整合业务和IT，实际上是回到我们为什么需要整合两者的原点

一，为什么整合。

1.业务+IT集成是建立敏捷组织的唯一途径。

数字化转型如火如荼，需要重构企业的组织架构，文化，人力资源和领导力和过去一样，企业无法通过设立单独的IT部门提供所需的技术支持来满足数字化建设的需求

现在企业的数字化战略和企业的经营战略是密不可分的2017年10月，麻省理工学院的韦斯特曼博士发表了一篇题为《你的组织不需要数字化战略》的文章1，引起了巨大的争议个人比较认同这篇文章的观点我们做数字化转型，不能按照原来的旧思路我们不应该看IT或最新的数字技术如何更好地支持业务，而是应该思考数字技术如何改变组织本身，产品，服务，流程并重塑业务也就是说，要把之前业务的所有基本假设重新梳理一遍，看看有哪些数字技术或能力可以改变，优化甚至创造最终的结果是数字化带来了新的商业战略但不是旧商业战略下的所谓单一数字战略

所以融合是大势所趋，就像那些原生的数字企业一样没有业务部门和IT部门之分这是生意，生意就是生意对于传统企业来说，要扭转这种固有印象，需要做大量的工作正因为如此，不利的融合日益成为数字化转型的核心障碍

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

根据阿里研究院副院长安肖鹏博士的发言记录。

既然数字化战略和企业战略已经融为一体，是否可以以业务+IT项目组的形式制定公司的数字化战略，然后不同的部门根据这个战略去执行这条路也不行在现在的VUCA时代，企业制定一个三到五年的长期战略已经成为一种奢望企业在长期变化的环境中应对变化最有利的武器就是敏捷性数字化转型2断言，敏捷性是现代组织的关键核心素质之一，数字化的最终目标是敏捷组织

你唯一可持续的优势就是敏捷，仅此而已因为别的都是不可持续的，你创造的一切都可以被别人复制

杰夫·贝索斯

敏捷组织的基础和前提是业务和IT的深度融合。

2.业务+IT融合是对IT提升价值时价值从何而来的回答

除了上述背景，业务和IT的融合还有一个现实问题，就是IT越来越重要，越来越贵，那么IT的价值从哪里来就成了一个不可回避的问题。

虽然证券行业的数字化转型还在探索中，但如何做还没有统一的认识但是，我们需要不断增加IT投资，这基本上是一个共识但是很多人会发现，自己的公司经常喊口号，一旦真的涉及到真金白银的投资，就畏缩了有什么问题

以前IT部门就像清水衙门，不是很重要它一年投入1050万元保证基础运维不出问题，然后500万元花在升级部分现有系统和各种许可费用上，然后象征性地启动了几个新项目至于项目的实施效果，其实公司并不是很在意只要没有大的问题，那么年终总结的时候PPT会做的很漂亮，每天的甜点和数字都会拉低请企业领导美言几句，一年就过去了

可是现在你说要大幅度增加IT投入，一年至少1—2亿，10亿甚至10—20%的收入小子，你要这么多钱干什么真正的问题来了之前一年1000万有没有效果不重要把它扔进水里，听听声音但是现在这个账户呢如何说服强势的商业领袖和自己把这些钱省下来，多给点奖金不是很好吗

我们看到很多公司在这个问题上没有想清楚，或者说没有在公司层面达成共识，所以就像老虎一样凶猛不管怎样，他们先把团队拉起来，每个业务部门成立一个IT团队此外，任命一个想要大型互联网公司背景的人是很昂贵的然后，所有项目迅速上马但是过了一段时间，我发现除了PPT里那一长串的项目外，业务层面似乎没有感受到它的作用，自然就有反对和质疑的声音出来了

因此，IT与业务的融合，与其说是为了弥合业务与IT之间的鸿沟，以更好地支持需求的实现，不如说是为了在提升其价值之前，成为IT的必答题就像一支平时只能喝汤的队伍如果你想吃锅里的肉，那么你必须证明自己最好的办法就是参加一线战，这样不仅能帮助球队，还能帮助球队赢得战斗当然，这个问题的答案不应该仅仅是IT或者金融科技部门的事情，而应该是全公司的人来回答

第二，整合怎么办

很多人会说，你的原则我都懂，我们也建议公司成立一个整合团队但是，我们经常会碰到一个我不知道怎么回答的命题:你IT天天说要整合你能做什么来实现这种所谓的融合和你之前作为单独的IT部门做的有什么不同

先不要急着回答，我们先来看看数字化转型背景下，需求端发生了哪些变化。

1.柔性需求和创新需求

伴随着过去几年证券行业的信息化建设，一些外部的监管要求或者展业必备的制度基本都已经搭建好了虽然还是会有一些升级版本或者更换供应商的工作，但是这种需求基本是明确的，也是其他券商或者产品服务商可以借鉴的这时，需求出现了一些变化第一类是被业内同仁定义为柔性需求的需求:以个性化需求，客户服务，体验需求为代表特点是这些内容很多都是第一次做，市场上基本没有成熟的做法可供参考相当一部分需求开发的目的是为客户服务，试图弄清楚他们的需求和偏好但是，很明显，人的喜好不是那么容易一次就能挖掘出来的虽然这种需求的变量很多，但好处是这种需求的类型有一些共性，基本逻辑是相似的对于通过实施这种系统可以实现的功效和障碍有相对的共识比如CRM系统，确定其核心概念和系统的主要模块，包括客户分类和分类管理，360°视图，商机管理和销售覆盖等难点在于系统和公司的管理风格与希望通过CRM解决什么问题的需求高度相关，所以需要做的是如何确定这些变量

第二种需求完全不同可能刚开始的时候，只有一些思路和大方向，和现有的业务流程和商业模式完全不一样我们称之为创新需求我们对这种需求的了解，可能是用户的痛点只有一个是痛点还是只是痒解决方案应该是什么样的需要哪些核心功能都需要快速测试验证，然后在最短的时间窗口内投放市场对于这种需求，需要业务和IT深度融合，在企业内部组建创业团队，完成一个从0到1的创业过程

2.柔性需求:快速响应，早期交付价值，持续提供价值。

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

传统的方式，更多的是配角业务部门有哪些需求它会通过相应的业务分析师与业务对接，提炼出相应的需求，形成相应的需求文档然后作为需求与第三方实施者对接，制定相应的解决方案，或者交给公司自研团队设计开发然后在后续的实施或开发中，业务方很少参与，最多是对项目的进展有定期的沟通最后，在实施/开发完成后，将邀请业务部门安排相关的UAT测试，并在验证后，有选择地进行相关系统的上线流程上线后，业务使用中遇到的问题会再次汇总，然后形成下一个版本的升级或迭代

上面瀑布般的模型在业务和IT之间划出了清晰的界限。支持灵活需求的问题很明显，主要体现在两个方面:

整个实现或开发阶段的输入来自于需求阶段与业务之间的沟通以及在此过程中生成的需求文档但是，由于其自身的特点，灵活的需求很难让业务方一次表达清楚自己的需求，IT方往往缺乏相关的经验如果一开始就要在名义上确定需求，最后的结果很可能是模仿猫，画虎，反狗，完成的系统很难满足业务需求在上述过程中，业务只会在最初的需求分析阶段和随后的UAT测试阶段与IT有频繁的交互，中间有很长的空档期这样，即使业务后续对需求有了更进一步或更清晰的想法，即使这些清晰的想法优先级很高，也很难及时投入到实现/开发过程中，只能排在一堆还不知道是否能用的功能开发出来之后

因此，业务和IT部门经常互相抱怨业务觉得慢，贵，难，而抱怨业务说不清楚自己的需求，而且在不断变化有人看到这里肯定会说，你的描述不正确我们的公司已经采用了敏捷实践，业务和IT之间的鸿沟不再存在

一段时间内客户或业务方参与情况的比较4

实际上演变成了以下几种特殊的发展模式:水—Scrum—Fall模式虽然在实现阶段实现了迭代增量开发，但是在需求分析之前有业务规划和产品定义，在测试验收之后有方案实施和验证从更大的角度来看，从创意到交付的过程仍然是瀑布式的

部分迭代，无法提前交付值5。

可见，没有IT和业务的真正融合，即使IT采用了Scrum等敏捷实践，也很难从根本上解决上述问题那我该怎么办呢

软件行业有个行话:垃圾进，垃圾出，意思就是输入会是垃圾，输出也会是垃圾所以需求阶段对一个项目的成功非常关键，它的价值是大家公认的因此，业务和IT整合的首要任务是优化需求阶段的产出但是，柔性需求的特点是一开始就无法确定因此，以敏捷和精益思想为代表的实践主张尽快提供价值来解决这一问题

首先，我们不得不承认和接受这个现实:我们无法从一开始就定义需求我们能做的就是加快需求的交付率和迭代周期，让业务基于实际运行的系统进一步细化或可视化自己对系统的期望和需求，然后通过迭代和增量不断完善系统

要使这种方法正常工作，它需要与业务深度集成在了解业务的基础上，分解一些初步的想法，看看哪些是核心功能，哪些是锦上添花的附加属性，然后围绕核心功能推早期交付，再以此为基础验证业务具体怎么做，后续会详细介绍一些最佳做法

3.创新需求:企业内部创业，定义产品，验证产品。

至于创新需求，可能是基于现有商业模式优化或改进的渐进式创新，也可能是彻底改变现有商业模式的颠覆式创新所以，第一步要明确这个创新对最终用户是否有足够的价值，也就是定义产品，然后证明它是一个好产品第二步，光有好的产品是不够的每个产品都有其适用的用户群和市场比如你把私募的好产品卖给公募使用，效果自然不会好所以在定义好产品之后，需要有一个PMF过程，就是在特定的用户群体和特定的市场中验证产品

而这个过程离不开对业务的深刻理解，以及对数字技术和能力的掌握，所以离不开业务和it的深度融合这时候可以借鉴创业团队的做法业务和IT采取类似于内部创业团队的方式，共同通过不断尝试来定义这个产品，也就是这个产品为其核心用户提供了什么独特的价值，然后在实践中学习，不断获得被证明的认知，最终找到成长黑客中定义的产品啊哈时刻在明确产品之后，还需要借助业务人员对行业和用户的深入了解，找到与现有产品/服务的区别，进而制定出有针对性的打法/策略在整个过程中，还需要依靠it人员必备的成长黑客和运营技能，实现产品的持续运营和迭代升级

新创企业是由在极度不确定的情况下开发新产品或服务的人组成的组织。

埃里克·赖斯

为了阐明业务和IT集成团队应该为不同类型的需求实现什么，我们将在下一节继续讨论在不同场景中要做的具体事情和一些最佳实践此外，我们将讨论一些常见的误解，集成团队的组成以及对团队中IT人员的一些要求

参考资料:

1.乔治·韦斯特曼:你的组织不需要数字战略，来自麻省理工学院斯隆管理评论。

3.《创新发展形势下证券公司项目与需求管理的思考》，王洪涛，沈云明，《贸易技术前沿》第17期

5.精益产品开发:原则，方法和实施。