数字化时代,技术已经成了企业发展的重要驱动力,是转型中的企业不可或缺的力量。那采用什么样的组织结构,才能发挥出技术能力的最大价值呢?华为经历了多种组织形式,最终得出的结论是业务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能力的复合型人才;二是把企业中台和企业架构作为两个落地实施的利器。


相关文章:

感谢您的阅读,欢迎关注我的微信公众号!

最新文章

  1. [Phalcon-framework] Phalcon framework - Dependency Injection/Service Location And the MVC architecture note 1
  2. [python]新手写爬虫v2.5(使用代理的异步爬虫)
  3. ZOJ 1109 Language of FatMouse
  4. 求数组中的最小子数组,时间复杂度o(n),java
  5. shell script创建库
  6. Prepared Java infrastructure for distributed scenarios
  7. JS面向对象编程创建类的方式
  8. 【转】Wireshark:“There are no interfaces on which a capture can be done ”
  9. php整理(二): 数组
  10. WCF 配置服务 (02)
  11. ext等待提示
  12. sql语句开发使用---update
  13. Delphi 数据类型的说明
  14. 【从零开始】用node搭建一个jsonp&json服务
  15. 安卓开发笔记(十):升级ListView为RecylerView的使用
  16. 加载配置文件-properties
  17. 【Sichuan 2017D】Dynamic Graph
  18. Atom+latex+中文环境
  19. 44个Java代码性能优化总结
  20. 170829、mybatis使用oracle和mybatis中批量更新

热门文章

  1. 微信小程序云开发-云存储-带图片的商品列表携带id跳转至商品详情
  2. mysql实现主从复制、读写分离的配置方法(二)
  3. 医疗器械软件产品经理必读的法规及标准-YY/T0664(一)
  4. 【递归+树】FBI树
  5. springboot多个service互相调用的事务处理(十三)
  6. SpringBoot: 后台接口文档 - 基于Swagger3
  7. redis的单线程
  8. vscode配置java+gradle开发环境
  9. 2019.06.28 MERGE INTO备忘
  10. XCTF-open-source