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

本文来自织梦

上篇文章也谈证券行业数字化转型中的业务与IT融合（上）我们介绍了业务与IT融合的背景和要做的事情，可能很多人看到这就迫不及待想开始组建自己的融合团队，准备大干一场了。但是，在开始组建团队之前，有几件重要的事情一定要先想清楚，不然的话即使有了融合团队，效果也会大打折扣。

织梦内容管理系统

三、如何融合？具体怎么做

1、融合不只是组建团队这么简单

1）团队运作模式：从项目制到产品制，找到Owner 内容来自dedecms

现在，所有企业都是数字化企业，所有企业都应该计划并开始朝着更敏捷的产品交付团队迈进，如果尚未采取行动，那么现在已时不我待了。到2020年，四分之三的数字商业领导者将从项目管理转向产品组合管理。

织梦好，好织梦

——Gartner高级研究总监尹廸勤（Deacon D.K. Wan） 本文来自织梦

随着数字化转型的推进，团队运作从项目制转向产品制，以便更好地助力IT从成本中心转向利润中心，已逐步成为共识。转向产品制不是为了赶时髦，而是确实项目制在应对柔性需求和创新性需求时存在先天不足，如下图所示，仅有40%投资在真正的价值交付上。而产品制是对这一系列问题的一个有效解决方案。我想除了这些数据上的统计，很多在一线的项目经理肯定有很多切身之痛。

本文来自织梦

dedecms.com

项目制中的资源及时间分配：仅有40%投资在真正的价值交付上⁶

dedecms.com

那如何转向产品制呢？很多公司谈到业务与IT的融合，第一时间做的就是组建一个涵盖业务与IT人员的混编团队，并且让这个团队中的产品经理取代之前的需求分析人员，然后想当然地认为这个团队就好比酵母似的，自己就会引起面团的化学反应。

其实不然，要是有这么容易那倒简单了。特别是对那些项目制已经根深蒂固的企业来说，这里面有一个非常痛苦的转变过程。观察到不同公司的不同团队，其实很多人对这个转变的认识是远远不够的，导致顶着产品制的头衔，做的还是项目制的事情，效果就往往不佳。下图是ThoughtWorks总结的项目制与产品制的区别。

内容来自dedecms

项目制与产品制的本质区别⁶ 内容来自dedecms

当然，每个公司的规模、行业特性、企业文化、IT基础、人员规模和能力都有很大差别，如何实践产品制需要结合自身实际对一些最佳实践进行裁剪。但是要牢记的一点就是：项目制对应的是稳定的、确定性的需求，而产品制要应对的是变化的、不确定的需求，所以不管你所在公司的产品制怎么运作，一定要评估它的实施是否有帮助到团队更好地应对变化的需求，是否有助于团队逐步把不确定的需求清晰化，是否提升了团队应对不确定性的敏捷能力。 织梦内容管理系统

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

内容来自dedecms

——杰夫·贝佐斯（Jeff Bezos），亚马逊创始人

内容来自dedecms

具体到证券行业，由于IT部门的弱势地位不是一天两天可以改善的，所以最重要的是要为产品找到一个真正的业务方Owner（产品经理或者敏捷团队中Product Owner角色），特别是在中国企业的文化背景下，缺乏一个强有力的业务方的项目是很难成功的。有一个常被提及的火腿鸡蛋三明治的例子，在美国，日常的标准早餐是一杯牛奶+一个火腿鸡蛋三明治，在偏远农村的一户农民，一大早起来准备做早餐。他把上一年收成的小麦磨成粉做了面包片，把头一天晚上母鸡下的蛋拾起来做了煎鸡蛋，再去牛栏挤了一杯牛奶。想了想，三明治还需要什么？火腿肉！⁷那接下来就需要从猪身上割一块肉洗干净煎成火腿片，但是，我们很多项目，往往不缺乏提供支持（Support）的麦子、牛和母鸡，但是没人愿意承担“猪”这个主导（Lead）角色，因为它在这顿早餐中是最主要的贡献者，甚至可能奉献自己的生命。

织梦好，好织梦

这其中，要特别警惕两类情况。一类是主体责任不明确的项目，一类是领导驱动的项目。

织梦好，好织梦

责任不明确意味着一个项目同时有多个业务部门责任主体，貌似是好事，但是如果缺乏一个主导方，在需求拍板以及后续持续推动项目方面会遇到各种各样的问题，甚至很多时候有心推动项目的一方还会因为担心别的部门有什么想法而不愿意去努力这种诡异现象。

领导驱动项目指的是项目的发起来源于高层领导的一些想法，这些想法可能很具象，也可能只是一句话或一个模糊的概念。这类项目因为是高层领导驱动，所以从立项到建设基本上是一路绿灯，但是最大的问题就是这些需求是否是真正的需求，是否具备相应的推广价值，因为项目组和高层领导隔了好几层，很难进行有效的直接沟通。即使有的时候有业务方代表，但是基本上都是被领导委派来被动执行的，大部分都是那种“妈妈觉得哪个孩子冷”的情况，所以很大可能就是“棉衣”做好了，“孩子”会说他根本不冷，或者即使“冷”他需要的也不是“棉衣”，而是“羽绒服”。 织梦内容管理系统

找到真正的Owner是第一步，但这还不够，很多时候主导项目的业务方也很明确，但是为什么随着项目的推进，业务方好像对项目的热情逐步衰减，有点那种“食之无味，弃之可惜”的意味，其实问题出在没找到真正的价值上。 内容来自dedecms

2）团队目标一致：价值对齐，避免貌合神离

前面我们说过，业务与IT融合不是目的，只是一个手段，核心目的还是要回答IT价值从何而来，如何去量化地度量这个价值。很多时候，表象是业务好像不积极、不配合，其实核心症结还是在于业务没有看到项目成功上线到底能给他们带来多大的价值。所以，融合团队首先要把这个价值定义和发掘出来，并且在整个后续过程中尝试一直用价值来牵引。

copyright dedecms

在这个过程中，融合团队中的业务和IT方在思维上都要有所转变。 本文来自织梦

业务思维转变：定量的价值定义

大部分项目，或多或少都是存在业务价值的，但是很多时候这个价值的描述很模糊，不具象。或者只存在几个关键人员的脑海中，并没有通过文字的方式清晰地表述出来，也没有在团队层面达成广泛共识。久而久之，大家就很容易忘掉了建设项目的初心，最后围绕着一些具体的功能或菜单在那不停地“拉扯”，甚至遇到项目过程中有人员调整，接手者不了解之前项目锚定的价值设定，就很容易以自己的理解代替了项目的方向。

华为在其数字化转型过程中，提出了变革绩效评估（Transformation Achievement Measurement, TAM）和价值承诺书（Value Book）的做法，就非常值得借鉴。

内容来自dedecms

内容来自dedecms

华为变革价值度量模型：TAM模型⁸

织梦内容管理系统

TAM模型不仅包含服务于“多打粮食”的财务/客户层面的结果类指标，还包含支撑“增加土壤肥力”的能力类指标，以及支撑业务能力提升的流程、数据和IT等管理体系类指标。

copyright dedecms

copyright dedecms

变革项目Value Book模板⁸

织梦内容管理系统

而价值承诺书通过定性描述（目标、范围、变革点）和定量指标承诺，通过文字的输出，让脑海里可能偏模糊的想法更具象、更有逻辑性，而且在整个项目过程中我们都可以锚定这个价值承诺，并且可以基于此对项目成果和目标达成情况做出评估。

copyright dedecms

当然，这个价值的定义跟公司大环境有关，如果公司关于数字化转型有很清晰的转型愿景、业务也有很明确的北极星指标，那么定义出项目的价值相关容易些。但是不管怎么样，还是要非常认真地做这个动作，并把它当做项目初期非常重要的一项任务。 织梦好，好织梦

IT思维转变：IT也要以客户为中心

除了业务之外，IT在思维上也需要进行转变。过往，IT部门往往把交付放在第一位，考核的重点也放在了今年启动了多少个项目，有多少个项目上线了。这个时候，项目上线了对业务有没有价值，价值大不大，就不是IT关注的重点，在这种情况下，可想而知，即使组建了融合团队，彼此的目标不一致，心都不齐了，怎么可能有一个好的结果呢？ dedecms.com

数字化转型常提及要以客户为中心，其实原因很简单，业务的本质就是要为客户创造价值，以客户为中心就是要回归价值本源。那么现在IT也要创造价值，那么以客户为中心也是一条必走之路。

copyright dedecms

那么如何以客户为中心呢？ dedecms.com

《精益产品开发：原则、方法与实施》一书总结得挺好：

“从以资源效率为核心，转变为以流动效率为核心来组织产品交付过程。” 织梦好，好织梦

资源效率指的是从组织内部的角度，审视各个独立环节的产出效率；而流动效率是指从用户的角度，审视用户价值顺畅流动的程度。

因此，IT层面的以客户为中心就是聚焦价值流动效率来提高价值交付能力，把为业务交付了多少实际价值作为核心考量点，而不是只考虑完成或在建的项目数等本部门视角的效率情况。这里常有一个误区，容易把这个命题认为只是IT或金融科技部门的任务，其实业务部门也要开始思考，在数字化转型的大背景下，如何使用或借助新的数字化技术来助推本身的业务发展或进行一些业务创新，设定本业务的数字化愿景，而这个部分也往往是最难的和容易忽视的。 本文来自织梦

因此，IT也要将自己的目光从交付转向业务价值的提供，只有团队的目标一致、价值对齐，大家才可能真正力往一处使。 本文来自织梦

3）团队能力加强及融合

dedecms.com

除了目标一致，接下来团队的能力建设也非常重要。比如，切换到产品制后，对于相应的产品规划、产品运营、增长黑客等方面的知识要不要学习？为了更好地获取需求，一些辅助需求分析的方法或工具，比如影响地图、用户故事地图等，要不要掌握？还有为了更好地实践敏捷，像Scrum/XP等敏捷框架，一些精益软件思想，要不要了解？

本文来自织梦

数字化时代产品能力框架⁹

copyright dedecms

上图是ThoughtWorks总结出来的数字化时代产品能力框架，大家可以对照着进行相关能力补强。 内容来自dedecms

除了能力的补强之外，既然是业务+IT的融合团队，那么双方之间的能力融合也是非常重要的。IT人员要懂业务，业务人员也要懂IT，有了共同的语境，才更容易设身处地地站在对方立场上去考虑业务或IT的难处及所面临的挑战。

织梦好，好织梦

这里想强调一点，就是公司要为团队能力的提升和融合提供条件和创造机会，国内的券商在这方面比国外投行还是有很大差距。《软件开发本质论》¹⁰的作者就此给出了振聋发聩的发问。

真正能够帮助一个团队提高工作效率的是更高的技能。这意味着，在培训和教育方面的投入将以工作效率的形式得到回报。 织梦好，好织梦

人们在日常工作中已经够辛苦了。他们在有限的个人时间里利用晚上或者周末提升自己的能力，这种设想现实吗？我们怎样做才能够使这种设想更有可能成为现实？

内容来自dedecms

大部分员工的日子过得都不会很富裕。设想他们会利用自己的闲暇时间花钱去学习课程或者参加昂贵的会议，这现实吗？我们怎样做才能够确保他们有钱、有时间去学习，而且这些钱和时间真的用在学习上？ 织梦好，好织梦

4）组织机制、文化、考核和立项都要配套改变 copyright dedecms

融合团队是一个微观组织，它能不能按照设想很好地运作起来，还依赖于整个公司的大环境。比如考核机制有没有配套，如果融合小组成员在小组内的工作一点都不体现在其考核里，特别是业务同事，那么试想一下，业务同事很难会倾情投入其中的，像华为那样选派业务骨干全职投入变革小组就更是奢望了。其次，固有的预算、立项和审批机制，也会给融合小组推行敏捷制造很多的障碍，前期得有一股力量去推动这个变化才行。再次，很多中小券商严重依赖于实施商的力量，与实施商的合同、合作模式等也都会影响融合小组的最终效果。

最后，潜移默化的企业文化也是非常重要的。比如《领导变革》¹¹一书列出了20世纪组织和21世纪组织之间的比较，试想一下如果公司文化还是非常严重的“以公司内部为中心”，业务和IT都是以各自直属领导为中心，很难想象能在融合小组范围内做到以客户为中心的价值驱动。

本文来自织梦

copyright dedecms

20世纪组织和21世纪组织之间的比较 织梦好，好织梦

以上，我们介绍了融合团队的一些基本要求和注意事项。那么对于具体的需求，融合团队还有哪些特别注意的点呢，接下来我就结合柔性需求和创新性需求来重点介绍一下。 织梦好，好织梦

2、如何支持柔性需求 ：管好需求与运营这“一头一尾”

1）产品生命周期管理

织梦内容管理系统

《华为数字化转型之道》一书提到华为产品化运作方式中两个根本的转变，除了建立一体化协同团队之外就是按产品进行全生命周期管理：将研发由技术驱动转变为客户需求驱动的产品投资行为。 本文来自织梦

IT产品不仅承接业务变革的诉求，还承接业务持续优化和运营的诉求。IT产品全生命周期管理强调规划、建设、运营一体，不断循环。 织梦内容管理系统

IT产品规划、建设、运营一体⁸

dedecms.com

而在这其中，需要各位引起重视的就是需求阶段和容易被忽视的运营。

2）如何做好需求？问题域分解需求，精炼需求

内容来自dedecms

如何做好需求是一个老生常谈的话题，为什么需求如此重要？其实早在1986的“没有银弹”一文中就指出了关键所在，软件活动最根本困难是打造一个复杂概念结构，而概念性工作中最困难的就是确定需求。如果失误了，需求工作对系统的影响比其他任何一个部分都大，当然纠正需求的困难也比其他任何一个部分都要大。

“没有银弹”一文也给出了应对之法，就是“需求精炼和快速原型”，这也是后续一系列敏捷/精益实践的重要思想之一。但是在我们日常推行敏捷的过程中，经常遇到一个问题，就是业务对敏捷这种方式不理解，认为IT并没有把他的需求完全实现，就让他去做测试、上线验证不合适。与此同时，IT人员又会抱怨业务人员“无法沟通”，不懂MVP理念等等。其实根本的症结在于双方在需求分解上出现了偏差。《精益产品开发：原则、方法与实施》一书对此问题有比较系统性的总结，涉及到在问题域还是实现域分解需求的差异。

内容来自dedecms

本文来自织梦

传统开发模式，在实现域分解系统⁵ dedecms.com

传统开发模式，在实现域进行集中分解，意味着集中的集成和验证必然带来瀑布交付过程，无法支持快速迭代交付价值，而且开发人员和用户间的心智连接是断裂的。用户及业务人员工作在问题域，开发人员工作在实现域，大家各干各的，有点“老死不相往来”，鸿沟自然而然也就产生了。

而敏捷/精益开发强调的是在问题域分解产品需求，需求在问题域内被拆分成端到端的子项，开发团队每次只专注一小部分产品需求自然而然可以很好地实践迭代/增量的开发模式。

本文来自织梦

dedecms.com

精益和敏捷开发模式，在问题域分解问题⁵

而且，通过问题域的逻辑性良好的拆分，每个子项对于业务来说都是业务价值可感知的，业务人员自然而然愿意配合去做测试和上线试用，而不是之前那种IT人员自己在实现域自嗨式的版本规划，分解出来的子项对于业务来说是无法单独展现价值的，即使上线了，但是它是无法在真实业务场景中使用起来的，所以自然很难得到业务人员的支持和配合。 copyright dedecms

3）如何做好价值交付？ 加速验证，重视运营

除了需求侧，“没有银弹”一文还提出针对软件开发根本困难的另一个有效应对手段是“增量开发——增长，而非搭建系统”，这个更多的被解读为敏捷实践里的增量开发，但是还有一个因素被忽视了，那就是对运营的重视。

很多券商有专门的运维部门，很多IT系统上线后就移交给运维部门来做支持和维护。但是要注意，运营不是运维，两者是不同的概念，运维是被动式维持，更多的是保障系统可访问、可登录，强调的是稳定可用，而运营则是主动经营，更强调体验和效益。

织梦好，好织梦

很多互联网公司都是研发、产品和运营三分天下，一个产品发布上线后不是终点，仅仅只是开始。运营一方面可以帮助用户更好地使用产品，真正触及到产品的核心价值，另一方面，运营的过程也是获取用户反馈的过程，我们无法一次性完整、精确、正确地获取用户需求，就需要通过运营来加速这个迭代过程，更快更好地获取用户需求。

内容来自dedecms

就以人类为例，婴儿出生后是非常脆弱的，不会爬也不会走路，更别说说话或掌握什么技能了，然后需要经历“二抬三翻六坐,七滚八爬周岁走”这样一些发育里程碑才能在1年左右后学会走路，而大脑的发育更是需要几年、十几年，甚至终身都有可塑性。这一切的秘密就是人不是“一次性搭建”的，而是逐步发育成长的。 内容来自dedecms

因此，对于我们来说要从过往“重上线、轻运营”过渡到“全生命周期管理”，进行持续运营。避免出现“只管生不管养”的现象：不断建设，但缺乏系统性的规划，也不重视运营。

4）做好融合角色，而不仅仅是桥梁角色 织梦内容管理系统

当然，要想承担好以上的职责。融合团队的成员组成也非常重要，以上我们只是笼统地说到这个团队需要由业务和IT两方组成，那到底需要包含哪些角色呢？

典型的业务和IT一体化产品团队阵型⁸

《华为数字化转型之道》一书给出了华为推荐的融合团队角色组成，当然每家公司很难严格按照这个图去组织队伍，必须经过适当的裁剪，但是产品经理、业务架构师、数据人员、技术架构师、运营人员及敏捷教练（推荐使用敏捷模式）等角色是必不可少的。 织梦好，好织梦

相对于团队里的每个角色定位，其实整个团队在公司里的角色定位也是非常重要。对于柔性需求来说，它的基础还是现有的业务，所以融合团队应尽可能发挥自身的作用，把业务部门和IT部门真正粘合起来。很多时候，会把这个融合团队比喻成桥梁角色，其实我个人是不太认同这个比喻的，需要桥梁隐含的背景是桥的两边有很强烈的互通需求，可能现在已经在通过轮渡、绕道等各种方式在互联互通。但是，在证券行业，很多时候业务和IT还是存在很大割裂的，双方也没有更多和对方连接的意愿和需求。另外，桥梁还有一个隐喻就是它是被动的，桥修好了，有没有人流和车流是未知的。 copyright dedecms

所以，对于证券行业来说，融合团队应该更主动些，不要只满足于承担桥梁作用，而应该把业务和IT都调动起来，让双方实现真正的融合，慢慢把之前明显的边界模糊掉。 dedecms.com

3、如何支持好创新性需求：创业团队加模式，尽快获取“经证实的认知” 内容来自dedecms

创新性需求在很多方面和柔性需求类似，但是创新性需求在开始阶段一个最重要的工作就是定义产品，如《精益创业》¹²所说这个时候最关心的问题不应该是“这项产品能开发出来吗”，在现代经济中，几乎每件想象得到的产品都能被开发创造出来。更应该关注的问题是“需要开发这个产品吗”和“围绕这一系列的产品和服务，我们能建立一项可持续的业务吗”。

这其中第二个问题非常重要，很多时候，开发的产品和服务确实有价值，也能找到对应的市场，但是可能和公司的定位及业务秉性并不贴合，通俗地讲，就好像业务体外很突兀地长出的一块包，和现有业务没有任何协同，这种情况下也是很难在这个公司取得成功的。

内容来自dedecms

做过创业的人都知道，那种纯粹的颠覆性创新非常少，很多时候一个好的想法可能同时期有多人或者多个团队都有想到并同步在尝试，所以这个时候时间是非常重要的。因此，支持这类创新性需求就需要高响应性，而一个精干的、独立的自研团队基本上是不可或缺的。 织梦好，好织梦

而且，要尽可能快地将产品/服务投向市场，通过每一次路演、每一项新功能发布、每一次客户反馈来获取“经证实的认知”，从而加深我们对产品价值的认知。 本文来自织梦

4、融合团队搁在哪？ 内容来自dedecms

在之前的介绍中，更多的还是以业务为主导，IT承担一个使能的角色，因此这类融合团队可以直接放在业务部门，或者至少要前置到业务部门。但是在数字化转型的过程中，有一个重要趋势是IT除了要使能业务部门之外，在很多方面要承担起主力军和火车头角色。

copyright dedecms

《组织的逻辑》¹³一书对此有深刻的剖析：

织梦内容管理系统

职能部门如果完全倒向业务部门，那么企业很容易成为功利性组织，变得只有短期没有长期。 织梦好，好织梦

职能部门要服务业务多打粮食，但这只是问题的一面，另一方面，职能部门还有责任帮助企业增强土地肥力。 内容来自dedecms

职能部门更需对企业的能力成长负责，那些基业长青的企业总是把主要经历放在做企业而非赚钱上，其中许多做企业的能力，都是通过职能部门的努力，而存蓄下来的。 内容来自dedecms

而且，随着数字化转型的深入，这类企业级的数字化平台的重要性越来越凸显，IT在其中应该充当主要角色，牵引着整个产品的前进方向，而这类融合团队就应该放在公司层面。在华泰证券的相关实践中¹⁴，我们也能清晰地看到这两类组织： 织梦好，好织梦

• 业务部门协同：各个业务部门都有自己的 ITBP，他们作为“产品经理”的角色，能够顺畅对接业务需求。与此同时，我们在不同的阶段，也在探索 ITBP 前置的模式，把科技团队放到业务部门，以此实现对业务和市场更快速直接的响应。
• 集团层面协同：成立数字化运营部，从顶层设计调动与整合公司资源，真正站在客户与长期战略角度，打破企业内部的组织边界和部门墙，成为科技与业务双向深度融合的连接者。

麻省理工学院教授埃里克·布莱恩约弗森教授研究过诺贝尔经济学奖得主罗伯特·索洛（Robert Solow）提出的一个著名问题，就是为什么我们在信息技术的投资无法反映在生产力的提高上。

布莱恩约弗森教授的研究有一个重要的结论，就是对信息技术的投资需要有相应的对组织的调整，从而使组织的商业和管理流程更好地适应信息技术的发展。

换句话说，信息技术本身并不能给你带来竞争优势，技术和商业结合才是成功的关键². copyright dedecms

我想，以上这段话是业务+IT融合团队最好的注脚，也是团队的每一位成员都要时刻警醒的金玉良言。

本文来自织梦

---

参考资料：

6、从项目制到产品制之一：确定正确的产品边界 织梦好，好织梦

7、《华为数字化转型：企业持续有效增长的新引擎》，作者：周良军，邓斌 copyright dedecms

8、《华为数字化转型之道》，华为企业架构与变革管理部 著

织梦内容管理系统

9、数字化时代的产品能力建设

织梦好，好织梦

10、《软件开发本质论：追求简约、体现价值、逐步构建》，作者：罗恩·杰弗里斯

织梦好，好织梦

11、《领导变革》，约翰 P.科特 著 dedecms.com

12、《精益创业：如何建立一个精悍、可持续、可盈利的公司》，作者：埃里克·莱斯 copyright dedecms

13、《组织的逻辑》，丛龙峰著

本文来自织梦

14、华泰孙源青：华泰数字化转型下的组织驱动与HTalent人才发展体系 | DTDS

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

Tags：[db:TAG标签](93989)

转载请标注：作文网——也谈证券行业数字化转型中的业务与IT融合（下）