于软件开发领域而言，敏捷已经被广泛认可为一个行之有效的应对快速交付和不确定性的指导方法，并有一系列相对成熟的模型和框架。而企业更为需要的企业敏捷和业务敏捷则仍在探索阶段。敏捷吸引软件开发工作者的原因，是它打破传统开发常规，用不同的思维找到更好的方法，取得更好的结果。同样的，如果要业务敏捷，就要探寻业务部门所需要突破的常规。本文将与诸君分享三类业务部门突破常规的故事。
在这个技术突飞猛进、环境瞬息万变的时代，能够快速响应变化并做出适当的调整，是关系到企业生死的基本能力。企业（enterprise）需要敏捷，业务（business）必须敏捷。但很不幸的是，现行的商业和管理理论和实践普遍相对落后，连彼得·德鲁克都曾感叹：“我们称之为管理的东西反而使人们做事更困难”，更不用说支持快速响应变化。请问各位，您所在组织的管理和运作模式是否支持快速实现客户需求，是否支持快速响应变化？有哪些规则妨碍你们的工作？要迈向更好的运作模式，首先必须打破那些不必要的常规。
探寻更有效的运作模式并非容易的事。幸运的是，软件群体已迎来新希望。交付周期缩短的压力下，软件团队已经成功的实践新的工作方式，我们将之统称为“敏捷软件开发”。敏捷团队能够高效有效地协作，产出客户满意的软件产品。敏捷团队惊人的效率和激情，对业务工作者是一种鼓舞。组织领导希望业务人员有同样的敏捷能力和效果。
但是，业务敏捷（business agility）并没有明确的定义。敏捷联盟（Agile Alliance）将业务敏捷定义为“业务能感知内部、外部的变化，并及时回应以便于为客户提供价值。业务敏捷不是一种具体方法，甚至不是一个整体框架，它是形容一个组织怎样在成长思维下运作，而这种思维很类似于敏捷软件开发群体形容的敏捷思维。”敏捷联盟进一步表示，没有固定的敏捷实践、角色、或者周期。因此，业务敏捷的组成可说是还处于探索阶段。因此，业务敏捷是什么，它的目标是什么，它的广度和深度是什么，还需要每一个组织自己去定义。目前，没有任何参考的模型，各组织需要自行探索，自己检验。
在敏捷软件开发方法体系，业界有不少通用的模型，比如Scrum、XP等，来指导敏捷开发的实施。以上模型以软件团队作为出发点。业务敏捷的出发点呢？它从哪里开始？业务部门的领域不同，需要的敏捷模式则不同。比方说：销售部门的敏捷可能就跟财务部的敏捷完全不同，采购部的敏捷和人力资源部的敏捷也应该不同。同样的，敏捷对于高层管理者和业务部门领导来说也有不同的意义和侧重点。
我们或许可以考虑让这些业务部门尝试成熟的Scrum框架，让这些部门有迭代运作的概念。这或许有用，但我觉得不能解决业务的根本问题。原因很简单，业务部门都有他们惯用的例行工作分配和跟踪机制。在这些例行会议当中，他们会讨论与跟踪问题，并商定改进措施。所以，如果跟业务人员只是谈论“一般”的敏捷迭代做法，持续改进，他们就可能会感觉“我们都知道，已经在做了，没什么新鲜的”。
敏捷吸引软件开发工作者的原因，是它打破传统开发常规，用不同的思维找到更好的方法，取得更好的结果。敏捷宣言中的四个价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
右边就是常规，左边就是崭新的思维模式。同样的，如果要业务敏捷，就要探寻业务部门所需要突破的常规。
敏捷宣言也提出“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观。”同样的，我将分享我的一些个人在业务敏捷经验和体会，供大家讨论，我把这些经历分为三类：
-
业务与IT的敏捷
（Business and IT Agility）
-
客户参与的敏捷（Customer Engagement Agility）
-
业务自身的敏捷（Business Agility in Itself）
这三类经历都在说明，业务人员如何跳出他们存在的心态和思维，找到突破。
业务与IT的敏捷
谈到业务敏捷，很自然的就谈到业务部门和IT部门的合作。下面的场景相信大家都不陌生：业务和IT双方并不和谐，各自维护自己的利益，互相对抗。业务压需求，IT抵抗需求。其实，从企业整体目标的角度考虑，他们应该是相互合作的合作伙伴关系，没有高下之分。
这是很多企业里常见的做法：业务方希望以最低价格完成目标，所以跟许多供应商合作，让他们之间互相竞争价格。这些供应商，有些做开发，有些做所谓的“独立测试”，他们互相竞争报价。在极端情况下，一个业务部门有十几个供应商，分别负责开发、测试、用户体验等等不同的工作。在这种讨价还价，随时停止供应商服务的情况下，供应商怎么可能有热情和忠诚？有些业务部门不仅仅对供应商这样，甚至对公司内部IT的同事也一样。IT服务质量难免受损。
业务与IT的敏捷协作基础是互相尊重，互惠互利。我分享两段个人经历：
第一个经历
是我2014年的一个大型敏捷转型项目，包括供应商大概有好几千员工，该业务在一年后扩张至约万人。当时我们提供IT组织敏捷转型方案，并且辅导团队落地实施。正好我辅导的某个团队，业务代表和IT代表水火不容，一开口就吵，几乎不说话，关系很尴尬。
业务代表希望将70个左右的需求都要现实，但是IT方面抱怨说需求不明确，做不到。IT代表问我，到底他们哪一方合理，这让我左右为难，倾向哪一方都有损失。这时，我便问业务代表是否真的希望每一个想法（Idea）都实现，以及每一个想法当前的进展情况。
如我所料，那些想法的进度并不相同，有些想法就是想法，业务代表只是想与IT代表共同讨论。说到这里，IT代表才平下心情。我们便建立一个想法看板（Idea Kanban），附有清晰的标准定义和具体的排序规则。这形成业务方和IT双方的合作基础。这个运作方式受组织的认可，并且变成了其他业务团队的参考模型。
第二个经历更是难以忘记。业务代表想创造一个B2B电子商务平台，向欧洲和香港市场发展，有大量的业务需求。IT方面正手忙脚乱地实施落地，工作量特别大，不少加班情况。为了满足业务需求，IT部门有并行的版本开发。这意味着业务方必须参与验收测试（UAT），而同时也需要投入准备德国和香港的演示和销售工作，所以工作量也很繁重。总而言之，业务和IT双方都被压得喘不过气。
其实，对我来说，解决办法很明显：就是要聚焦，不要把精力分散。为了让香港客户演示的成功，应该把大部分精力集中在这里，不必要并行版本开发，反而应该舍弃一些已经计划发布的工作。我参加他们业务和IT的协作会议，并指出我的想法。业务方很果断的舍弃一个版本，并同意专注于演示的准备。取消一个并行版本之后，业务和IT突然感觉轻松多了，特别开心。为了纪念这次的决定，业务代表还提议在敏捷宣言前合影留念！
客户参与的敏捷
说到客户参与，我想把本文的重点放在线上和线下的“人为渠道”
（human channel）
方面。在目前提倡数字化背景下，组织提倡自动化和智能化，希望通过技术手段，更好的为客户服务。客户通过这些自动化智能化的渠道办理业务，不需要业务人员的参与，减少业务人员和客户通过移动或其他方式进行沟通。虽然，这将让客户更方便，但是在某种情况下，会失去跟客户人与人之间的接触机会。数字化和业务敏捷存在的意义就是让业务给客户更人性化的服务，如果要人性化，怎么能够完全没有人为的参与呢？所以，在本文当中，我分享两个相关经历。
在某家金融科技公司，客服人员每人每天有350次通话指标。其实，通话次数和通话质量是两回事。我便问他们是否有建立一些有意义的关系，解决他们的问题。这些一线客服人员便滔滔不绝的讲述他们与客户接触的感人故事：一名客户问客服夜间上哪里买药，另一名客户询问哪里能找到托儿服务、等等。
很明显，这些都是超出客服的工作范围。在他们分享经验时，我能感觉到他们的热情，他们助人为快乐之本的心态。我相信他们的客户也会特别感激。在这分享中，客服人员理解他们的意义不是为了达到冷冰冰的通话次数目标，而是有同理心的帮助客户。客服人员不是接电话或拨电话的机器，他们是一群具有影响力的大使，帮助组织建立人脉，建立口碑。当业务意识到这一点，就会有更强大、更有创新力的服务。如果你想要客服更人性化，你必须关注他们，鼓励他们呈现人性化的一面。这是敏捷的基础——以客户为中心，以人为本。
这个故事是我在某家银行的经历。作为一个每月领取人民币薪资的新加坡人，还要把工资汇到新加坡，这手续其实很麻烦。在银行风险政策的要求下，每次境外汇款都要亲自跑支行两趟去办理手续，对我这样一个差旅频繁的人来说，这是个很大的问题。不过与支行经理商量之后，商定一个稍微简单的办法，将两次亲自现场办理手续减为一次。支行的王经理不仅满足我作为客户时间上的要求，在自己的工作上取得成就，更交了新朋友。这是个体现出一线人员寻找流程创新和突破的很好例子。
一线员工不是推销产品、提供信息的渠道。他们是真正能够与客户
建
立关系的大使，所以他们应该赋予更多权利。但是，不少企业往往对他们就像对待机器一般，完全没有决策权，完全百分百的遵循过时和不完备的流程制度。以上两个案例体现了一线的突破。这就是所需要的业务敏捷。
业务自身的敏捷
业务敏捷的第三方面是业务自身的质量和管理方式。这跟客户、合作伙伴和IT没直接关系。这是业务自身的核心，通常与领导层有关。业务的决策和经营体现了领导者的意愿。领导做事的方式对业务敏捷有很大的影响，通常表现在细节上。
我在知识共享领域有一段有趣的经历。客户所在的业务有不同产品线，规模很大。领导层希望不同产品线分享知识，让员工互相学习，找到更好的解决方案。但是，业务的安全部门有责任保护机密。因此，两个部门产生了冲突——知识管理部希望分享，安全部门需要维护保密性。讨论之后，最终没有将知识分享的项目交给知识管理部，而交给安全部门负责，这样他们就需要改变保密政策。这显然是创造共同视野的好方法。
在另一个组织中，不同额度的采购需要不同的级别的审批权限，这在某种程度上是有道理的，但却给带来巨大的问题。一个项目当中所需采购工作，就需要获得不同级别的批准。较小的采购交给较低管理层的批准，而较大的采购则交给更高管理层的批准。结果，经理们看到的是完全不同的采购，而不是一个项目的所有主要采购。经过一次改善活动之后，让每个项目都由一个单独的人来批准重大的采购，而采购业务的合作使他可以批准指定项目相关的所有其他采购。这大大简化了审批过程，将审批周期从最多21天缩短到最多3天。
最后一个例子是一家有很多个不同子公司的业务，每一个子公司经营的业务都不同，成熟度也不同。于是，我们合作设计了一个共同的绩效框架，用于管理不同子公司。这个框架基于麦肯锡的三维度、基于业务驱动变量，它们适用于B2B、B2C和混合商业模型。过去，他们集中于金融指标，经过共同的努力，他们得到了更好的领先指标，能够追踪客户和商业伙伴的成长。为总公司和子公司之间提高了急需的可见性，优于以往不透明的方式。
敏捷即打破常规
如果你已经尝试过敏捷，你可能会在开始的几星期或者几个月内感到很新颖。但是，如果在这期间没有任何突破，没有任何思维的创新，没有打破常规，团队就很容易回到老样子。团队们可能说他们有Scrum活动，有一系列的“敏捷”仪式，但是，我的经验告诉我，如果只有表面上行动，没有根本上的改变，这是很难持续的。若要真正的敏捷，就必须更上一层楼，就必须有思维的突破和创新。敏捷软件开发如此，业务敏捷也如此。
各位业务敏捷实施者，你们有哪些最关键限制因素?这些因素背后的原则和政策是什么？你可以做出哪些改变？你可以克服这个限制吗？要付出什么代价？如果你袖手旁观，后果会怎样？ 我们追求的是管理层面的突破。这些突破，往往就是一个简单的决定，就向打开一扇门那么简单。但是打开门后，海阔天空。
今天，你有没有尝试打破常规？欢迎分享。
黄邦伟
ThoughtWorks商业洞见
[摘要]
企业的成功既需要数字化也需要敏捷化。数字化提供更好的用户体验，敏捷激发热情与创新。数字化和敏捷化是天生一对，不能只选其中一个。数字化、敏捷化如何评估？如何才能更加数字化、敏捷化？
人类的进化进入了一个新阶段。科技已成为我们日常生活中不可缺少的一部分， 大部分人离开科技就无法生活。不仅如此，我们对科技的需求还在日渐增长。你能想象一整天不用Wi-Fi、Facebook、Instagram、谷歌或智能手机吗？ 对大多数人来说，这肯定难以忍受吧。 我们需要来自各种网站、应用的即时回应。亚马逊、京东等公司已用“翌日送货”乃至“一小时内送货”（只要送货地址在范围之内）这样的服务宠坏了我们。我们需要吸引眼球、容易使用的界面，想我们所想、专为我们而创造的服务。
现在每一个公司都在寻求数字化转型。图1显示了2017年1月至本文写成期间，谷歌搜索“数字化转型”的趋势。很明显，大家对这个话题的兴趣在上涨。
图 1 谷歌搜索“数字化转型”（英文）的趋势
虽然技术是数字化中必不可少的一部分，但它并不是全部。数字化也需要转换商业模式、流程、文化和思维。非技术的部分可以用一个词来总结：敏捷。要适应客户不断变化的需求，就要保持敏捷。
图2显示了2017年1月至本文写成期间，谷歌搜索“敏捷转型”的趋势。可见，“敏捷转型”和“数字化转型”的搜索趋势都是在2014年开始上升的。
图2 谷歌搜索“敏捷转型”的趋势
数字化转型和敏捷转型有很强的关联。举例来说，亚马逊是数字化企业的领头羊，它本来只是一个电子商务网站，但现已成为市值两倍于沃尔玛的巨头。亚马逊没有把利润回报给股东，而是不断投资于创新，创造更好的客户服务。它是为客户而存在的。同时，亚马逊也是敏捷方面的领头羊。杰夫·贝佐斯提出的控制团队人数，以及他著名的“两个披萨”高效团队原则，都是在谈敏捷。
企业的成功既需要数字化也需要敏捷。数字化提供更好的用户体验，敏捷激发热情与创新。数字化和敏捷是天生一对。坦白来说，根本不能只选其中一个。
“数字化”和“敏捷”是动态的、没有终点的比赛
想要数字化转型的企业往往一开始就问什么是“数字化”。虽然对它的定义众说纷纭，但在一些方面存在共识——比如，“数字化是关乎客户的”。数字化的目的是改进客户体验，让他们在达成自己的目标时投入更少。你对客户的服务越好，来找你的客户就越多，这就是真理。
但是，数字化没有一个黄金准则。有一个手机应用，不一定就是数字化公司。其他公司也有他们的数字应用，但并没有因此领先。不过如果你的数字应用很烂，那你就不能算是数字化公司。“数字化”的最低标准是有的，但没有最高标准。
企业和科技都在不断进步，数字化企业的最低标准也在不断提升。不断会有公司打破常规，抬高标准。今日的巨头很可能明日就辉煌不再，如博德斯、柯达等等。企业也是有半衰期的，平均寿命是18年。如果五年来你的公司还在同一个行业，做同样的事情，方法完全不变，就要特别小心了——你需要“颠覆自己”，不然就会被他人颠覆。
沃伦·巴菲特在2015年警告大家小心企业衰退的三要素，告诫波克夏下一任CEO必须与傲慢、官僚主义和自满作战。即使是波克夏这样一家收入超过了新西兰GDP的公司，也要小心谨慎，更不用说其他公司了。对付这致命的“三要素”的方法是公开、透明、激情，这也都是敏捷的基础价值观。
“数字化”（Digital）是个形容词，不是名词。你不能指望数字化有个标准，静态不变。这是一场动态变化的、没有终点的比赛，赛道上有很多竞争者。你需要以竞争对手为基准，来自我衡量。你能做的，只是比他们“更加数字化”。
同理，敏捷也不是个名词，没有最敏捷，只有更敏捷。在这个数字化时代，更数字化、更敏捷的企业才是赢家，也只有赢家才可以生存。
那么，到底是什么需要更数字化、更敏捷？
如果数字化和敏捷的都是形容词，它们形容的名词是什么？这个问题很重要，因为它定义了数字化转型的大框架。在这个框架下，需要找到数字化最少、最不敏捷的地方，让它们更加数字化，更敏捷。名词是你希望数字化、敏捷化的个体或组织。这个组织可以是企业也可以是政府。
那么，是什么构成了组织？组织运作的部分都是什么？它们是渠道、职能部门、外部合作伙伴、雇员、技术和领导力（见图3）。
图3 数字化、敏捷化的领域
渠道
——渠道是组织与客户互动的渠道。渠道可以完全是数字化的，也可以物理与数字并存。好的渠道应该做到有用、有意义、知识丰富、无缝、统一、迅速。作为一个客户，我想与企业中那些了解组织也了解我，同时可以提供优质、迅速服务的人互动；我不想跟不同的人，还有讨厌的聊天机器人不断花时间去解释我的需求；我希望立即得到我想要的服务；我费的力气越少，我的感受就越好；不要让我费劲去想、花时间去等。
职能部门
——组织
中的各个职能部门齐心协力满足顾客的需要。有些可能在一线接待客户，有些可能在后台做不同的工作，有些可能负责管理与合规等等。不管怎样，他们的工作可以更加数字化、更加敏捷。他们的流程如何？采用什么步骤？可不可以省略或者自动化？有没有其他更简洁的方法达到同样效果？职能部门之间的合作能不能改进？职能部门能不能合并或重组，以精简流向客户的价值流？能不能给职能部门更大的权力去更好地服务客户？
合作伙伴
——在全球化的今天，没有企业能独立生存。企业需要与伙伴或供应商合作。企业拥有的是哪种关系？是一方需要不断与另一方协商、再协商才能达成合作的关系，还是互利共赢的关系？合作伙伴能否很容易地纳入其中？信息可以顺畅地跨组织分享，还是有很多交流摩擦？沟通不畅、合作不佳，相关的职能部门就需要花时间等待，最终损害的是客户体验。
员工
——有满意的员工才有满意的顾客。工作环境如何？工作环境是促进学习和分享，还是加剧孤立？员工需要每时每刻坐在桌前，还是可以在任何地方工作？举例来说，工作现在越来越移动化，员工可能不在桌前，而是用电子设备完成工作。出差和请假申请可以用电子软件批准。不过还不止于此。考虑一下能不能倾听员工的声音，提高员工参与度吧！考虑提供一个能为不同工作需要，提供不同合作空间的数字化职场吧！
技术
——这点可能让人惊讶，不过技术管理及操作自身就需要数字化和敏捷。很多时候，信息技术被认为是要花钱的，我们会抱怨为什么一个系统要投入那么多人力，一个改动要花那么长时间。但是，如果我们相信科技是业务成长之源，那就在源头多投资吧：投资工具，也投资相应的人才，使用最新的技术。让你的IT系统成为“持续成长”的系统，而不是“老旧”的、衰退不能用的系统。顺便一提，英语里“老旧”一词是个多义词，它只有在形容IT系统时才作贬义词用。如果你的系统确实很“老旧”，那么，制定更新换代的计划——考虑一下DevOps（开发与运营一体化）模型，或者云端，或者微服务，或者敏捷与持续交付吧。
领导力
——或许领导力改变的时候才能发生最深层次的改变。我并不仅仅指领导者，而是说人们领导组织的总体方式。它包括战略、计划、决策、预算、治理和绩效管理。领导者获得了准确的信息吗？雇员愿意提供信息吗？各层领导都愿意倾听吗？不论个人还是组织本身，都在持续学习吗？牢记沃伦·巴菲特的告诫，时刻警惕：傲慢、官僚主义和自满。
你有多数字化，多敏捷？
如上所述，数字化和敏捷是形容词。它们没有静态的定义，而是相对的概念。没有人能说一家公司满足了一组固定的条件，就是一家数字化公司。因此，不要问“我们是不是数字化”，而要问“跟竞争对手或以前相比，我们的企业数字化程度更高了吗？”。另外，数字化包含很多层面，你的企业可能在一个领域非常数字化，但另一个领域却做得不够。这种情况也不能长久。比如说，渠道十分数字化，但员工和技术的数字化成都非常低，就不明智。对于敏捷，道理也是相似的。敏捷也是一个相对的、包含多个层面的形容词。
在这里，我提出了一些衡量数字化和敏捷程度的评估方法，因为这是与时间、与对手赛跑，所以是相对评估。你可以有一些绝对的评估方法，不过即便如此，它们也是在相对场景下才合理。图4展示了这套评估方法。
图4 衡量数字化和敏捷的程度
我想强调这些评估方法只是为引出讨论而提出。当然没有适用于所有组织、所有领域（也就是前面讨论过的渠道、组织单位、合作伙伴等等）的一套标准评估方法。不同的组织和领域，侧重会有不同。因此，我提供的只供参考。
制定一套评估方法的时候，弄清楚你的目标对象非常重要。对渠道，评估对象是客户。一个企业更加数字化（或更加无缝等等），它的转化率就会更高。对职能部门，可以用订单、交货单等等作为评估对象。对员工，评估对象就是员工自己，人才招聘、员工发展才是最重要的。
另外，我的评估没有考虑“方法”，也就是说我并不关心你在使用什么技术。你如何做好顾客工作，达成效果才是最重要的。
这个数字化评估框架，原型是基于电商平台制定的。如果你有一家电商平台，而它比其他电商平台更数字化，我会期望你有更高的客户转化率，更低的客户投入，更高的交付履行速度，更高的推荐精准率，以及更高的客户推荐率。
评估敏捷化程度，我用的是同样的准则。评估的对象主要是变化：对变化的反应有多灵敏，变化后质量有多好，发货速度有多快，团队结构应对变化的速度和效率如何，以及学习速度有多快。
重申一下，我要强调这些评估方法只是为了引出讨论。你需要根据你的组织和领域进行调整。
如何更数字化、更敏捷
渠道，职能部门，外部合作伙伴，员工，科技，还有领导力等领域都可以变得更加数字化、更加敏捷化。虽然每个领域都有细微的差别和独特之处，数字化和敏捷化的方法是相似的，思维也是相似的。我总结了这些不同的方法帮助你变得更加数字化、更加敏捷化（见图五）。这是数字化者和敏捷者的职业工具。
图5 变得更加数字化、更敏捷的方法
先谈谈更加数字化的方法。当然这仅仅是个简介。
首先，利用数据。
不要猜测，猜测会带来不必要的风险。你的设计和决策都必须基于相关的、无偏见的数据。设计在线或离线系统时，思考可以获取或收集数据的方法，当然不能侵犯客户隐私。思考在渠道、产品和服务中可以嵌入哪种智能来减少客户投入。
第二，设计思维是研发新产品和新功能时常用的。
设计思维是与客户共情，了解需求以及反复改进可行的解决方案，永远追求客户认可。这与传统意义上“我什么都知道”的象牙塔思维的设计是不同的。不断收集数据、信息反馈，设计也持续迭代、改进。
第三，思考你怎样能利用科技民主化。
不要限制顾客的操作，相反，向顾客和合作伙伴开放技术，让技术成为顾客的工具箱，顾客可以自行组合工具自助服务，满足需求。这包括开放应用程序接口，公开成果或提供其他自助服务的功能。这就是赋权，给客户赋权。
第四，反思你的价值主张。
你还能向客户提供什么？你能更好地在客户和合作伙伴之间建立连接吗？你能重新包装你的产品，或者和合作伙伴的产品重新组合？这就是改变商业模式，它常常需要组织结构的变革。
最后，寻找将你的产品变成平台的机会。
利用效应帮助客户放大商业生态系圈。这当然并不容易，需要清晰的价值主张、投资和市场，才能跨越引爆点。需要精心策划，才能保证生态系圈中有一个健康的网络平衡。
踏上数字化之旅，首先你需要变得
更敏捷
。没有敏捷就不能开始，这就是为什么我们经常看到新企业在做老企业想做却做不到的事情。老企业被官僚主义和自满绊住了。数字化在于改进商业科技的硬件和软件，但是敏捷在于改变员工和领导的心性。
敏捷之路开始于谦虚和勇气，在于承认我们不是什么都知道，而且我们愿意
不断学习和适应
。学习需要如饥似渴，对现有的所有智慧进行消化。学习也在于不断验证假设和猜想，不断调整，寻找可行的方法。
与敏捷很相似的是
精益系统思维
。分析整个价值流，去除浪费和瓶颈，或许还要重新设计价值流。精益系统思维常常和设计思维一起使用，但是前者更着重于后台合作，后者更着重于客户触点。
有了
科技民主化
，权力就会被下放。权力不再集中，相反，决策权会交给前线——创新最多的组织边缘。这对于很多组织来说，需要进行引导和赋权。过去，决策是由几个大人物掌握的，但是现在由很多小人物做决定，为顾客提供更好的服务。
引入颠覆性商业模式，需要改变组织和团队结构。这合乎情理，因为每一个商业模式都有相关联的组织结构。这是现实生活中的康威定律。不过商业模式在变，组织结构也在变。在企业结构方面没有万用灵药。组织结构是动态的，让自治的团队发挥才智满足客户需求，比让你的员工在循规蹈矩恪守工作流程要好得多。
如果数字化平台可以利用客户及其社交群体的网络效应，利用员工的网络效应也是一种创新。提供让不同职位的人合作的机会，这会让你的员工更好地了解公司，也能发掘更好的工作方法。这也能创造更强的归属感，而归属感正是传统企业中缺乏的。
为什么你不够数字化？
最后说一句，苹果公司推出iPhone的时候，诺基亚在研发上花的钱是苹果的九倍。钱和资源并不是关键。除了科技方面投资不善，我怀疑（并无证据）诺基亚当时有潜藏的傲慢、官僚主义和自满。如同每个个人一样，其实就是那句再普通不过的俗语：“骄傲使人落后。”
如果组织中存在某种显而易见的问题，鼓足勇气提出来吧。这个世界不需要假的数字化、纯粹的口舌之劳、或用来装饰门面的数字化。你需要有勇气，坚持，看到问题的核心。
问题经常出在人心，也就是为什么敏捷需要先行于数字化，而勇气需要先行于敏捷。
所以，抛弃旧方法，系统地开启数字化的工作，在走向数字化和敏捷的进程中也要运用数字化和敏捷。有了这份勇气，你会得到丰厚回报的。
企业不敏捷就out了
很多企业已经走在敏捷转型的路上，首先始于电信和互联网公司，然后是金融行业，现在连零售这样的传统行业都在尝试转向敏捷。
从2001年敏捷宣言宣布到现在，已经有将近十五年的历史。十五年，在我们这个变化迅速的软件工程行业已经是一个非常悠久的时期了。敏捷并不是什么新玩意，而已经成为我们行业主流的管理运营体系。
如果一个企业还没开始拥抱敏捷思想并付诸实践，那它很快要就out了！原因很简单，为了快速响应市场需求的变化，企业采用和拥抱一些敏捷的方法和思维是必须的。
走向敏捷并不表示完全放弃目前的工作方式。很多企业可能会觉得目前的运营有敏捷所不具备的优势，但在这个快速变化的时代中，持续改进已经成为必然，敏捷有很多成熟可操作、可落地的改进方法是完全可以被拿来借鉴的。如果一个企业对现有的工作方式太执着，结果必然是逐渐边缘化，直到被市场淘汰。
十年前，很多企业对敏捷有所怀疑，说敏捷不成熟。但如今形势恰恰相反，一个还没有拥抱敏捷的企业会怀疑自己到底出了什么问题，为何不愿意敏捷、为何敏捷不起来。
在2007年，每当我介绍敏捷，都一定会跟瀑布模式做个比较，解释敏捷的好处。眼下我再给企业介绍敏捷时，已经不谈瀑布了，大家都知道敏捷的好处，解释也变得多余。我遇到的问题大多是如何让敏捷落地，如何把敏捷带给整个企业。
企业痛点在哪？
即使敏捷已经是主流了，一个企业也不应该为了敏捷而敏捷。敏捷是要解决具体问题的。企业具体问题在哪？有哪些痛点？涉及哪些方面？这些问题应该从组织结构开始梳理。
图1展示了一个典型的企业组织结构。
上层负责指定方向，规划、预算、决策、治理和激励。在执行层面会有业务部门直接与用户对口。用户的请求和期望由业务代表来收集。如果组织有复杂的系统应用组合，往往会有一个解决方案部门，负责整理需求传达给开发和测试。开发测试交付的软件系统由运维部门来运营和支撑。
我咨询过的很多企业，从互联网企业、传统企业、到嵌入式产品厂商等，他们的组织结构大概就如图1。
图1 典型企业组织结构
虽然图1是一个高度抽象的组织结构展示，但它有益于让我们在讨论企业痛点时找到具体聚焦的主体：是业务侧，还是解决方案侧；是开发测试侧，还是运维侧，亦或是决策层的问题？
企业的痛点一般是如何让各部门端到端的更好协作，那么具体痛点在哪？瓶颈在哪？具体哪些部门必须更加敏捷灵活的运作来响应市场变化？
小范围的尝试、小范围的效果
很多企业在尝试敏捷的初期往往都会从一个小范围开启，大部份会从开发测试小团队开始。小团队的敏捷方法和理论非常成熟，比方说Scrum的小团队迭代运作，极限编程（Extreme Programming）的用户故事（User Story），持续集成（Continuous Integration），看板（Kanban）等。
图2 小范围的尝试，小范围的效果
小团队敏捷运作的方法和理论是很成熟的。有能力让小团队敏捷落地的教练和资源也很多。
不管企业团队大小，如果企业敏捷落地只限于开发测试这一侧，没有执行层端到端的考虑，以及和企业上下对齐的思维，就不能发挥敏捷的潜能，就失去了获取更大效益的可能。
没有组织层面的支持，小团队的良好效果也不容易持续，反而很容易倒退。组织一旦想踏上敏捷的道路，就必须要有决心，必须要有长远的目标，必须考虑企业的整体敏捷转型。
大型企业的挑战
除了小团队必须敏捷之外，一个拥有大型开发团队的企业还必须解决一系列的问题。我与许多上千人企业的管理者和工作者交流他们面临的挑战，做了一个总结（看图 3）：
图3 大型企业的挑战
这些企业面临的挑战包括：
-
端到端的敏捷：
如何让执行层端到端的运作更加顺畅稳定？包括前端的需求管理和后端的运维协同。前端的业务代表往往非常希望需求能够快速上线，而后端运维则希望系统稳定，能不变是最好的。在这样的矛盾中，大型组织必须思考如何建立一个快速又稳定的开发通道。
-
跨团队协作敏捷：
团队之间和项目之间如何协作得更好？每个小团队都有他们的目标和工作量，团队之间的工作计划如何更好的对齐，减少协作的成本和不必要的等待或者冲突？我经常观察到由于团队之间冲突导致工作中不必要的拖延，浪费了时间非常可惜。
