迈出第一步(译)

太长不读版总结:

这一章对前五章进行了总结,给出了在组织内部落地 Wardley Map 的思路。作者对技巧、术语、符号进行了总结,并给出了一些可以帮助我们检查组织势态感知能力的反模式。最后,作者推荐了一些值得一读的介绍通用的战略概念的书籍。


我经常讲到在巴塞罗那艺术酒店碰到的那位聪明的高管。提前透露一个小秘密:我不是唯一假装自己能做高管的人,他也一无所知。但是,这一点是我画了六年地图之后才有人告诉我。我觉得一定有秘诀,而绘制地图不过是效仿别人的笨办法。但事实上大多数行业的做法都是在没有理解形势的情况下直接下场。这就像将军没有地图就投入战斗一样。把命运交给运气和个人英雄主义吧。

认识到这一点后,我震惊了,我开始质疑那些被我珍藏在小图书馆里的商业战略书籍。我通读了所有书籍,按照原则、基本规律、特定背景或纯粹靠运气进行了分类,这是一项艰巨的任务。现在,如果有人告诉我他懂战略,我就会要他提供一张业务地图。如果给不出来,任他讲得天花乱坠,我也不会相信。他知道的可能并不像他以为的那样多。还有可能更糟,让我们陷入困境的多半不是我们不知道的东西,而是那些我们自以为知道但实际上并不知道的东西。

我并没有说大家都很无知,我想强调的是了解环境、竞争背景还有审时度势本来就是战略的核心,并不是奢望。如果不了解地形、部队的位置、规模和能力,没有什么能拯救你,鼓舞人心的愿景、训练有素的部队、强有力的文化还有过硬的技术都不行。卡斯特上校的教训值得汲取,他手里的地图甚至比今天大多数企业的都要好。我见过有些公司浪费了数十亿的资金却成了炮灰。我见过有些公司用没完没了的SWOT图、故事和其他神奇的思维方式来为这种行为辩护。我也见过有些公司轻而易举地统治了一个又一个行业。

遗憾的是没有军事背景的人很少讨论态势感知的话题。要让高管们体会到:他们学到的最新的成功秘诀并不是放之四海皆准的,必须结合环境思考,但这往往费力不讨好。国际象棋也是一样。我可以给你看棋盘(地图),然后教你游戏规则(基本规律),支持或牵制棋子等通用原则(原则),然后教你具体的走法,如愚者自将(特定背景的打法)。然而,即使你学会了这一切,仍然必须自己思考决定走子,或者使用计算机来处理数十亿的排列组合。神奇的指南或是四象限解决方案都是不存在的。游戏可以教会我们很多管理知识。

最近几年,我甚至会建议高管们花上一两个月练习大型多人在线角色扮演游戏 (MMORPG),例如魔兽世界 (World of Warcarft)。这听起来好像是在教人摸鱼,但没有经验的人能通过MMORPG学到一些基本实践,包括:

态势感知的重要性。把精灵和矮人投入战斗之前,你首先要做的事就是侦察地形,提高对态势的感知。在战术策略、学习、战斗力倍增、避免被对手击溃(或被对手横扫)等等都必须要了解地形,这一点非常关键。玩上一定的时间之后,侦查地形就变成了本能,而那些懒得看地图的玩家经常会被吐槽浪费了大家的时间,因为他们总是问“这是哪儿?”、“我们怎么去那里?”。

能力的重要性。最大规模的战斗需要多种能力,从伤害(通常躲在后方远程输出攻击敌人)到坦克(顶在前面充当肉盾)到治疗(坦克经常被攻击需要治疗)到群体控制(法师的睡眠法术可不是摆设)。战术和角色部署取决于场景。如果没有态势感知,能力往往会被用在错误的地方,战斗必然会陷入十分被动的局面。

团队协作的重要性。多种角色需要团队协作,包括沟通、协调以及把团队的利益放在首位。使用同一种共同语言(例如地图)也能起到积极作用。

准备工作的重要性。如果不知道武器怎么用,战斗时就算全副武装也是白搭。一些MMORPG中最大的公会有几百到几千名玩家,还有丰富的维基、沟通机制、培训发展、战术策略、用户界面定制、组织结构、领导技能、专家小组和信息系统的支持。这提供了一套系统的学习机制。

怎么样?玩MMORPG和做业务有什么不同吗?做业务往往没有地图。大多数公司的态势感知能力都很差,即使是可以预测的变化也会让他们困扰。

商业战略通常就是蛮横不讲理地行动:怎么做、做什么、什么时候做,而不会考虑意图:在什么环境下行动和为了什么行动;这一点最能说明问题。总的来说,我们意识到了战略需要多种能力,这已经是进步了。然而,我们往往会因为没有考虑到心态和背景而遭遇挫折,然后又因为各自为战进一步恶化(筒仓式的运作)。我们当然会在团队合作上发力,时不时组织一些团建活动,管他有枣没枣先打几杆子。

沟通的工具再多,我们也会抱怨有问题。这里面的原因往往又可以追溯到对环境的认识不足:如果我们不了解地形,也没有此基础上制定进攻计划,而是用模糊的愿景或故事来代替,那么事情的实际进展就很难沟通了。“你在什么位置”这种问题,地图上的坐标才是最好的答案,而不是“我刚刚走过一条小路走,现在旁边有一棵树,还看到了很多兽人。这里的阳光很耀眼”。

事实上,沟通重在效率而不是机制,如果态势感知能力不高,新玩家就会不停地问“我们应该去哪儿”,四处乱跑或是原地发呆。这会占用其他团队成员的宝贵时间,削弱团队的整体实力。准备工作在企业中几乎是不存在的。在某些领域,我们可能会试着做一些场景规划,或者想象初创公司如何破坏自己的业务来做些推演,但总的来说,我们最常做的还是火烧眉毛的工作,比如到处充当救火队员,或者被竞争对手牵着鼻子跑,我们几乎留不出准备的时间。

从网络游戏中学习这些知识值得说道说道。那些把商业幻想成战略游戏的人都应该花几分钟时间,看看经验丰富的玩家团队是如何有组织地突袭的。这些玩家运用的战略打法和理论水平是大多数企业无法企及的。还好,我们业务上的对手往往也存在同样的问题:缺乏态势感知、组织割裂挣扎、缺少团队合作、大量的沟通无效、准备不足等等。

这就好比一群没有经验的魔兽世界玩家此起彼伏地喊着“进攻”、“谁能给我加血!”就向对方冲去。这场惊心动魄的乱斗往往只会凸显出那些英雄玩家个体(好比精灵军队的史蒂夫·乔布斯)的作用。如战斗中有一方是一支经验丰富、训练有素的团队,这场乱斗必然会变成大屠杀。第一个被干掉的是奶妈,紧接着是群体控制的魔法师和坦克,然后是失去防御无助的远程伤害攻击手。

商业世界中有些组织非常危险。“这是我们的愿景,我们的人很靠谱……现在冲锋!”这种简单的招数拿他们没办法。广积粮缓称王是更加明智的选择。这里给那些担心亚马逊带着Lumberyard下场的游戏公司提个醒。要么潜心研究自己的玩家,要么换个赛道东山再起。最后,不要指望读几章关于地图的书或玩几场网络游戏就能立刻转变为战略大师,前面的路还很长。

绘制地图的技巧

我在绘制地图时会运用一些通用的技巧、常见的术语和图例,包括:

所有模型都是错误的,但有些是有用的。(译者注,统计学家乔治·博克斯的名言)

地图是指引而不是答案。因此,地图不用画得特别完美,画到足够进行协作就好,这需要开放心态去分享并迎接挑战。此外,在场景规划和研究不同进攻位置的可行性时,也可以结合使用其他工具,包括财务模型和商业模式画布(现在是我的最爱)。

找准位置再问为什么

战略要做的第一件事是确定进攻的位置,然后才是为什么进攻这里而不是那里的原因。就是要搞清楚位置(Y轴)和运动(X轴)。

迭代并持续学习

整个战略周期是迭代的,必须按部就班一步一步来。也就是说地图不是一次就画完了,而是要一直画下去。再次强调一定不要钻牛角尖,克制对整个环境精雕细琢的想法,这种事无巨细的“死星”项目注定要失败。应该拥抱不确定性,着眼小处,从一点切入(便于采取行动)。如果在地图上花了很长时间还没有解决什么问题,那么就停下来。如果找到更好的方法就果断一点。世上没有完美的模型。

身体力行

既然战略由你负责,你就应该挑起这付担子,躬身入局,自己去掌握战略打法。所以我经常让战略顾问很难堪,虽然他们并不是帮不上忙。但是,不要完全依赖第三方给出的答案,而是让他们来挑战你的战略,从他们那里学习新的打法。

术语

绘制地图时我使用了很多术语。我常常直接使用这些术语忘记了解释,这让我有些内疚,为了纠正这个习惯,我把最常用的术语列在了图60中。

术语

图60 术语

术语(中文版)

图60 术语(中文版)

符号

地图显然是可视化的,虽然与常规测量的地理地图相去甚远,但使用一套通用的符号也很有必要。图61是我在绘制地图时使用的符号。

符号

图61 符号

符号(中文版)

图61 符号(中文版)

早期术语仍然适用

绘制地图的过程也会随着时间演变,因此我现在使用的术语和过去也有些不一样。这些表面的变化纯粹是为了让地图更美观,基本含义没有变化。

绘制地图如何落地

大多数组织都有现成的组织结构可以嵌入绘制地图的方法,架构小组、CEO办公室、业务关系职能部门或是其他机构都可以绘制地图。一般来说,分布式的组织通常会有负责交付的业务部门;某种形式的行政职能部门,如政策、审批、问责;还有一个共同或共享的服务提供团队,提供一些共性的元素,如图62所示。

通用组织结构

图62 通用组织结构

但是,提供一套通用组件的想法就有些牵强了。没绘制地图之前是很难发现哪些东西是重复的,也难发现这些东西是由哪些不同的业务部门提供的。这往往会变成凭空捏造。业务部门和共享服务之间往往还存在着政治冲突,最糟糕的时候共享服务职能可能被当成阻碍。

要解决这个问题,我们需要把共享服务交付和确定共同点的工作分开。我发现要实现这个目标,最好的方法不是(为了避免重复浪费而)削减业务部门的预算(通常是政治争论的焦点),而是引入独立的协调职能部门。协调职能部门的作用是通过支出控制机制鼓励遵守原则(“法”);同时通过地图让业务部门之间互通有无,促成共享。这不需要大刀阔斧的改革,但现有组织结构通常需要正规化,例如行政职能部门办公室或架构委员会可以转化为这个角色。支出控制机制应该设定限额策略(例如10万英镑),任何超过限额的项目必须绘制地图,并将地图发给协调职能部门。协调职能部门可以对地图进行分析,提出建议,在组织内透明公开地图并接受挑战。收集到的地图多起来之后,协调职能部门还可以找到公共服务的模式。这应该是一个相对快速的过程,从启动到形成提议用不了几个小时。

协调职能部门可以将其他原则(例如单元结构、开拓者-定居者-城市规划者以及更多特定上下文的打法)引进到业务部门里。我在图63中进行了总结,增加了协调职能部门(第一点)。我还发现共享服务(第二点)应该提升为一个业务部门,他们应该放开对外提供公共组件,而不是把自己局限于服务组织内部。如果你打算运作ILC(创新-杠杆-商品化)这样的生态模型,那更应该这样做。如果组件的重要性足以为之创建共享服务或公共服务,要么存在外部市场机会,要么就是重复造轮子。

加上协调职能

图63 加上协调职能

共享服务团队的目标应该是成为提供工业化组件的城市规划者小单元。业务部门主要应该由提供定制产品和租赁服务的开拓者或定居者小单元组成。协调职能部门将主要由定居者组成,他们的主要工作是确保组织透明,并从组织内部学习。但这需要时间。

如果是第一次采用协调职能部门(例如英国政府的支出控制部门),其成员必须具备“未来”运营方式的经验,也就是说他们被寄予挑战组织的期望,而开拓者应该在这里有一席之地。这一点非常重要。2016年我仍然看到一些公司建立起的数字团队只顾埋头画饼,却对现有组织不管不顾。这无形中划分出了“他们”与“我们”的界线,形成了各自为战的局面,如果没有任何挑战机制,那么你很可能又会回到老路上。企业的抗体会把你打败。

因此,应该先从一个协调小团队开始,这个团队的人员技能水平要高,他们要帮助其他业务部门创建并分享地图,还要向这些部门学习。你可能会发现,一些业务部门把自己开发的功能作为通用组件提供给其他业务部门。不要阻止这些自然而然的分享行为。虽然这里面可能掺杂了一些“建设自己帝国”的投机因素,但如果业务部门愿意分享地图并从地图中学习,那就支持他们。这些组件后面一定可以移交给共享服务团队。需要注意的是别让业务部门破坏流程,比如找各种借口逃避共享或支出控制。

有些人常常会说他们“太忙了,没空画地图”或“地图太复杂了”。画不出地图的东西还有人愿意花10万英镑买单,这种想法在我看来值得警惕。这么大的开支,我们应该知道用户的需求是什么,涉及的内容是什么。地图是一种反思的手段,我们可以挑战假设,质疑我们正在思考的东西,反过来证明我们已经考虑清楚了。但请注意,他们找的这些借口往往是抵制分享的信号,因为他们担心的是他们在组织内的权力基础被动摇。知识就是力量,这句话经常被误解成:把知识分享出去就是在削弱自己的力量!无休止的重复、偏见以及不合理的打法会让企业自残,想要阻止这种自残,你就要和这些行为作斗争。准备好迎接战斗和挫折。

你还会听到很多人说“我们有架构团队”或“我们的沟通没问题”。大多数联合型的组织重复造的轮子何止百个,沟通也和高效沾不上边。组织里现在正在进行的、没什么差别的物联网或人工智能孵化项目有多少个?自己想一想。如果回答是“不知道”或“不确定”,那么根据经验,不管组织有多大规模,真实的数字一定远超想象。没有地图这样的沟通工具和协调职能部门,就不太可能发现这些重复。因此,可以利用发现重复问题的机会引入共同语言和信息共享。

但请注意,抵制共享的人会叫嚣着要豁免,要保护筒仓。如果向他们妥协,自然浮现的分享行为都会消失。还要注意即时通信、Wiki等等沟通机制,因为它们是双刃剑,一面可以促成变革,一面则会巩固阻力。你必须坚定。

有人会问,协调职能部门是不是应该属于行政执行部门,我的回答是属于。在我的公司里,行政执行团队就承担着协调职能。在更大的公司里,你才会想要建立一个专门的部门。要记住,你的高级副总裁和副总裁不可能像变戏法似地把地图随手画出来。他们需要支持和帮助,因为他们和我一样不熟悉战略。

持续学习

这一整本书本身就是一个持续学习的过程,我认为更重要的是把这个学习的过程(战略循环)展示给读者,而不是某些模式的细节。打好基础之后,读者可以自学这些模式。但回顾也是必要的,图64是我们目前已经研究过的基本模式。

已经讲过的模式

图64 已经讲过的模式

已经讲过的模式(中文版)

图64 已经讲过的模式(中文版)

反模式组织

我觉得用反模式来说明避免做某些事情非常好。那么,绘制地图这件事有哪些反模式呢?总的来说,违背绘制地图的过程中发现的原则,无法应对基本规律,没有正确运用特定背景下的打法都是反模式。我们可以用这些反模式来描述对环境一无所知的组织。我经常这样分析竞争对手,但要注意这里可能存在误导(误导的话题我们还没有讲到)。反模式组织看起来会像下面这样。

不关注用户需求。

无法描述用户需求,还经常把自己的需求(盈利能力、收入、手机数据)与客户的需求混淆。

没有共同语言。

描述同一个问题空间的方式五花八门,线框图、业务流程图和故事等等。经常因为混淆和错位出问题。使用的工具都不符合任何地图的基本特征——可视化、特定背景、(相对参照物的)位置、运动和组件。

不透明。

回答不出“我们正在进行的物联网项目有多少”这样的基本问题。信息往往被封闭在筒仓之中。

不去挑战假设。

行动的依据要么是热词,要么是Hippo(Highest Paid Person’s Opinion,工资高的人说了算),要么是哈佛商业评论上的热门文章。组织中往往有人知道他们构建的东西是不会成功的。

对重复和偏见不管不顾。

实际的重复太多,远超想象。随便做点调查就会发现,外部已经有了商业化的产品,却有团队还在定制他们自己的托马斯·斯威茨烤面包机。团队经常会因为这一点而抵触变化,尽管他们说不清用户需求,但这些产品总会有些独特性。

没有使用正确的方法。

总是想用一套方法解决组织的所有问题,比如“所有IT全外包”或“统统采用敏捷”。一个极端是固守原来(老皇帝)的方法,另一个极端是穿着皇帝新衣的新方法,因为某个特定情况下的例子获得了成功就急不可耐地铺开(结果偏见)。你一定会听到这些说法:“六西格玛这个项目有用,所有项目上就都有用”。

想一口吃个胖子。

总是想大张旗鼓,大力出奇迹(比如搞死星项目)。频繁地重新设计主要平台或是大范围地调整组织结构都是这种情况。

没有考虑能力和心态。

看不到特定背景需要的能力(如财务、运营、IT),认为它们都是一回事。宣扬只有“IT”的口号,不考虑各种类型的细致信息。总是想用一套通用的培训课程覆盖所有主题,比如“让每个人都参加敏捷培训”。

没有针对演变的设计。

新的热词一出现就要采用新的组织结构。云部门、数字部门、大数据团队等等。这里还有一个错误的例子,风靡一时的双重、双模和双速IT概念就是最好的说明。双模的基本假设是有两个团队,一个专注于新事物(通常是数字化),一个专注公司核心业务的运营。这听起来很有道理,但很久以前我就发现这会造成一个棘手的问题,图65的地图就是最好的解释。

双模的问题

图65 双模的问题

这幅地图来自(第四章的)图42,我只是拿掉了图上的“定居者”团队。现在,城市规划者构建了一个新的组件服务(A1A2),开拓者在此基础上构建(B1)。一切都运转良好,直到开拓者让城市规划者接管这个新的组件服务。城市规划者的回应往往是拒绝的,比如“太不稳定了”,新产品还没有成形,目前还不稳定,也没有文档,因为没有团队负责产品的演变。开拓者们又想赶紧交接出去继续自己新的探索,这样矛盾逐渐升级。最后,开拓者们只好继续在自己的组件上构建(B1C1)。最终,平台永远不会扩张,上面构建的新东西一点都不可靠,就像一团搅在一起的意大利面。这会对性能产生负面影响,直到有人提议搞个“死星”项目,重新设计这个大平台。

可惜,在新设计的平台上构建还是会遇到同样的问题,因为组织结构的问题(“消失的”定居者)并没有解决。大多数人都不知道,双模结构可能会带来短期的胜利,但最终得到的是永不扩张的平台、搅在一起的意大利面,还有损失惨重的平台重写。双模非常适合把热词挂在嘴上搞组织结构重组的顾问,但是对那些想用可持续方式达成目标的企业来说就太糟糕了。

做不到通过使命、专精和自治来驱动。

组织内部往往对目标感到困惑,同时感到缺乏控制,又无力改变些什么。

不了解基本的经济模式。

经常实施效率或创新项目,却没有意识到两者之间的联系。觉得有应对变化的选择(例如云计算),实际却什么也做不了。没有认识到过去的成功带来的惰性,也没有办法应对这种惰性。

不了解特定背景下的打法。

没有现成的语言来理解特定背景下的打法。经常把“开源”、“生态系统”、“创新”这些术语挂在嘴边,却不清楚用在哪里合适。

不了解环境。

不能完全掌握自己组织内的组件和复杂性。常常说不清自己的基本能力。

不懂战略。

总是在说“战略是为了什么”,但分不清目标为了什么和行动为了什么。很少讨论位置和运动,而且讲不清楚应该从哪里突破,甚至无法理解先有位置才有为什么的重要性。战略往往就是简单粗暴的行动声明、复制的热词或外部建议。

因此,如果你还不确定组织目前的处境,上面这些反模式可以你帮助思考公司内部的态势感知现状。我在图66中也做了一些对比,注意这只是一份帮助你讨论和思考组织状态的指南。

信号

图65 信号

信号(中文版)

图65 信号(中文版)

推荐书单

唉,我还没有找到任何有关商业中的地形情报(使用地图和态势感知)的书籍,这也是我纠结了八年终于要写书的原因。我是算不上合格的作家,这本书就算是抛砖引玉吧。因此,我也会推荐读一些值得一读的书,因为这些书提供了一些通用的概念。我不一定同意他们所有的陈述,但这些书绝对值得探索。我认为下面这些书都值得花时间读读(译者注:有中文版的都进行了补充,所有图书已经整理成一份豆瓣书单:https://www.douban.com/doulist/154878118/)。

孙子兵法, 陈曦译注
Sun Tzu, the art of Warfare, Robert Ames译

Science, Strategy and War, Frans P.B. Osinga

Atlas of Military Strategy 1618–1878, David Chandler

The Simplicity Cycle, Dan Ward

Accidental Empires, Robert X. Cringely
意外的電腦王國,罗伯特·X·克林格利,羅耀宗译。

Hierarchy Theory, The Challenge of Complex Systems, Howard H. Pattee

The Evolution of Technology, George Basalla

Thinking in Promises, Mark Burgess

Diffusion of Innovations, Everett Rogers
创新的扩散(第五版),E.M.罗杰斯,唐兴通/郑常青/张延臣译

Customer driven IT, David Moschella

Digitizing Government, Alan Brown, Jerry Fishenden & Mark Thompson

Learn or Die, Edward D.Hess
学习的科学, 爱德华·赫斯,

The Oxford Handbook of Innovation, Jan Fagerberg, David Mowery & Richard Nelson
牛津创新手册,詹·法格伯格/戴维·莫利/理查德·纳尔逊,柳卸林/郑刚/蔺雷/李纪珍译

The Starfish and the Spider, Ori Brafman & Rod Beckstrom
海星式组织,奥瑞·布莱福曼/罗德·贝克斯特朗,李江波译

Does IT matter?, Nicholas Carr
冷眼看IT,尼古拉斯·卡尔,曾剑秋译

Technological revolutions and financial capital, Carlota Perez
技术革命和金融资本,卡萝塔·佩蕾丝,田方萌译

The Entrepreneurial State, Marriana Mazzucato
创新型政府,玛丽安娜·马祖卡托,李磊/束东新/程单剑译

Topographical Intelligence and the American Civil War, Daniel D. Nettesheim

The Intelligent Investor, Benjamin Graham
聪明的投资者,本杰明·格雷厄姆,王中华/黄一义译

Cybernetics, Norbert Wiener
控制论,诺伯特·韦纳, 王文浩译

Systems Thinking, Jamshid Gharajedahi
系统思考,贾姆希德·格哈拉杰达基,王彪/姚瑶/刘宇峰译

The Age of Discontinuity, Peter F. Drucker
不连续的时代,彼得·德鲁克,吴家喜译

The Red Queen, William P. Barnett

留给读者的练习

我的建议可能有很多,最重要的还是在你的组织内练习绘制地图。我也会时常翻阅上面这些书。

如果你还是对态势感知的重要性存疑,我能不能建议你去玩一下魔兽世界?据我所知,费尔南多·弗洛雷斯(智利政府前财政部长和参议员)开设了这方面的行政培训课程。我知道这听起来很疯狂,但还有什么能比在打游戏(play game)中学习打法(gameplay)更好的呢?

在接下来的六章中,我会回忆自己的峥嵘岁月,我们将再次展开战略周期循环,看看地图是如何逐步形式化起来的。

原文作者为Simon Wardley, 本译文作者为覃宇,分享需遵循CC BY-SA 4.0许可。

这个系列的帖子