职能型组织向敏捷型组织的演进路径

2023-07-27 08:00:00
翰德恩咨询
原创
340
摘要:越来越多的职能型组织认识到了现有组织结构低效、对外界变化响应迟钝 及遏制创新的种种弊端,希望能够重组,向敏捷型组织转型。但是,打破现有的组织结构并非易事。本章介绍传统的职能型组织向敏捷型组织升级的路径。
越来越多的职能型组织认识到了现有组织结构低效、对外界变化响应迟钝 及遏制创新的种种弊端,希望能够重组,向敏捷型组织转型。但是,打破现有的组织结构并非易事。今天介绍传统的职能型组织向敏捷型组织升级的路径。

1.敏捷团队的组建方式

职能型组织组建为敏捷团队的方式有两种。一种是颠覆重组,即颠覆现 有的职能部门,按照敏捷团队划分业务单元,各个实体的敏捷团队负责业务 目标端到端的实施(见图1)。


图1 颠覆重组方式

另一种是创新孵化型,公司对整体组织结构不做调整,而是决策投资一些创新项目,从各个职能部门抽调人员组建虚拟敏捷团队。项目中途取消或者正常结束后,项目成员回归到原职能部门(见图2)。


图2 虚拟敏捷团队

2.颠覆重组

企业要及时感知、洞察市场的变化,迅速行动,就必须在组织结构上将重心下移,将权、责、利向一线业务单元倾斜,让驱动企业发展的发动机从领导者和总部变为一线各个业务单元。这需要从 3 个方面开展。

( 1 )将原有组织进一步裂变、整合。将大型组织拆分成能够覆盖客户端到端价值链的业务单元,每个业务单元都在一定程度上获得独立发展业务的授权,从而成为增长的永动机。同时,这些业务单元互相协同,作为一个个节点再黏合成网状。有企业的资源平台做支撑,整个组织的运作以市场需求为牵引力,形成市场呼唤一线、一线呼唤后方的联动效应。

( 2 )去除中间层级,缩短市场的反馈链和执行链。加强执行力,防止决策信息在层层下达中衰减。

(3)授权一线业务单元更大的权力。因为一线是最贴近市场,也往往是 最能产生增长活力的地方。企业总部需要推进各个业务单元的知识用于经 营共享,打造统一的资源平台等。对于前线的业务单元而言,总部就是服务平台。

某金融企业在数字化战略转型的背景下,首先,从零售业务条线开始对 组织结构进行了重组(见图3),成立了3 个一线业务单元,它们均是面向客 户的客群经营单元—惠农业务经营单元、大众客群经营单元、私行客群经 营单元。其中,大众客群经营单元专注于开拓新客户,并服务好在本行存款 量低于百万元的客户,以实现中低端客户的留存和增长;私行客群经营单元 专注于发展本行客户成为私行客户,并服务好现有的私行客户以实现高端客 户留存和增长;惠农业务经营单元专注于经营发展乡、村、镇的客户。这3个经营单元共同的职责有:设计客群营销活动,协助分、支行开展营销活动;


图3 颠覆重组的敏捷组织设计案例

改善客户旅程,以增加所有渠道的客户流量;提升客户在本金融机构的价值,创设客群专属的产品和服务等。

其次,构建了 3 个纵向的金融产品开发部—— 日常银行部、零售信贷部、 信用卡部。它们负责产品大类的总体业务开发和设计产品战略、开发并优化 公共产品、确定产品的价值主张者、对 3 个前台经营单元提供销售支持(产 品手册、产品信息、套餐和条款条件等)。

再次,构建了横向的赋能平台——渠道管理部、产品支持部、数据银行部。它们端到端地负责渠道、产品、大数据相关系统的公共部分的开发、更新和维护;为客群经营单元提供支持,如提供开发工具、交付标准、公共平台和大数据洞见等。

在开展业务的过程中,一方面,横向的客群经营单元、纵向的金融产品开发部,以及赋能平台部各有分工又密切配合。客群经营单元深入客户捕捉市场机会,诞生金融创新产品或营销活动的创意,利用本单元内部自身的业务和技术部门人力资源构建 MVP ,经客户验证创意通过后,向金融产品开发部提交正式的产品需求,在此过程中,借助赋能平台提供的大数据分析进行产品决策。在产品发布后,借助渠道管理部提供的渠道资源将产品通过各个渠道推广出去。另一方面,赋能平台和金融产品开发部以服务于 3 个客群经营单元为宗旨,以最短的时间响应他们的需求,从而达成整个零售条线的业务目标。

3个客群经营单元和金融产品开发部内部,又划分为多个敏捷团队。以大众客群经营单元为例,整个经营单元根据客户群体的类型进一步划分为多个敏捷团队,如图4所示,每个敏捷团队负责其所经营的一类客群的业绩增长和客户留存。每个敏捷团队有两种专职人员,分别是市场营销师和业务分析师。市场营销师负责策划营销活动,以及分析大数据平台提供的运营数据以辅助其精准营销;业务分析师负责对所经营的客群进行市场分析、行业 动态观察、竞品研究并策划创新产品。

每个敏捷团队有两种兼职共享人员,分别是设计师和 IT 工程师,他们 服务于本经营单元的所有敏捷团队。当敏捷团队的创新产品、营销方案需要 UI/UE 设计的时候,由设计师来制作;当敏捷团队创设的新产品需要 IT 开发 的时候,或者营销活动需要数据埋点、小程序等技术开发的时候,由 IT 工程 师来开发。理想的情况下,每个敏捷团队都配有专职的设计师和 IT 工程师, 但是,现实中往往不是所有的团队在所有的时候都有设计或技术开发工作, 因此在整个经营单元范围内共享这两种职能足以满足需要。


图4 大众客群经营单元内的敏捷团队

此外,每个经营单元任命一位业务首领,负责整个经营单元的愿景制 定,带领各敏捷团队达成业务目标。每个经营单元有一位或多位(取决于经 营单元的大小) 专职的敏捷教练,以培育整个经营单元的敏捷思维和敏捷工作方式。

其他两个客群经营单元和金融产品开发部以类似的方式组建,只是敏捷团队职能人员不完全相同,但是其构成原则都符合颠覆重组的原则。

3.创新孵化型

颠覆现有组织结构对企业来说无异于做大手术,需要高层领导者具备强大的勇气和决心,在现实中也会面临以下困难。


  • 对变革的抵制。各个职能型部门的主管忧心忡忡,害怕自己的职位 不保,对重组产生心理抵制,因而在行动上不予配合。
  • 系统架构耦合度高,导致团队难以拆分。根据康威定律 a ,什么样 的组织结构产生什么样的沟通方式,而这种沟通方式又决定了产品的架构。因此,职能型组织结构下开发的产品,其系统架构耦合度往往比较高。当组织想拆分成互相独立的团队时,由于系统的架构难以拆分出松耦合、相互独立的模块,导致拆分出的团队仍旧互相依赖。
  • 拆分出小团队后会出现人才不足的情况。组建覆盖全价值链的团队,意味着将同时服务于多个产品或业务的专业人才重新分配,成为全心全意为某一个产品或业务工作的全职人员,会不可避免地出现专业人才不足的情况。


此外,很多业务在探索初期的前途并不明朗,企业无法判断是否值得长期投资,在此情况下过早地调整组织结构、成立固定的敏捷团队反而是一种浪费。在无法进行大规模的组织改造,或业务模式较新的情况下,可以建立创新孵化机制,企业内部成立投资决策委员会,定期对代表公司战略方向的创新孵化项目进行投资决策。

创新孵化项目可以来自任何部门、任何人的提议。投资决策委员会决定投资创新孵化项目后,从各个职能部门抽调人员组 建敏捷团队来运作项目,如图 5所示,根据项目的需要,敏捷团队的成员可能来自业务部门的前台和中后台各相关部门。同时,对于占公司主体的 成熟业务,公司仍旧保留传统的面向客户的前台和提供支撑的中后台职能部 门,其组织架构、运营方式和组织管理方式保持不变。


图5 职能型组织里的创新孵化项目

国外某个具有百年历史的汽车企业下属金融子公司面对互联网汽车交易 平台的冲击以及中国市场同行竞争的压力,成立了创新项目委员会,由 CEO 亲自带领。该创新项目委员会按月度对创新项目提案进行评议,挑选符合公 司在中国市场发展战略的创新项目。在一年时间内,该公司评议了上百个创 新项目,审批投资 10 个创新项目,其中 2 个项目最终发展为公司的重点业 务, 3 个项目发展为常规业务流程优化项目或数字化建设项目,其他 5 个项 目中途未通过 MVP 验证(进行了转型或中途取消)。在创新孵化项目成立之 初,敏捷团队成员不都是全职在该项目中工作,只有核心骨干全职工作,其 他成员部分时间投入创新项目,所有成员仍旧归属于其所属的职能部门。

当创新项目经过 MVP 阶段后达到了产品与市场适配,证实该创 新方向值得长期投资时,投资委员会再决定将敏捷团队成员固定,长期为新业务服务。若创新孵化项目在概念阶段或 MVP 阶段验证失败,投资委员会 需要做出决策——是转变创新方向还是放弃继续投资。若投资委员会决定不 再继续投资,则该敏捷团队解散,每个团队成员回到各自原有的职能部门; 若投资委员会决定转变创新方向,则根据新的方向重新审视团队成员需要从 哪些职能部门抽调。

公司对于每个创新孵化项目均采取此机制,因此,在此模式下,支撑公司传统成熟业务的前台部门、中后台职能部门和支撑创新业务的敏捷团队并存。这种组织方式能够让企业快速抓住市场机会、灵活响应,同时又不会使企业内部由于组织结构大面积调整而伤筋动骨,也不会产生将专职人力资源集中在一个敏捷团队或业务单元中所带来的潜在浪费。从该企业运行的实际效果来看,从职能部门进入敏捷团队的成员都热爱团队的工作内容,因为敏捷团队拓宽了其在原有职能部门的技能范围。

还有很多企业虽然没有建立创新项目委员会及创新项目评议决策的流程,但是为了拥抱市场创新机会并优化公司内部,针对那些跨多个职能部门的项目也组建了敏捷团队,从不同职能部门抽调人员,树立共同的项目目标,在流程上采用迭代式交付与运营方法执行项目,从而实现了打破各职能部门的壁垒,加速跨部门的协同效率的目的。这种以跨部门项目为单位组建的敏捷团队,在本书也归类为创新孵化型。

4.技术与业务协同的阵型

随着数字化转型的深入,越来越多的传统企业成立了数字科技部门或数字化中心,承担全公司数字化系统的建设,包括 HR、财务、工厂生产、销售、采购、公司电商平台等,但是数字科技部门与需求的提出部门(即各个业务部门) 矛盾不断。比如,业务方经常抱怨数字科技部门效率低、产品质量差;数字科技部门抱怨业务方需求不清晰、变化多,没有价值排序等。虽然公司希望转型为敏捷型组织让业务与数字科技人员密切协同,但是并不可 行,原因有两方面:一方面,众多业务部门在数字科技部门之外,甚至在有 些大型集团公司里,众多的业务部门与数字科技部门隶属于不同的子公司; 另一方面,与数字科技部门对接需求的业务人员只占整个业务部门的一小部 分,对业务部门来说,建设数字化系统以满足业务需求只是其部门的一小部 分工作(见图6)。


图6 常见的数字科技部与业务部门的关系

对于这种情况,可以尝试将业务方的数字化系统接口人与数字科技部门的敏捷团队融合。具体来说有以下两种融合阵型。

1.融合阵型 1 :联合办公,业务方融入数字科技部门的敏捷流程

业务方融入数字科技部门的敏捷流程其阵型如图7所示。业务方与数字科技部门的产品负责人密切协同,联合办公。方式有两种:一种是业务方将本部门对接数字化系统的业务人员派驻到数字科技部门,每周以一定的频次与数字科技部门的敏捷团队一起办公,不仅便于业务人员更清晰地了解数字化系统的交付进展,也便于业务人员向数字科技部门的敏捷团队传授业务知识,确保团队理解业务场景和客户需求;另一种是数字科技部门派驻产品负责人到业务部门,每周以一定的频次与业务人员一起办公,并与业务人员一起参加客户调研和市场研究,从而增进产品负责人对业务知识和客户场景的理解,以便产品负责人向科技人员传递正确的需求。


图7 业务方融入数字科技部门的敏捷流程

数字科技部门的产品负责人全权负责与业务方协作,将业务需求和 客户需求转化为产品的解决方案。


  • 业务方按照数字科技部门的敏捷迭代周期提供需求输入。比如,若 敏捷团队的迭代周期为双周,则业务方以双周为周期准备好需求输入,尽量避免在迭代过程中插入新需求或变更需求。
  • 业务方按照数字科技部门的数字化产品上线周期开展用户验收测试。 比如,若敏捷团队的产品增量上线周期为每周,则业务方在上线前 验收产品增量,批准发布。


2.融合阵型 2:调整团队结构,将业务人员与数字科技人员组成一个敏捷团队调整团队结构有两种方式。一种是业务部门派驻业务人员到数字科技部 门,与数字科技人员一起构成完整的敏捷团队,业务人员作为敏捷团队的产品负责人,对数字化系统有产品决策权,并能够对敏捷团队交付的产品增量 进行日常验收,如图8所示。


图8 业务部门派驻产品负责人到数字科技部门

另一种是数字科技部门派驻工程师到业务部门,作为业务部门敏捷团队 的一部分,如图9所示,数字化系统的交付作为业务团队管理的一项工 作,归敏捷团队统一管理。 

不论是哪种融合阵型,都是在无法改变业务部门和数字科技部门分割为 两个部门甚至是两家子公司的现实下,努力将双方凝聚在一起,形成一个敏 捷团队,实现快速响应业务机会、快速交付价值的目的。


图9 数字科技部分派驻工程师到业务部门

5.小结

传统的职能型组织诞生于工业时代。在商业环境确定的情况下,以追求执行效率为最高目标,职能型组织结构正好符合这一目标。但是在当今的数智时代,高度不确定的商业环境成为每个企业面临的常态,单纯的职能型组织无法满足组织对市场的迅速响应。

业界已经诞生了多种敏捷型组织形态。作者在前人研究的基础上,提出了业务敏捷组织的设计模型,使组织具备更高的适应力。

然而,对于企业来说,打破现有的职能型组织结构并非易事,需要知道如何从传统的职能型组织向敏捷型组织演进,本章提供了演进路径供组织参考。


联系我们
联系人: 田老师
电话: +86 135 5227 9573
Email: clientservice@hardenx.cn
地址: 北京市朝阳区福码大厦B座17层1705

加微领1G资料