转载

传统企业大规模敏捷转型的先决条件是什么？

启示

很多 传统企业 都在尝试 敏捷转型 ，但往往无法充分挖掘出 敏捷模式 的全部潜力，究其原因，这些企业尚不具备大规模推广敏捷模式的前提条件。

我们发现，成功企业往往会从调整运营模式入手，以促进敏捷模式的大规模推广。这些调整主要集中在4方面：1）调整组织架构，更加注重产品；2）加强业务部门与IT部门间的互动；3）重新定义业务部门与IT部门内的不同角色；4）调整预算和规划模型。

只有先对运营模式进行大范围调整、有序推进变革，企业才能充分释放敏捷模式潜力，从而超越竞争对手、驾驭新兴技术、满足客户预期。

在敏捷模式下，许多数字化企业能更高效、更可靠地交付新产品。通过大范围推广敏捷模式，数字化巨头得以迅速设计和打造产品的新功能，让客户试用，并通过快速迭代对性能进行微调和更新。

相比之下，很多线上和线下相结合的传统企业并未大规模启用敏捷模式。例如，很多银行都设有数字化团队，负责移动app和网站开发。但小到办公位置，大到战略制定，他们都游走于企业其他部门之外，甚至独立于IT部门的其他团队。

研究表明：许多传统企业在相互独立的试点项目中尝试推广敏捷模式。这虽大有裨益，但只有不到20%的企业认为，已将敏捷模式推广到全局层面1。而据麦肯锡观察，大规模推广敏捷模式最多可使创新速度提高80%。

传统企业未能大规模推广敏捷模式，这一现象背后有诸多原因。但在麦肯锡看来，传统企业转型的最大障碍，还在于其现有运营模式和组织架构。

几乎所有传统企业的软件和产品开发流程都很分散、复杂。很多时候，连开发一个新的网站功能都会牵扯多个团队，但团队本身又各自为政，导致大量的重复性工作。比如，甲队负责前端应用，乙队负责相关服务器和数据库的更新，丙队则负责协调甲乙两队的工作。此外，IT与业务部门的支持性业务流程（包括预算、规划和外包），以及职位和职责设置，都还在沿用原有的瀑布式方法2。

因此，即便小规模试点项目再成功，企业如不做结构性调整，也很难将敏捷模式推广到组织层面。

麦肯锡帮助许多组织在IT部门与业务团队中普及了敏捷模式。在此基础上，麦肯锡最近又深度剖析了13个大规模推广敏捷模式的传统组织，这些企业都调整了运营模式，以促进敏捷模式的大规模推广。这些调整主要集中在4个方面：1）调整组织架构，更加注重产品；2）加强业务部门与IT部门间的互动；3）重新定义业务部门与IT部门内的不同角色；4）调整预算和规划模型（见图）。

传统企业大规模敏捷转型的先决条件是什么？

变革之路上的先行者已有了不小的收获。例如，某公司已将其运营模式由项目导向转变为产品导向。在客户引导阶段，该公司会依据客户整体体验而非单个应用所需的IT技术，来部署人才与IT资源。该企业过去一年仅发布4种新功能，而进行调整后，一个月内就能上线4种新功能。企业若能认真思索如何循序渐进地转变运营模式，就将大大提升向敏捷模式转型的成功几率。

扩大敏捷实践规模

敏捷模式的益处已广为人知。在该模式下，IT部门和产品开发团队会与业务部门一起打造产品与服务，这会避免瀑布开发模式所产生的敷衍了事与各自为政的问题。团队可以先行设计最小可行产品（MVP），并不断测试和改进，数日或数周就能交付新产品，而不用再等好几年。麦肯锡观察走在敏捷模式最前沿的公司发现，只要企业循序渐进地调整运营模式和组织架构，IT与业务人员就能在更广的层面上合作，也能更快地协作开发产品。在此过程中，企业需要遵循4条原则：

1. 组织架构以产品为导向

传统企业往往会根据应用或项目调配IT资源，导致整个开发过程过于分散。正确的做法是围绕产品来分配IT资源，集业务领导、开发人员和组织内其他成员之力，组成稳定的端到端团队，专注于特定业务成果的交付。这种结构会颠覆传统的项目制，也不再需要“项目管理办公室”。

在敏捷模式已得到大规模推广的环境中，产品不再只是某种商品，而是多种服务（如薪资管理服务）、多个客户体验（如线上购物旅程的方方面面）、多支产品团队共享的IT系统（如即时生成报价的定价软件）之和。因此，业务部门与IT部门的领导者必须重新定义交付内容。这一步完成后，企业必须指定一支或几支敏捷团队，由他们负责产品的开发和维护。团队通常包含开发人员、测试人员和敏捷组长等，他们可以从专家团队那里获取额外支持，比如有关安全、用户体验和企业IT架构等方面的帮助。

通过调整组织架构，某大型医疗器械制造商大幅缩短了产品上市时间。由于产品之间依赖度很高，原先发布一款新产品或一个新功能，可能会在业务部门与技术部门间折腾20个来回。领导层发现这点后，意识到仅在单一业务团队或技术团队采用敏捷模式远远不够。2015年，该企业调整了原有的产品开发权限，使得业务部门的敏捷组长能绕开组织层级，直接向敏捷团队下达指令。经过这番调整，该企业成功缩短了产品上市时间。结构调整还促成了新团体的兴起。这些基于特定职能或业务主题的团体（或称“行会”）是敏捷组织内的重要平台，能让团队成员彼此交流知识，促进团队与职能部门间的协作，持续推动绩效改善。

2.业务部门与IT部门加强互动

想要大规模推广敏捷模式，企业就要打破业务部门与IT部门之间以及内部各自为政的状态。事实上，多数企业都长期深受此问题困扰。但其实，公司可以指定具备专业知识和权威的优秀产品负责人为敏捷组长，让他们与IT人员合作，为产品功能做优先级排序，从而实现更加高效、紧密的合作。

在多数传统企业，来自业务部门的敏捷组长只会偶尔参与软件开发，按需提供帮助。为了弥补这一人手不够的情况，IT部门往往会指定一名本部门员工作为敏捷组长。这种安排在短期内或许有效，但长期来看只会起阻碍作用。由于组织架构的限制，IT部门的“敏捷组长”很难近距离接触用户，并且也没有决策的权限或威望。由此造成的方向不明、优先次序不清晰和问责制度缺失，会导致敏捷开发停滞不前，而团队也将面临大量的返工与浪费。

相比之下，优秀的敏捷组长对产品有着深刻的理解，他们能接触客户、了解客户，并可全权作出决策。高效的决策流程能够消除开发阶段的瓶颈并提高生产力。

某家SaaS（软件即服务）供应商，曾面临产品难以及时交付的问题。当时，决策流程明显滞后，IT部门与业务部门之间也缺乏清晰的沟通路径。2014年，公司采用了三层架构：一名敏捷部门领导管理整个产品业务；一名敏捷项目经理管理其中一条产品线；数名敏捷组长与Scrum团队分工协作。新结构加强了IT部门与业务部门之间的互动，沟通路径也变得更加清晰。公司决策速度加快，各产品开发团队内部以及彼此之间也沟通顺畅、合作协调。结构调整后，公司每季度都能推出新产品，有时还会逐月推出。而此前，公司每年只能推出一到两款新产品。

3.重新定义管理人员的角色与责任

在麦肯锡调查的企业中，约有一半都调整了管理人员的角色与责任，以凸显敏捷模式的优势。在瀑布模式下，项目经理需要协调各应用开发团队和数据库团队的一系列任务。而在敏捷模式下，任务的数量（以及对协调的需求）被降至最低，仅存的任务会由权责明确的敏捷组长或敏捷团队自行处理。同样，此前由项目经理负责的流程管理任务（如发现和解决依赖问题、任务分配等），则会由专注于产品的、自组织的敏捷团队负责。

非洲一家大型银行就调整了部分管理角色的沟通路径和职责，以大规模推广敏捷模式。之前，银行的软件开发团队需要与数名技术主管合作才能了解架构师对技术规格的要求。采用了敏捷模式后，技术主管的职责被架空，该岗位不复存在。开发人员可以直接与架构师和敏捷组长对话，因此能更好地理解用户需求，并针对这些需求开发软件。当然，直线经理仍承担重要职责，如提供职业发展方面的支持，以及进行相关的专业指导。但他们的职责经过了重新定义，并在组织内部进行了清晰传达。这样，团队成员便能知道彼此的职责，以及特定情况下应该向谁求助。

根据麦肯锡的观察，成功推广了敏捷模式的企业都高度透明。在决策权限的划定上，他们的指导原则十分明确。团队拥有适度的决策权，既能承担一定的责任，又不会因权限过大而闯祸。

4.调整预算和规划模型

IT部门通常会逐年制定预算和工作计划，这通常会导致两种结果：1）各个技术项目间存在矛盾和冲突；2）大量的返工和浪费。

对想要大规模推广敏捷模式的组织而言，这种方法简直是个诅咒。有些企业打破了这种模式，总预算仍逐年制定，但会逐月或逐季度回顾工作路线图和计划，并持续对各项目的优先次序进行调整。

欧洲一家大型保险公司调整了预算制定流程，为每个产品领域都分配了一定比例的年度预算，供敏捷领导者使用，同时保留部分预算作为必要的维护费用。预算权责主要有三方面：1）业务和IT管理人员组成开发委员会，每月开会决定各个项目实施与否；2）敏捷领导者负责合理分配预算（例如出现新商机时快速决策），并且不定期开会，随时调整预算的分配；3）敏捷组长则负责确保软件开发任务的及时执行，管理维护任务和积压任务，并持续进行评估。工作方法的转变使得公司预算流程的灵活性得到提升，响应能力也大幅改善。

了解到敏捷模式的精髓后，部分企业开始探索一种“风投式”的预算模型：先为最小可行产品提供初始资金，基于用户反馈改进后，再重新投放市场，后续资金支持则视MVP的市场表现而定。

在这种模式下，MVP会受到密切监控，而开发任务的优先次序也会不断调整，因此项目失败的风险会大大降低。这样，产品经理的工作会变得更加透明，无用功也会减少，企业也更容易终止那些没有前景的项目。

选择正确的实施方法

调整运营模式是一项浩大的工程。在向新模式转型的过程中，会有很多颠覆性挑战需要克服。一如任何大规模变革管理举措，这种转型需要全体员工的长期投入。在调查中，我们发现企业有几种改变运营模式的方法。

有些企业采用了敏捷试验室，即单独设立一个部门，作为贯彻敏捷模式的专项试点，试验成功后再进行大规模推广。若公司高层愿意给予的支持有限，且需要在短时间内看到变革的必要性，那采取这种方法无可厚非。但很多时候，这种敏捷试验室会始终游离在外，难以为整个企业带来变革。

有些企业则过于激进，企图一次性改造所有职能部门和业务部门，实现敏捷转型和流程提速。在这种模式下，成功的前提是高层领导自始至终都全力以赴，但能做到这一点的企业已是凤毛麟角。

上述两种做法都较为极端。其实，逐波推进才是大规模推动敏捷变革的最好方法。在这种模式下，各团队会有序分批向敏捷模式进发，在每一批次的末尾，管理者提出新的运营要求。例如，一家大型技术解决方案供应商曾需要快速提升数字化能力。由于项目的规模、复杂程度和数量都在与日俱增，IT部门在产品交付上遇到了很大困难。

该公司将产品开发团队分批改造为敏捷团队：第一批培训和部署5支团队，第二批则包括近20支。每批团队成功转型后，公司都会收集相关反馈意见，编制和修订培训资料，以供下一批团队使用。此外，公司还委派了多名敏捷教练来指导团队。

敏捷转型开展到第6个月时，该公司采用了产品导向型组织架构，让业务单元领导者、开发人员、工程师及IT人员组成一个个“部落”。几个月过后，公司又开始专注于IT部门与业务部门之间的互动。公司调整了运营模式，以增强产品开发团队与IT运维团队的合作，真正进入DevOps模式。这些调整极大提升了产品上市速度，残次品数量和需要返工的情况也显著减少。

一些公司只在小范围内推广了敏捷模式，初尝了甜头。他们或许认为，应该紧守眼前的好处，避免大规模转型的风险。然而，止步不前才是数字化商业世界中最大的风险。若想紧跟竞争对手、新兴技术和客户预期，企业必须在各职能部门和业务部门大规模推广敏捷模式，勇于调整组织架构的方方面面，为敏捷转型的蓬勃开展提供所需的空间和支持。

1 《第10次“敏捷现状”年度调查》（Tenth annual State of Agile survey），VersionOne，2016年，versionone.com。

2 瀑布式产品开发并非同步，团队必须严格依序完成多个流程阶段。

作者：

Santiago Comella-Dorda是麦肯锡全球董事合伙人，常驻波士顿办公室；

Swati Lohiya是麦肯锡专家，常驻伦敦分公司；

Gerard Speksnijder是麦肯锡全球董事合伙人，常驻阿姆斯特丹办公室。

原文 http://www.ceconline.com/strategy/ma/8800102793/fbe1df9701/

正文到此结束