0
独立存在的IT部，似乎正在从大公司消失。
近期，一篇《是时候砍掉IT部了》的文章被《华尔街日报》刊载，给这一趋势添了一把火，随即引发了业内热议。
该文由MIT斯隆管理学院首席研究科学家Joe Peppard 撰写，核心思想是：现有公司内设置“独立IT部门”的组织模式，阻碍了公司业务的创新、敏捷、以客户为中心和数字化转型。一些先进公司已经将集中式的IT部解散，选择把IT人员分散建在业务上。
事实上，这样的观点并非第一次出现，类似的实践也早已有之。
当前大部分科技公司，早期都按照职能来划分部门，这其中IT部作为重要的组成分支，自然和产品部、人事部同属于公司的独立一级部门，其领导CTO或CIO直接向CEO汇报。
但随着业务线和产品线的增多，一个独立的IT部往往无法及时灵活地服务所有产品线，因此不少公司也经历了“去IT部”的组织变革：肢解掉该部门，把工程师们发配到各个业务线上。
只不过有的成功，有的因此殒命。针对IT部的去留，以及IT与业务之间的组织关系，一直以来充满争议。
IT部独立集中化，企业更容易合力办大事，实现重大技术创新，完成彻底且高效的转型。
而拆分IT部，让IT分散在各个业务线上，则对业务创新层的技术支持更加灵活。
集中力量办大事 VS 高频的渐进式创新，前者的劣势就是后者的优势，同样，后者的劣势也是前者的优势。
目前我们所看到的大部分互联网公司，早已没了独立的、服务全公司的“集中式IT部”，相应也撤掉了CTO的岗位，即便存在，CTO的象征意义也大过实际效用。
而保留集中式IT部的企业，有两个极端：一种是刚走完或正走在信息化阶段的传统产业巨头；另一种则是像Google和Facebook这样的科技领导企业，两家公司至今依旧保留了独立且话语权巨大的IT部，其负责人直接向佩奇和扎克伯格汇报。
相应的，Google前CEO施密特也曾明确反对“去IT部化”的组织结构。
为什么越来越多的公司选择打散IT部、撤掉CTO？又为什么有些公司选择反其道而行？
国内BATJH等巨头在IT部的砍与留、CTO的入局和出局，又经历了哪些曲折反复？本文将会对其进行宏观概述，更多案例和真实故事，雷峰网将在《京东技术大复盘·五问》系列中，以京东为研究对象，进行深入挖掘和报道。
长久以来，大量公司都在忍受着一种痼疾：职能型组织架构下，各个部门承担各自的功能，各部门内部沟通畅通无阻，但跨部门间如烟囱般彼此隔离，相互沟通协作不畅，组织效率大幅折损。
尤其最近几年，数字化浪潮下，面对瞬息万变、多元复杂的市场需求，IT与业务之间的部门墙，尤其是让传统企业愈发痛苦不堪。
究其原因，一是，独立的IT部在日常运作中，与业务部更多是“合作伙伴”而非利益共同体，IT部的工作成果是按自身预算达成或项目验收来衡量，不与业务部绩效挂钩，导致IT配合业务的积极性不高；
二是，业务部很难提前预见到业务的数字化需求，而IT部的预算却是至少提前一年就得审批，供需脱钩，IT建设无法敏捷支持业务；
三是，由于技术人员长期脱离具体业务场景，缺乏足够的行业know-how，在实现需求时，往往要先花大量时间去了解业务逻辑，导致交付周期的延长。
鉴于以上痛点，一些公司干脆把原有的IT部解散，将人员全部下放到各个业务部门，让各业务部拥有自己的IT团队，随时解决各种问题。
砍掉IT部，把IT建在业务上，直接打破了部门墙，提升了效率，但也埋下了两颗“定时炸弹”：
一是当遇到重大技术迭代的新浪潮，公司无法集中所有IT力量去All in技术新基建，可能因此错失最佳转型时机。
二是当业务部门拥有完整的技术团队后，基本满足了自成一派的条件。随着业务发展，各业务线可能会自扫门前雪，将部门利益至于公司整体利益之上，出现“诸侯割据”的乱象。
在第一个问题上，一位曾在多家巨头企业担任技术高管的专家告诉雷峰网，为什么国内的技术部门永远是业务的支撑者，哪里需要补哪里，哪里有锅背哪里，但却很难像Google的工程部一样，成为产品部门的第一推动者？是差人还是差钱，都不是。
“一个关键因素是，过去20年，国内多数工程师水平是比较差的，即便是BAT这样的企业，堆积了20多年的代码依旧像垃圾一样，要在这基础上，持续做出能产生实际效益的技术创新，难于上青天。这时候要么重做一遍地基，把架构、系统、代码翻新一遍，要么干脆另起炉灶，把新业务搭在新技术体系上。”
但搭建全新的技术体系也好，新的中台也罢，这一过程中，只有CTO领衔的独立IT部，才有可能将之有效地落实到位。而让分布在各个业务线的技术团队，带着各自利益立场，临时组合起来去执行，显然不现实。
拥有独立IT部的企业更易恪守长期主义，也更能以长远眼光和大局观看问题，把握住时代大势。
但如果技术全部建在业务上，各部门并没有动力兴师动众去配合其他产品线，做一件烧钱且不见收益的事情上。尤其是光景不错的时期，看着每年营业数据的飞长，他们甚至会认为，即便在垃圾堆上做研发，似乎也并没什么大碍。技术无用论，也就此产生。
技术本身是长期之事，一旦沦为纯业务支撑，必将会进入短视的恶性循环。当行业整体下行时，技术积累和数字化能力不足的企业，管理和经营上的致命弱点，便会暴露而出。
而在第二个问题上，去IT部门化，将直接加速企业的诸侯化。
一个知名的惨痛案例是：发明了Java的SUN公司，在公司发展一片大好时砍掉了IT部，结果导致整个公司分崩离析。
Google前CEO施密特曾在《重新定义公司》中写道，早期他在SUN公司担任CEO时，随着业务越来越复杂，公司决定调整组织架构，分设多个业务单元，称为“行星”，每个“行星”独立运作，人员配置五脏俱全。
但由于自成一体，自负盈亏，各单元各自为政的情况越来越严重，甚至认为集团的战略与己无关。最终，SUN的行星组织结构，对企业的生产力造成了重创，使其在最巅峰时轰然陨落。
施密特
前车之鉴令人扼腕，也足以说明组织架构的调整，绝非易事，调整得好，如获新生，调整不好，则会伤筋动骨、元气大伤甚至死路一条。面对这一难题，国内互联网科技巨头们也基于各自的发展轨迹给出了不尽相同的复杂回应。
华为是砍掉IT部的一派，但比之更为激进。
2010年，在吃了多年IT与业务的协同之苦后，华为开始采用项目型组织，让业务人员和IT人员组成一个项目组，去解决特定的问题，解决完后，项目组解散。 但项目组的临时性导致无法把做项目得来的经验沉淀成公司的能力。
为了解决能力流失，华为再次优化组织，确定了“业务IT一体化”的组织模式，成立企业BG、运营商BG、消费者BG。按照规定，技术必须懂业务规则才能施工，业务必须和技术的流程相配合，技术与业务进一步融合。
但没几年，又遭遇了瓶颈。随着数字化转型加速进入深水区，传统政企机构急需全方位、长周期的“云-管-端”一体化改造，此前各BG单兵作战的模式难以满足这一需求。与此同时，华为受美国打压持续加重，如何集中力量，在产业数字化上快速破局从而活下来，变得迫在眉睫。
这样的背景下，2021年华为开始创建“军团”模式。把各BG/BU等核心部门的将才，整合到海关、公路、能源、光伏等一个个以细分场景为单位的独立部门中，为客户提供一套更全面的解决方案。
不仅仅是技术和业务的融合。任正非曾在接受媒体采访时表示，“华为的军团是把基础研究的科学家、技术专家、产品专家、工程专家、销售专家、交付与服务专家全都汇聚在一个部门，缩短产品进步的周期。”同时，为了让军团拥有较大的独立权，任正非赋予了华为军团与BG等同的部门地位，同属集团一级部门。
不难看出，华为的军团模式，要比砍掉IT部、把技术建在业务上，更为激进。这样组织调整，更像是短期应急的一剂猛药。
在雷峰网看来，华为的军团模式或许局部、短期最优，但长期隐患很大。虽然在初期阶段，有助于在几个垂直领域集中火力做深做透，缓解生存之急；但从长期看，急攻于增长而大量放权，极有可能造成放出去的时候是一个“军团”，收回来的时候是一个“王国”，几大军团配置越强，地位越高，其发展壮大后“失控”的可能性也就越大。GE帝国的分崩离析，与该组织模式的应用不无关联。详情可参考雷峰网(公众号：雷峰网)文章《华为的「军团」组织模式：破茧重生，还是作死？》
2005年，也就是腾讯上市的第二年，腾讯迎来了公司的首次重大组织变革。在此之前，腾讯的主要业务相对比较集中，因此内部组织是按功能模块划分的，比如，开发、设计、市场销售各自成一部，每个部门同时支持多个产品。但随着新业务越来越多，速度就成了第一生产力，因此腾讯将公司BU化，尽可能把所有一线资源进行切分，分别闭环到各个BU。本质上与“去IT化”如出一辙。
但不同于其他企业的完全拆散，腾讯在IT组织架构上，采取了一个折中方案：在六大事业群里保留了一个类似“独立IT部”的技术工程事业群（TEG）。
张志东
消息人士告诉雷峰网，早些年，腾讯前CTO张志东在任时，与世界上所有的CTO一样，时常与技术线、业务线高管产生分歧。其中在某项所有业务必不可少的技术部署上，张志东认为应该由集团IT部统一管理，给各个业务线做支撑。而另一派代表则认为，该技术团队应该打散，融入至各业务线当中。
这样的争执不止一次发生。
无论是集中式管理，还是分散式部署，都是企业无法避免，且会制造不少矛盾的选项。
如前所述，两种模式各有利弊，但多数企业为了更加敏捷，在发展最迅猛的阶段，选择了后者。腾讯也不例外。
但不同之处在于，腾讯将IT团队一分为二，其中3~4成的研发人员组成了TEG，而剩下的6~7成的人员分散在其他5个以业务为主导的事业群。
现在回看，尽管腾讯选择了分散式IT管理，但对其缺陷也做了提前预防：组建了现在拥有1.3万多人的独立技术事业群TEG，一方面为腾讯思考和推动更为长期的基建之事，另一方面为各大事业群提供核心技术组件。
“腾讯让TEG独立于业务体系的最大作用之一，是通过掌控其他事业群的核心技术命脉，给他们拴上一个镣铐，相当于一种变相的卡脖子。”业内人分析道。
不同于华为军团的彻底、腾讯TEG的折中，京东在技术这件事上，走过了一段颇为摇摆的曲折之路。
京东以电商业务起家，是先有业务，再招人做技术，成立后很长一段时间里，都将技术定位于业务的辅助，重视程度有限。
据《决战618—探秘京东技术取胜之道》一书，2008年京东618正式推出的第一年，京东备战的技术人员仍是个位数。
此后，随着业务增长，到2014年上市后，京东的业务翻了一万倍。这时候就遇到了棘手的问题，大促销的时候容易出现宕机之类的问题，当时在电商领域非常普遍，需要解决。
刘强东及京东内部在公司上市前夕，对技术定位产生了动摇，他们愈发感到京东需要一个强大的IT部和CTO，聚集业内顶尖的工程和研究专家，让技术成为业务的开拓者，去反向推动公司实现跨越式发展。
其次，对于谋求上市的京东来说，一家科技公司的估值空间显然要大于零售公司，弱化零售属性，强化科技色彩，更能讨好资本市场。
在IT部的建设上，京东的第一个动作就是找一位杰出的CTO。
京东历史上，只有过两任CTO。
2012年，首任CTO来自Oracle的王亚卿，但王待的时间不长，一年后就挂冠而去。
王亚卿离开后，刘强东没有扶正从2007年起就跟着他一起闯荡的技术副总裁李大学。李大学唯一的问题是，没有光鲜的特别是在大公司工作的履历，也就是没有刘强东要的面子，但里子李大学很强，于是李大学就顶着技术副总裁的title干着CTO的事情。
2014年京东上市后，李大学向刘强东提出退休。而就在此时，雅虎裁撤在中国的全球研发中心，京东就此盯上了原雅虎全球副总裁、雅虎北京全球研发中心创始人兼总裁张晨。
有说法是京东最开始是只想要张晨个人，但当时追逐张晨的不只京东一家，加上京东刚上市财大气粗，因此，也就答应了张晨带团队过来的要求。简单说，京东最开始追逐张晨，更多是出于面子的需求，而后才有里子的考虑。
张晨
2015年3月，张晨先是担任京东集团高级副总裁，负责京东商城技术研发体系工作，半年后被任命为CTO，开始对技术部门大刀阔斧地改革。在他的主导下，京东得以把技术部门从业务部门剥离出来，成为一个单独的技术大体系。
该体系主要包括两部分：一是核心技术研发团队，包括云、大数据、AI等技术团队；二是应用技术研发团队，主要服务于京东商城业务。两大团队直接从属于CTO大系统。
张晨上任后的一系列战略，让外界看到了京东在技术上的决心，不仅吸引来了诸多工程大牛，更是在2018年前后，成功引入了周伯文等10多位知名人工智能科学家。据消息人士透露，京东在2015-2019年给顶尖技术人才开出的薪资，远高于BAT。
集齐以张晨为代表的工程团队和周伯文为代表的研究团队，刘强东期望京东可以由此建立起一个强大的独立IT部，实现从“技术辅助业务”到“技术驱动业务”的蜕变。
然而，这些动辄千万年薪的工程大牛和科学家的到来，并没给京东带来实质性的业务提升，数十亿计的投入收益乏善可陈。
对此京东内部进行了深度诊断，得到的结论是：京东这十几年来，技术跟着业务走的开发模式，致使IT架构比较混乱；其次，过往一线工程师的水平总体较差，堆积的大量代码如同屎山粪山。而这些都是历史遗留问题和编程基本功，不是技术大牛们能直接解决的问题。
很显然，让这些重金请来的科学家直接到业务一线去提高研发水平，并不现实，但放着这些科学家们让他们只是发论文、参加学术会议也不是事情。
走到这一步，京东的“强大的IT部美梦”其实已开始动摇，随后便开启了一系列组织架构大调整，那一时期，张晨等工程派领导者相继离职，而科学家们全部划入京东科技，主做对外赋能，与京东的原有业务离得越来越远。
现在的京东似乎又回到了老路，于他们而言，技术更适合生长在业务上，但难以为之开疆拓土。
在雷峰网看来，企业对IT部门的调整大致有两大方向，一是向内收缩的防守型，二是向外扩展的进攻型。前者是从各业务部抽出技术人员，建立集中的IT部，扮演类似技术中台的角色；后者是将IT部人员下放到前端各业务部门，砍掉中间层，增强业务敏捷性。
就国内而言，很多互联网企业都是以业务起家，创始初期走的都是技术建在业务上。
当产品成熟稳定后，往往会通过建立集中的IT部来进行统一管理，为下一步发展打技术基础；而一旦体量到了大而难倒时，又会肢解掉IT部，把其分散在需要迅速迭代的业务线上。当业务线变得庞大强势时，集团又会通过收编IT部，来削弱“诸侯”的势力，巩固权力……
“建”还是“砍”，关键在于对市场和时机的判断，这也是一切组织调整的原点。
但反过来讲，收权后虽然可以避免各业务部拥兵自重，但一个大一统的IT部也会造就更大的官僚系统，而授权后也可能会因为重复建设而加重成本浪费。这些都加剧企业组织调整成为一个受多重因素作用、因时因势的动态复杂过程。
也正因如此，企业们才不得不在收权和放权、裁撤与新建、短期效果与新问题之间一次次地反复折腾，而难以给出一个一概而论的确定性答案。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
