如何在数字化转型中整合业务和IT，确实是一个让人头疼的问题。 有的企业在业务部门内部设立了IT团队，有的企业成立了“业务+IT”专项行动小组，都是为了实现业务与IT的深度融合。 但是，如果只是组建一个团队，则不会进行其他更改。 就说几句鼓励和打气的话，然后丢给业务和技术的孩子自己去连接，他们能自己集成吗？
最近看到一篇文章，题目是《金融机构如何更好地整合业务人员和IT人员？ 总体思路是业务人员和IT人员必须融合成一个团队，并列举了一些如何构建真正的团队的方法。 这从方法论的角度教会了我们一些技巧，但仍然感觉还不够。
我们知道，要改变一种做法，必须了解它的背景和原因，还要衡量改变的结果，看看是否达到了最初的目的。 所以，如何更好的整合业务和IT，其实就是回到我们为什么要将两者整合的本源。
1、为什么要整合？ 1.业务+IT融合是构建敏捷组织的必由之路
如火如荼的数字化转型需要对企业的组织架构、文化、人力资源和领导力进行重构。 与过去一样，企业单独设立IT部门提供企业所需的技术支持，远远不能满足数字化建设的需要。
如今，企业的数字化战略与其业务战略密不可分。 麻省理工学院的韦斯特曼博士在 2017 年 10 月发表了一篇题为《你的组织不需要数字化战略》的文章，引起了不小的争议。 我个人同意文章中的观点。 我们在做数字化转型的时候，不能再按照旧的思路走。 不是IT或最新的数字技术如何更好地支持业务，而是数字技术如何改变组织本身、产品、服务、流程，重塑业务，即之前业务的所有基本假设都要进行重组，看看哪些数字技术或功能可以改变、优化甚至创造以前不存在的东西。 最终的结果是数字加持的新商业战略。 它不能是旧商业战略下的所谓单独的数字战略。
所以，融合是大势所趋，就像那些原来的数字化企业一样，根本没有所谓的业务部门和IT部门，IT就是业务，业务就是IT。 对于传统企业来说，要扭转这种固有印象，还需要做很多工作。 正因如此，不利的融合日益成为数字化转型的核心障碍。
哈佛商业评论总结了数字化转型的十大障碍，其中之一就是“IT 与业务线之间的协作不足”。
根据阿里研究院副院长安晓鹏博士的讲话实录
既然数字化战略和企业战略已经融合，是否可以以业务+IT项目组的形式制定公司的数字化战略，然后不同部门按照这个战略来实施？ 这条路已经行不通了。 在现在的VUCA时代，企业希望制定一个三五年的长期战略已经成为一种奢望。 企业在长期变化的环境中应对变化最有利的武器就是敏捷。 《数字化转型》2甚至断言敏捷是现代组织的关键核心品质之一，数字化的最终目标是敏捷组织。
您可以拥有的唯一可持续优势就是敏捷性，仅此而已。 因为没有什么是可持续的，你创造的一切都可以被其他人复制。
——杰夫·贝索斯
对于敏捷组织的建立，业务与IT的深度融合是其基础和前提。
2、业务+IT融合是IT“升值”时价值从何而来的答案
除了上述大背景外，业务与IT的融合还有一个现实问题，那就是IT越来越重要，越来越贵。 因此，IT的价值从何而来成为了一个无法回避的问题。
证券行业的数字化转型虽然还在探索中，但如何去做还没有统一的认识。 不过，要继续加大对IT的投入，这基本是共识，但很多人会发现，自己的企业经常喊口号是徒劳的，一旦涉及到真金白银，就畏缩不前。 哪里有问题？
IT部门曾经就像一个不那么重要的清水衙门。 每年投入1000万元，500万元保证基础运维没有问题，然后500万元用于去掉部分现有的系统升级和各种license费用，然后Tokenly开始几个新的项目。 至于项目实施的效果，其实公司并没有太在意。 只要不出大问题，年终总结的PPT应该做的漂亮一些，日常的甜品和人物应该放低一些。 一年就这样过去了。
但是，现在你说要大幅度增加IT投入，至少每年100-2亿，10亿，甚至10-20%的收入。 好家伙，你要这么多钱干什么？ 真正的问题来了。 一年的1000万，有没有效果也不要紧，扔到水里听听声音就可以了。 但是现在这笔账怎么算呢？ 如何说服强大的商业领袖并说服自己？ 节省这笔钱并获得更多奖金不是很好吗？
我们看到很多企业在这个问题上没有想清楚创业的基础和前提是，或者在公司层面没有达成共识，一时间虎视眈眈。 不管发生什么事，先把团队先拉起来，每个业务部门建一个IT团队。 而且他还点名了那些有大互联网公司背景的，他们要的是贵的。 然后，每个项目都迅速启动。 然而，折腾了一阵子后发现，除了PPT中的项目列表较长之外，业务层面似乎并没有感受到IT的作用，自然而然就有了反对和质疑的声音。
因此，IT与业务的融合，与其说是打通业务与IT之间的鸿沟，更好地支撑需求的实现，不如说是IT“提升自身价值”的必答题。 就像一个只能喝汤的团队。 要想吃锅里的肉，就得证明自己。 最好的办法就是参加前线的战斗。 不仅能帮助球队，还能帮助球队打赢这场仗。 当然，这个问题的答案不应该只是IT或FinTech部门的事情，而是应该由整个公司来回答的问题。
二、什么是融合？要做什么
很多人会说，我明白你说的道理，我们也建议公司组建集成团队，但是经常会遇到一个命题不知道怎么回答：你们IT天天讲集成，什么应该做些什么来实现这个所谓的融合？ 它与您作为一个独立的 IT 部门所做的工作有何不同？
不急于回答，我们先来看看数字化转型背景下需求侧的变化。
1、灵活创新的需求
随着这几年证券行业的信息化建设，一些监管要求，比如外部监管，或者业务发展必备的系统创业的基础和前提是，已经基本完成。 虽然还是会有一些升级或更换供应商的工作，但这样的需求基本是比较明确的，也可以为其他券商或产品服务商提供借鉴。 这时，需求发生了一些变化。 第一类是被业内同仁定义为“灵活需求”的需求：以个性化需求、客户服务、体验需求为代表。 特点是其中很多内容都是第一次做。 基本上没有成熟的做法可以借鉴。 有相当一部分需求开发的目的是为客户服务，尽量贴近客户的需求和喜好。 但是，很明显，人的喜好并不是那么容易一下子就挖掘出来的。 这类需求虽然变数很多，但好处是这类需求在类型上还是有一些共性的，基本逻辑还是大同小异的。 对于实施此类系统可以实现的效果和障碍，也存在相对共识。 的。 比如CRM系统，它的核心概念和系统主要模块的确定，包括客户分类和分级管理、360°视图、商机管理和销售覆盖等。难点不外乎管理方式系统和公司以及希望通过CRM解决什么问题的诉求高度相关，所以需要做的就是如何确定这些变量。
第二种需求则完全不同。 一开始可能只有一些想法和大概的方向，与现有的业务流程和业务模型完全不同。 我们称之为创新需求。 我们知道这一类需求可能只有一个用户痛点。 是痛点还是痒点？ 解决方案应该是什么样的？ 需要包括哪些核心功能？ 都需要快速进行试错和验证，然后在最短的时间窗口内走向市场。 针对这种需求，业务和IT需要深度融合，在企业内部形成“创业团队”，完成一个从0到1的“创业”过程。
2、灵活的需求：敏捷响应，提早交付价值，频繁提供价值
对于灵活的需求，我们先来看看目前IT和业务的交互模式可能存在哪些问题。
在传统方式中，IT更多是一个辅助角色。 如果业务部门有一些需求，IT会把相应的业务分析（BA）人员与业务对接，细化相应的需求，形成相应的需求文档（比如BRD等形式，或者原型+文档），然后用这个作为需求对接第三方实施者制定相应的解决方案，或者交给公司自研团队进行设计开发。 那么在后续的实施或者开发过程中，业务方基本上很少参与。 顶多就是一些关于项目进展的定期沟通。 最后，在实施/开发完成后，会邀请业务部门安排相关的UAT测试。 审核通过后 择日进行相关系统的上线流程。 上线后，业务使用过程中遇到的问题会再次聚合，形成下一个版本的升级或迭代（具体应对取决于不同的研发模式）。
上面的瀑布式模型让业务和IT的边界非常清晰明确，支持灵活需求的问题很明显，主要体现在两个方面：
结果通常是业务和 IT 相互抱怨。 企业认为 IT“缓慢、昂贵且困难”。 肯定有人会说你的描述是错误的。 我们公司已经采用了敏捷实践，业务和IT之间的鸿沟不复存在。 但是，你认为实施Agile之后，IT和业务之间的交互会像下图中的直线一样：
随着时间的推移比较客户或业务参与度4
事实上，它已经演变成如下特殊的开发模式：Water-Scrum-Fall模式。 虽然在实施阶段实现了迭代和增量开发，但在需求分析之前有业务规划和产品定义，在测试验收之后有程序实施和验证。 从更大的角度来看，一个项目从构思到交付的过程仍然是瀑布式的。
部分阶段迭代，无法更早交付价值5
可见，如果IT与业务没有真正的融合，即使在IT内部采用Scrum等敏捷实践，也很难从根本上解决上述问题。 我应该怎么办？
软件行业有一个行话：Garbage In, Garbage Out，意思是输入是垃圾，输出也会是垃圾。 所以，需求阶段对于一个项目的成功是非常关键的，它的价值是大家公认的。 因此，业务与IT融合的首要任务是优化需求阶段的输出。 但是，灵活需求的特点是不能一开始就确定需求。 因此，以敏捷和精益思想为代表的实践主张通过“尽早提供价值”来解决这个问题。
首先，我们不得不承认并接受这样一个现实：即我们无法从一开始就明确需求。 我们能做的就是加快需求的交付速度和迭代周期，通过实际的操作系统让业务在此基础上进一步发展。 细化或可视化他们对系统的期望和要求，然后以迭代和增量的方式不断改进系统。
为了使这种方法正常工作，IT 需要与业务深度集成。 在了解业务的基础上，分解一些初步思路，看看哪些是核心功能，哪些是“锦上添花”的附加属性，然后围绕核心功能驱动早交付，业务验证最重要的是。 具体怎么做，我们后面会详细介绍一些最佳实践。
3、创新需求：企业内部创业、产品定义、产品验证
对于创新需求，可能是基于现有商业模式优化或改进的增量式创新，也可能是彻底改变现有商业模式的颠覆式创新。 因此，第一步要明确这个创新对终端用户是否有足够的价值，即定义产品，然后证明它是一个好产品。 第二步还不够有好产品。 每个产品都有其适用的用户群体和市场。 比如你把私募的好产品卖给公募，效果自然不会好。 所以在定义好产品之后，需要有一个PMF（Product/Market Fit）过程，就是在特定的用户群和特定的市场中去验证产品。
而这个过程离不开对业务的深刻理解，以及对数字技术和能力的熟练，所以离不开业务与IT的深度融合。 这时候，我们可以借鉴创业团队的做法。 业务和IT采用类似于内部创业团队的方法。 我们一起继续尝试定义产品，即产品为其核心用户提供的独特价值。 边做边学，不断获取“经过验证的知识”，最终找到增长黑客定义的产品“顿悟时刻”。 产品定义好后，需要依靠业务人员对行业和用户的深刻理解，找到与现有产品/服务相比的差异，进而制定有针对性的策略/策略。 在整个过程中，还需要依靠IT人员必备的Growth hacking、运维等技能，实现产品的持续运营和迭代升级。
初创企业是在极端不确定的条件下开发新产品或服务的人。
— 埃里克·里斯
明确了业务和 IT 集成团队应针对不同类型的需求实现的目标。 在下一篇文章中，我们将继续讨论不同场景下具体要做的事情和一些最佳实践。 另外，一些常见的误解，融合团队的组成，以及对团队中IT人员的一些要求，都会再讨论。
参考：
1. George Westerman：您的组织不需要数字战略，来自《麻省理工学院斯隆管理评论》
2. “数字化飞跃：数字化转型的战略与策略”，作者：Raz Heiferman、Yesha Sivan、张晓全
3.《创新发展形势下证券公司项目与需求管理的思考》，作者：王洪涛、沈云明； 《交易技术前沿》第17期（2014年12月）
4. 《Scrum Essentials：敏捷转型指南》，作者：Kenneth S. Rubin
5、《精益产品开发：原理、方法与实施》，作者：何冕
