来源微信公众号：Sammy Liu 世民谈云计算
数字化时代，技术已经成了企业发展的重要驱动力，是转型中的企业不可或缺的力量。那采用什么样的组织结构，才能发挥出技术能力的最大价值呢？华为经历了多种组织形式，最终得出的结论是业务IT一体化组织是最合适的。
一、华为经历过的三种业务和IT组织形式
模式一：烟囱式组织
大部分传统企业都是以业务部门为核心的，IT部门只是一个配合部门，信息化只对业务发挥支持和保障业务的作用。业务部门首先提出业务需求，两个部门进行沟通，然后技术部门进行开发、实施和上线。这个过程，速度慢、周期长、成本高。这种组织形式，是典型的烟囱式组织，烟囱间（业务和IT之间）彼此隔离。这种组织形式也称为职能型组织或功能性组织。
在烟囱式组织里，价值链跨越了多个部门，内部信息流转节点过多，信息经过多个部门的处理后才传递到决策层。信息的处理、论证及决策链条过程很长，导致整体决策效率低下。此外，由于经常需要集中到业务的最高领导才能作出决策，使得纵向层级链出现负载，决策堆积，高层管理者不能做出快速的反应。
在复杂的业务环境下，跨越各个职能部门的横向协调成为常态。但是在烟囱式组织里，业务部门和IT部门没有共同的目标，每个部门服务于各自的KPI，造成部门墙厚重，横向协调极其困难，导致业务价值交付周期时间长，以及对客户的需求响应缓慢。
模式二：项目型组织
为了解决烟囱式组织存在的问题，华为2010年后采用了项目型组织。为解决某个特定问题，业务人员和技术人员形成一个项目组，解决完之后，项目组解散。
这种组织的问题是，它天生就是临时性的，只对项目目标负责，不对长期结果负责，所以没法把能力固化下来。
模式三：业务IT一体化组织
后来，华为开始搞业务IT一体化组织，并认为这是目前看来最好的一种组织。
这种组织结构中，技术人员不再是单独一个部门，而是成为具体业务部门的一部分，形成一种长期固定的组织形式。
在笔者看来，这种业务IT一体化组织，其做法应该是把技术人员打散到各个业务部门中去。其好处是显而易见的，就是技术人员离业务更近，减少了沟通成本。
但不足之处也是明显的，就是无法形成企业级能力，形成的只是部门级/领域级能力。为了解决这个问题，华为把各个业务单元的IT人员打散，将他们和业务部门的人员组成一个联合的混编团队，构建BET（Business Enable Team）团队；同时通过建立全球统一的运营中心来保证全球化大而不散。采用统一的底层平台同时赋予业务部门自主性，各个业务部门可以做自己的应用系统，但是IT资产、数据资产要按照统一的标准沉淀到集团的平台上来，供其他部门去调用。
二、业务IT一体化的目的是业技融合
笔者认为，建立业务IT一体化组织的目的是为了业务和IT融合。
业务和IT融合是个老生常谈的问题，但搜遍了互联网，都没找到一个明确的定义。“融合”是将若干元素整合在一起，形成一个有机整体。在数字化转型过程中，推动业务与IT的融合实际上是将信息技术有效应用到业务的各个环节，使得业务质效提升，驱动业务模式转型。与之相对的是，业务与IT“两张皮”，分离而不融合。
2010年，工业和信息化部发表了一篇文章《工业和信息化部完成重点行业两化融合发展水平评估》。某种程度上，工业和信息化部本身就可看做一国家级的业务（工业）和IT（信息化）融合领导组织。
文章提出，实现业务集成、精细管理和流程再造是两化融合领先企业的重要特征。企业通过业务和IT融合，优化或深刻变革了传统的业务流程、管理方式和经营模式，为企业发展注入了新的强大动力。也就是说，业务和IT融合，实际上是IT要融合进业务流程中去，对老旧的流程进行再造。
可以说得更远一点、更大一点。《第四次工业革命：挑战，机遇与实践》一文提到，当前正处于第四次工业革命期间，商业与科技之间的关系正面临着一场变革。在这场变革中, 科技的核心地位愈加凸显; 在这个新纪元, 外部层出不穷、颠覆式的新商机驱动着企业内部的变革；这次变革的浪潮，将迫使企业各部门必须以前所未有的方式紧密合作。
在前一次（第三次）工业革命中，信息技术一开始仅作为辅助业务的角色而存在，目的在于提升扩展性和效率。虽然信息技术很重要，但它并不是业务价值的主要来源，因此不管市场如何急速变化，技术仍然只是平稳缓慢地发展着。这种情况如下图左侧所示，在流程和控制占主导地位的关系里，信息技术和业务之间还隔着千山万水。可以把这个时期的业务和IT之间的关系称为“支撑型”关系。
而在第四次工业革命中，不仅每项业务都是数字化业务，而且每项业务的各个部分都是数字化的。新技术可以在商业模式层面上提供颠覆，创造出可以重塑整个行业生态系统的新机遇。一旦技术成为企业战略核心，从颠覆行业到事半功倍的一系列可能性将不再遥不可及。技术与业务通过战略协作紧密绑定在一起，将为各自领域提供锐意进取的新方式去追逐机遇。可以把这个时期的业务和IT之间的关系称为“融合型”关系。
综上所述，简单总结一下，业务和IT之间的关系可以分为两种：支撑型和融合型。 
- 支撑型关系：业务让IT干什么，IT就干什么。IT不懂业务，业务不懂IT。在业务眼里，IT部门的价值就是提供IT资源，并根据业务部门提供的需求写代码，在业务部门眼里，开发部门就像个外包团队，而且还没有外包团队听话。这种模式中，业务和IT是两张皮。
- 融合型关系：IT能力充分融合到业务流程中，为业务流程提供用户体验提升、数据分析、自动决策等能力和价值。这种模式中，IT和业务是一个整体，两者是一个团队，有共同的KPI。
支撑型关系模式下，IT系统建设是业务需求驱动的，是被动型的，IT技术团队是与业务线相匹配的支撑部门，业务部门提出需求，IT技术部门进行项目式的流水线模式开发。IT技术人员的KPI与各自业务部门的KPI相绑定，导致其缺乏全局统筹规划，所以天然形成了各自业务的组织墙，初始建设很快，但后续发展却异常复杂，代价极大。这种模式“局部最优，但全局未必最优”。
三、如何实现业务和IT融合？
如何实现业技融合，是一个老大难问题，没有一个完美方案。笔者认为两点很重要：一是，一把手认同是关键；二是，企业架构和中台是两把利器。
温思雅在《证券公司数字化转型中的业务与IT融合问题研究》一文，提出推动业务和IT融合的几项措施，笔者认为有一定的借鉴意义：
- 岗位方面，设置融合性岗位，比如首席信息官、产品经理、业务分析师、企业架构师等。复合型岗位的作用是搭建业务与IT之间的“桥梁”。
- 组织架构方面，设立业务与IT的复合型组织或部门。
- 人才培养方面，推动跨业务和IT领域的知识学习，推动跨部门轮岗。
- 协同方面，建立促进业务与IT沟通的机制，可采用合作办公、向业务部门派驻IT团队、KPI共担等措施。
示例案例一：建立基于企业中台的业务IT一体化组织
这种模式下，企业有统一的云平台、中台、架构管控体系和项目实施工艺。企业技术人员一分为二，一部分做企业级的东西，其余部分打散到各个部门，负责在企业级平台之上、企业级体系之下，做部门级的个性应用实现。这种应用，实际上只是薄薄一层业务逻辑，所以能又快又好。
这种模式，既能实现业务和IT一体化（部门级），又能保证避免重复建设（企业级管控体系+企业中台），还能加快应用交付速度（企业中台和平台，还可以加上低代码或零代码应用平台）。
**示例案例二：建行模式**
建行模式中，设置了一个专门团队，把业务人员和技术人员放在一起，专门负责对整个公司各个业务部门提出的业务需求进行需求分析，运用企业架构方法进行业务建模，生成标准化业务模型，作为下一步开发团队进行开发的输入。
这个专门的团队之中，既有来自于业务部门的业务人员，也有来自于技术部门的架构人员。采用定期轮岗方式，来避免能力固化。
**示例案例三：某地产集团模式**
昨晚跟两个在某地产集团做IT的朋友聊天，发现他们的业务IT融合做得蛮好。把他们的做法，按照笔者的理解，简单总结如下：
应用研发由过去的外购和外包，已转变为自研。组建了一两千人的研发团队。
在每条业务线内，成立了业务IT一体化组织，一个团队大约20人，包括业务人员和IT人员，负责该业务线内所有需求的分析。接到业务需求以后，通过业务流程的梳理，推动业务流程优化，推动新一代技术和业务流程的融合，推动共同的能力复用，推动使用集团共同的基础服务。
从集团层面，把应用分为两大类，一类是基础型系统，比如第三方支付、发票、会计核算等，支撑集团各业务线的应用；另一类是业务应用，主要是实现业务流程，能调用基础系统的就要调用基础系统。
虽然集团的研发团队是一个部门，但是把开发人员分为两类，一部分负责开发基础系统，另一部分负责对接各业务线负责开发业务系统。
虽然他们没有明确说企业架构和中台这些概念，但在笔者看来，他们实际上已经在采用企业架构理念，由业技融合团队负责业务架构设计和需求分析，再推动应用架构；基础型系统实际上起着业务中台的作用。对于企业架构和中台这种时髦的东西，有些企业是做了也不说，有些企业是说了也不做，有些企业是做了等于没做，有些企业是不说也不做。
四、给企业的启示
**
- 业务和IT融合是企业数字化转型的必然要求。可以说，没有业技融合，就没法做到数字化转型。结合企业的实际情况，选择最合适的模式吧。
- 业技融合有两个关键：一是组织机制的设计，因为融合的关键还是“人”，包括深刻认识到融合价值并有魄力推动实施的管理层，和具有业务和IT能力的复合型人才；二是把企业中台和企业架构作为两个落地实施的利器。
若有收获，就点个赞吧
0 人点赞
