公司的组织结构决定了一个公司如何组建自身资源以及打造怎样的产品。这也是CEO能明确做出的为数不多的决定之一。由于组织结构很容易被简化为简单的图表，因此，往往当一个公司表现良好时，其组织结构常常被他人效仿;而当事情进展不顺的时，人们就会异口同声地希望其向一些显而易见的选项改变。不幸的是，现实要复杂得多。Matthew Yglesias在最近的一篇文章中写道，苹果公司不同寻常的职能型结构可能无法满足其庞大的公司规模。文章清楚地描述了两种主要的组织结构，并解释了一个新的结构将如何解决苹果公司的一些问题。今年早些时候，Stratechery的博主本·汤普森(Ben Thompson)也提到了苹果的组织结构变革正处在十字路口。我真希望事情能像这些帖子写的那样简单明了。如果你不确定职能型结构和事业部制结构对组织发展意味着什么，那么请阅读这两篇文章作为背景资料。
读到这些帖子和近期对苹果的组织评析，让人想起多年前微软高管的离职风波。在当时，一些学识渊博的顾问主张，微软应该是事业部制的组织结构而非职能型组织结构。 当时公司大多都是基于“产品”衍生的事业线构建公司结构而很少会基于各职位的“功能”。所以当时第一次接触到这种区分让我感到困惑(相信很多人也是如此)。但由于对那个时期的记忆以及我自己多年来在各个规模的组织中积累的工作经验，我现在有了动力来看看在对这两种结构选择中，哪些标准是有效的，哪些标准是无效的。
本篇文章分为四个部分:
- 一些个人的亲身经历
- 关于组织的两个黄金法则
- 关于事业部制与职能组织结构的利弊分析的集合
- 关于组织设计的普遍真理
首先，这篇文章特别长 主要因为这是一个困难且复杂的话题。在以人为中心的公司中，CEO采取的组织方式与当时亨利福特(Henry Ford)在工厂中提出的创新生产方式同样重要。当大企业中，组织形态影响甚至决定了什么样的产品会制造出来。
01 全面职能化，个人工作经验
实践中，在任何公司的组织结构中，几乎未见过能纯粹表现这两种组织类型的例子。伯克希尔哈撒韦公司(Berkshire Hathaway)或通用电气(GE)等工业企业所看到的企业集团模式，接近于事业部制结构，但这相当罕见。同样，除了单一产品公司之外，几乎很难找到纯粹的职能型组织。苹果很接近于职能型组织，但是在下定论之前还是应对更多的细节和操作有一定的了解。在这点上，细节非常重要。一般来说，你越深入了解，你就越意识到大多数公司其实都处于组织结构的混合地带。他们试图采用一种“全世界最好”的方法来避免单一组织结构带来的令人不悦的取舍。
举个例子来说，几乎没有一家事业部制的或者职能型的公司允许其全球销售团队分散至各个业务线，由各自业务部门内部进行管理。因为此团队可能是实际掌控公司整体命运的关键。同样地，大多数公司都将财务和人力集中在总部进行管理，这两者通常都是“经营企业”的标志——即使他们是按业务部门来报告销售或收益。类似地，大多数职能型组织都有许多小型的、自主的团队致力于不同产品开发或营销计划。
可见大多数提炼出来的单一组织结构其实是对组织本身实际情况的讽刺，因为在运作上很少存在。这就是为什么我在文章的开头使用了那张与事实相差很远的组织结构图表——这是一幅很好的讽刺漫画，但却与我在Microsoft工作的事实相去甚远(尽管我完全理解人们为什么喜欢这幅图片)。 这一差别解释了为什么把组织结构看作钟摆是如此普遍。当你以一种方式定义了一个组织，事情变得很简单；但是当你面临挑战时，你有会很容易改变原来的定义。
office 由职能型转为事业部型
长期以来，微软的Office团队管理结构一直是经过深思熟虑形成的(这要归功于传奇人物迈克·梅普尔斯(Mike Maples Sr.)，在加入微软之前，他在IBM的职业生涯中经历了所有能想到的事情)。他的智慧深远影响了组织的发展，远远超过了他的任期时间。在“应用程序”的早期(在80年代，它被真正的称为“应用程序”)，Office团队是典型的职能型结构，就像你所想象的一个有着几百人的初创企业一样。在每个环节如工程开发、测试、文档编制、营销、本地化等等都有一个领导者。也有专门负责某一应用程序工程师(比如文字处理和电子表格)，但其他大部分人的工作都是在为下一个应用程序准备。
通过Mike卓越的领导，组织随后演变成由各个业务单元组成(各事业部有一长串朗朗上口的名字，如ABU, EBU, OBU, GBU, DABU）各个业务线拥有自己运营所需的研发和营销团队。值得注意的是，Mike坚持让损益意识较少影响各个事业部组的决定。他(无可争辩)的逻辑很简单，就是很多时候不能合理地解释损益表中的成本。因为(a)大部分成本不受业务单位的控制，(b)业务单位通过相互依赖或竞争以获得大部分业务成功。后一点可以用Word团队领导者最喜欢的一句话来说明“让Word 变得更加完美的是Excel”。
Mike在IBM的经历促使了这一想法的形成，因为他花了多年的时间观察人们如何将成本转移到其他团队，为自己的团队争取更多收入，甚至与公司共享服务的价格作斗争。这种“分配”活动是极端的“财务操作”，随着业务相互依赖的增长，这种“财务操作”的复杂性呈指数级增长。最终，争取到的损益对组织中的理性思维造成了毁灭——招聘、投资、营销等活动都受到了这种少有人理解的神话数字的影响。真正缺点是，它把会计作为一种做战略决策的工具。由于Mike 领导Office巧妙地规避了这一陷阱。Office的事业部制的结构运行得非常好。
之后当其主要业务需要从单一应用程序规整到一个套件时，Office的结构需要相应发生些变化。此时，集中式的营销结构就变得非常重要，因为它可以解决Word广告与Excel广告完全不同的问题，或者让不同产品线销售人员搞清主次。在出现了集中化的销售、财务、人力资源平台后，工程团队也需要建立一个共享平台解决一些产品本身的协同问题。这导致了工程团队采取一种更实用的方法，将越来越多的资源集中到工程、测试和产品管理的高级领导者身上，以构建大量的共享代码和基础架构。然而，组织内部也保留了相应应用程序的事业线，因为打造冠军产品仍很重要。这种职能和事业线混合的形式虽有不太吻合地方，但至今运行得相当好。在某种程度上，这就是Office 365今天的样子。
Windows 从事业部制转为职能型
在Office 工作了12年，经历了6个产品周期后，我转到了Windows。这两个部门的文化差异成为了我关注的焦点。当时，Windows系统组织下有许多“单元”，数千人为各个“单元”工作。这些单元之于Windows与Word之于Office相比要细得多。“单元”组织会受到Windows的青睐，原因如下。Windows为每个子系统都提供了不同的产品——文件系统、内核、shell、核心网络、图形，以及更为细微的代码页、传真/扫描、DRM等等。实际上，我做了一个详尽的项目，对产品单元的数量进行分类，所有的Windows产品和其相关的在线服务有142个单元。每个单元都由一个总经理(或产品单元经理)、一些工程师(称为软件工程师)、测试人员和产品经理(称为程序经理)组成。具体来说，大多数团队平均共有30人，其中每队工程师不到15人。当然，正如我们在Office看到的那样，这些单元团队都没有销售、营销、财务、人力资源等。但每个单元确实有独立企业的所有属性来决定在产品单元中做什么工作以及如何分配资源。因为没有任何中央协调和约束，使得单元内的项目管理工作非常有趣。但是当2006年在开发下一个Windows版本的过程中，事情并没有进展得很好。当时很自然有人会问，是否是组织结构造成了问题，还是是否只是领导/管理方面的问题。确实，在Windows中体验到的许多不协调的地方——不同的API策略、不同的语言和运行支持，不一致的企业管理，解决相同问题的不同模型等等——其实都可以直接归因于这种事业部制组织结构。所以，我们对Windows团队进行了重组——我知道我们需要做出一些改变，但我们花了大约3个月的时间进行了100多次会议，才真正理解了需要改变什么和为什么要改变。本质上促使这次改变的其实是Windows的产品属性。首先要认识到Windows实际上是一个单一的产品，只有一个发布日期，有限的客户(PC制造商)，以及非常广泛的终端用户群，等等。考虑到这一点，事业部制组织可能从来就没有什么意义。
在变得“职能化”的过程中，我们所面临的挑战主要集中在以下几点上：
这一改变是我们需要变得“职能化”。但是这是一个巨大而痛苦的过程，因为它基本上结束了20年的“事业部制”组织，要消除许多管理层，取代掉许多总经理。我在这篇文章中省去变革管理中血淋淋的细节。
- 缺少清晰的产品目标和明确的责任
- 降低工程工作质量
- 极少的跨团队协作
- 资源配置的不灵活
- 产品开发缺少灵敏性
- 核心环节的低效率
这是Windows团队中许多人感受的总结。对于大多数参与“职能化”的人来说，这是一个相当大的变化——不仅是当前组织结构或汇报结构发生的变化，还包括他们对自己的职业生涯和期望发生的变化。由于微软的大部分部门长期以来都是由产品/业务部门组成的，因此，大多数经理最直接的职业目标就是从工作职能部门的经理一跃成为多学科经理(MDM)或产品部门经理(PUM)。在像这样的重大变革时期，大多数人必然会更加关注自己的道路，而对公司整体的担忧减少。这很自然，但使变革面临的挑战更大。虽然在这个转变过程中我学到了很多东西，但其中一个让我印象深刻，因为它充分说明了组织形态如何影响团队中人才的整体增长。如果你有一个大的组织，在那里，好的员工从直线/单一学科的管理工作转到同时管理多种学科的工作，那么实际上这会对其掌握的核心学科中的技能会有一个明确的，渐进的侵蚀。其次很多提拔上来的总经理，有管理能力却缺乏在产品管理、软件工程和测试等核心技能方面的领导力。
02 两个黄金法则 Golden Rules
为了商业成功，许多疯狂的建议会产生。例如，在谷歌的早期，他们避开经理，坚持经理可以直接对接40-50个汇报人。这个想法并没有持续多久，但是很多公司都认为这是值得考虑的。相反，如果某件事进展不顺利，那么用不了多久，集体智慧就会得出结论：你需要调整钟摆方向。事实上，由于没有最优或最完美的组织结构(如果有的话，那么这篇文章将是不必要的)，那么最重要的是了解每种结构的弱点并弥补它们。关于组织，以下是我所尊重的关于组织的两条金科玉律。
1. Golden Rule of Orgs—Don’t ship the org chart. 组织机构的金科玉律——不要随意发布组织结构图。
关于这一点，早在很久以前就有很多人写过。组织结构图不能动态反映组织变化。而发布的结构图会成为一种限制。当Office要构建一个套件时，我们组织各个事业线来构建一个套件。当Windows需要按时交付一款Windows产品时，我们删除了产品事业线组织结构并开始使用职能型结构，当我们想提高产品设计和质量时，我们还提升了测试、产品管理和设计的领导者的质量。当我们第一次想要制造一台电脑的时候我们创建了一个只专注于这一事务的组织并委任由一个领导者来做，等等。当你创建一个组织结构图时，你就是在创建你的产品——组织中的不协调最终会反映在产品中;资源配置方式会体现在工作的重点上;工作职能的不同会反映在你选择的领导等等。
2. Golden Rule of Re-Orgs—Know the problem you are solving. 重组的黄金法则——知道你正在解决的问题。
如果有一件事一直让我惊讶的话，那就是组织结构的改变很多情况下是在没有明确将如何分配新结构、新领导和新资源，没有确定需要解决哪些问题的情况下发生的。事实上，我所见过的每一次组织架构上的改变，一开始都不是为了问题陈述，而是为了任命某个人负责，或者从以老板为中心的角度把一些东西组合在一起，或者把一些东西分开。很多人在阅读组织结构重建的邮件后并不太确定刚刚发生了什么，这也解释了为什么大多数人忽略了关于重组的邮件而直接跳到了组织结构图。因此，最简单的黄金法则是明确指出导致变更的问题并从那里开始。然后，你要指派一个团队负责处理这个问题并让他们明白什么会变得更困难(在现实中或感知中)，以及如何解决或管理这些挑战。例如，我花了很多精力向员工阐述在职能型结构中的职业道路和机会，因为管理阶层的消除，许多人认为职能型组织结构相对于事业线组织结构缺乏明确的晋升路径和发展通道。
03 职能型组织结构 VS 事业部制组织结构
没有一个组织是纯粹的职能型的或完全基于各个事业部，然而在任何给定的公司的规模(有着一个以上的产品或超过100个工程师)几乎肯定有一个占主导的结构。在没有特定人群的背景，特定的公司或特定的产品计划下，对于“功能或单元”的问题，是没有一个通用的答案的。对于这些组织结构，是有各自的优缺点的。
1. 为什么喜爱一个职能型结构？
- 1.）一个产品代表一个组织。这是职能型组织最明显的真理，也是为什么大多数初创公司会在相当长的一段时间内都保持此种结构。但即使是在Windows(6000名全职员工)的规模下，如果只开发一种产品，那么你就不需要真正的事业部制结构。然而我们在Office的组织结构转型中看到，一旦客户有需求购买一套office组件，就有必要对应设计一套能有效发展office各个产品线的组织结构。
- 2.）更好地发展每个职能领域的技能。职能型组织能使员工深化职能领域的知识和技能，而非扩展其综合技能。这仅仅是因为组织中的大多数高级人员是工程师、测试人员或产品经理，而不是总经理。在职能型组织中，大多数成为领导的技术专家会创建一个更加专业并且在技术上有经验的团队。我认为对于科技公司保持技术专业性是非常重要的因为公司的未来从来不是取决于现在的产品而是多年以来引领科技变革的能力这些都取决于科学技术的深度。
- 3.）为每个学科创造群聚效应。即使对于非常大的产品组织，有些必要的技能只有少数人才拥有。在一个职能型组织中，并没有很多人力的学科还是能够聚集在一起并创造出一个重心。这既适用于工作的众多领域，也适用于某个领域的特定技术技能。早在2000年当Office需要构建在线服务, 我们做的第一件事是认识到了我们需要操作技能并且基于此创造了一个职能型的领袖来构建统一的服务平台而不是让每个事业部来雇佣和训练自己的专家。
- 4.）组织结构更容易少等级。对于管理者来说，管理那些他们“理解”并能自己完成的工作要比管理那些没有个人经验的人要容易得多。由此可见，在一个职能组织中，你可以拥有更少的经理，从而更少的层级。一项统计数据:在Windows改革前，整个团队超过35%的经理(!)但是当我们完成“职能化”的时候，我们有20%的经理。
- 5.）一场会议可以汇总所有观点。 在任何规模的项目中，最大的挑战将是确保各方的声音都被听到——在产品制造中，这些声音意味着工程、产品、设计、质量、本地化、运营等等。在一个职能型组织中，你不需要让总经理“代表”这些声音或者更糟糕的是每次带3到4人参加会议。相反，在一张桌上公司的所有职能部门都能有参与。
- 6.）拥抱产品之间的协同效应。一个大的机构同时着手几件事情明显地是需要寻找事件之间的协同效应。再加上销售和市场总是希望讲述1+1>2的故事， 几乎总是让这些产品能同时工作并能同时发货。职能型组织是面向跨部门协作的，因为它消除了可能独特地解释策略或者协同效应的管理层。
- 7.）更容易实现资源和负载平衡。原先计划的事情会发生改变。应对变化的方式就是将工作负荷转移到他处或者将资源调用到最需要的地方。一个职能型组织特别适合这种情况因为所有职能的资源都在同一个屋檐下并且各个职能的领导能更加顺畅和轻易地看到改变的潜在条件和改变后的波及面。在一个有着高变化程度的项目中，一个职能型结构几乎都是更好的选择。
2. 什么时候职能型组织不起作用？
1.）难以扩展到多个产品。对职能型组织的第一个指责是这种结构很难在一个团队中创造出多个产品。不同的产品和不同的市场分离是很重要的。如果一套由不同产品组成的系列对应的是同一个市场，那么职能型结构能够运转良好。如果对应的是不同的市场，那么职能型结构很难去管理不同的客户或者销售渠道，或者仅仅只是不同的发货日期。
2）需要一个在某方面有专业技能的领导同时管理很多人。一个不是特别明显的挑战是这种结构需要一个强有力的领导管理多个部门。在过去，你可以有两个经理，每个人都有能力垂直管理自己的小团队，而现在，你希望只用一个经理就可以来管理这两个小团队——每个人都知道管理并不总是直线延展的。如果你缺少高层领导，那么在转到职能型结构前，你需要储备人才以对挑战做好充分准备。
3）可能会稀释责任感。由于事业部制组织机构有着强大的问责作用，这有必要提到，职能型组织可能会有较少问责的感觉。最终，承担责任更多的是整个团队，而不是某一个领导者。多年来，许多在Office或Windows o工作的人都对多个工程贡献者的存在感到沮丧，而这些领导者同样对那些似乎从不知道发生了什么的部门经理感到沮丧。
4）从一开始就需要合作。职能型组织本质上是关于跨领域和跨学科的协作。人们通常会觉得，如果你不与一个经理共享一个资源，促成交叉的信息，释放出混杂的信息，那么合作就会变得不可能。通常，如果组织认为要把事情做好需要一个经理来强迫人们去共享合作，那么其中问题就比组织结构所能解决的问题要大得多。但是在这种情况下，事业部制组织需要付出非常大的代价来更快强制跨部门协作。
5）管理远程工作的人员具有挑战性。如果你的团队在地理范围上分散到一个相当大的程度，那么职能型组织可能是具有挑战性的，因为它促使每一个领导成为从能从远程有效管理人员的专家。通常，随着在不同地理位置的分部的发展，公司面临着将这些分部领导者“集合”到总部或是独立创建分部组织的挑战。如果你只有少数的远程工作人员或者他们都集中在一个功能领域，那么职能型组织是可行的。
6）员工往往觉得晋升机会更少，因为一个部门只有“一个”领导。.随着员工的成长，他们希望扩大责任范围，在“一个职能领域管理”与在“多个领域管理”相比，可能会有一种机会有限的感觉。对于我来说，应对这一挑战的重点是优化技能的深度和经验的广度并以此作为职业发展的衡量标准。
3. 为什么人们喜欢事业部制结构？
1）更容易管理同时管理很多产品。如果一个公司有着很多产品或者产品有不同的时间点 面对不同的市场和结构那么一个事业部制的组织结构往往是合理的。一个值得思考的领域是如何处理多平台产品开发。通常，多平台开发的产品都视为不同产品一方面是因为较少有一个客户同时使用不同平台开发的产品，另一方面也由于产品开发需要不同的技能(常常是故意的/必要的缺乏代码共享)。.但是在利用不同平台或不同的工程技能作为事业部制组织的边界时，值得谨慎，因为处于下游的客户/市场需要不同平台有战略性的协作以扩大使用范围。
2）给员工只需要一个决定而非多个决定。事业部制是那些面临了许多“问题”的高管们的最爱，因为他们只需要作出一个单一的决定——就是雇佣一个人来解决一个问题。如果招聘经理在其职业生涯中缺乏相关领域的经验，那么单次招聘的简单性就很有吸引力。
3）能专注于特定的市场挑战。和做单一决定很相似的就是组建一个小的，专注的甚至是独立的团队来解决这个问题。这样做，你可以解放一个团队去追求市场需求，解决问题，或者打造一个产品而不受组织其他部分的影响。这种的方法很有吸引力，只要一旦团队成功后，会有一个如何解决潜在的战略和市场问题的想法。事业部结构几乎总是被用来应对破坏性的技术的威胁。
4）能清晰地界定工作。事业部型结构从一开始就明确了部门的使命（尤其是在一个领导之下）并且对公司的其他部门也能有效的沟通。
5）谁是决策者是很明显的。在事业部型结构中，有意地进行设定后任务有谁负责 怎样做决定是很清楚的。
6）团队会很小，每个人其实都会喜欢小团队。在事业部型公司中创建的组织，总是以小而集中的方式开始的。这会很刺激并且很多人都想加入.(在我职业生涯的早期，出于这个原因，我非常努力地去加入一个为数不多的小型组织，但可惜的是，我没有得到那份工作)同样的情况是，被选中作为事业部领导的人往往正是为新团队创造吸引力的人。实际上，随着时间的推移，很少有团队能保持小规模。
4. 事业部型组织结构在什么情况下不起作用？
1）迄今为止事业部最大的缺点是这种结构是为了解决问题而非创造一个商业市场。虽然问题需要引起注意，但是事业部的结构更多的会重视一个技术问题或者一个市场问题而忽略了对于开拓一个市场的战略性举措。不可避免的是，负责解决一个问题的事业部会纠结于“自我定义”而很少地去寻找目的或者使命感。反过来，因为一个事业部的组建是为了解决一个问题，很多做法是谨慎的。
2）重复的策略或执行总是建立一个新的事业部后出现。事业部型结构最大的神秘在于它给人一种印象就是新成立的事业部是在这个大组织中唯一一个接收新技术或者新产品的地方。如果这个部门研究的领域是最新最热的那么这种神秘感会更加强烈。但是事实绝不是如此。 我已经记不清楚有多少次看见Microsoft为了追求最新最热的领域以组建的新团队是如何困难地防止竞争对手创新（不管是通过在现有产品上增加新功能或新市场还是通过尝试一些新的领域）由于追随热点而造成的战略混乱和冗余总是伴随着一个单位的创建。.事实上，公司规模越大，创建一个新事业部的可能性就越大，因为新部门的创建释放出每个人都应该为这个新领域工作的信号。
3）相互协作是不会发生的。事业部型组织不管有多大，让相互合作变得很困难 – 但是这其实是故意的。 一个事业部的总经理专注于他们被任命来解决的一个商业问题。在没有充足的资源下，他们更愿意去解决迫在眉睫的问题。而且，即使有额外的资源几乎都优先解决部门内部的现存问题而非来解决需要跨部门协作的问题。
4）很难分配资源。如果一个负责多个事业部的高管觉得有必要重新分配各个部门的资源，那么这么做需要重新审视各个部门的职责，流程以及工作目标。这是因为一个事业部就是一个单位。各部门的经理会抵制变化如果资源从本部门移除。
5）在没有必要的地方创新或改变。对于事业部制结构另一个潜在的缺点是在一个公司或文化下存在的事业部会随着时间去重新修改几乎所有的流程和方法。. 我已将看到有很多事业部认为为了获得成功需要不同的招聘方法，不同的部门饮料，不同的绩效评估工具，雇佣不同的公关公司以及购买不同的家具等等。我能想到的最著名的部门创新是用一个独立的权限去建立部门自己的域名和邮箱地址。工程师们也经常用部门创新来改造工具和方法。这些再创新有时能够创造出一个个鲜明的部门（明确的隔阂）但是很多时候是白费功夫。
6）事业部制需要更多的资源。一般情况下事业部制组织需要更多的资源，不仅仅是因为有许多的管理层。当Windows 从事业部制结构转向职能型结构时有个有趣的统计就是整体的人员数没有发生变化但是有一半的行政人员被裁掉了。
7）很少任命能跨部门的的领导。事业部制的组织结构制造了一种错觉，就是高管人数的数量增加是因为事业部中总经理的数量和各职能领导的数量。现实是因为事业部有限的规模，事业部制组织阻碍了职能层面领导的增加。一方面公司想让每个人都成为通才但是另一方面在资源一样的情况下，很少人能有机会管理较大范围的事务。
8）很难找到合适的总经理。总经理的来源是个需要考虑的问题。 在Microsoft很多总经理都是项目管理出身。这很符合逻辑但是也需要考虑两个维度的问题。其一，这样的总经理很难产生新的产品经理因为总是关注眼前的产品，这也造成了产品经理的缺失（正如我们在Microsoft 发现的一样）.其二，管理一个你从未做过的工作是非常困难的，这需要大量的辅导，对最佳实践方案的观察，更重要的是如果你雇佣了很多这样毫无经验的领导，出现的问题会在整个组织中放大。
9）实际的责任感不会增加。尽管事业部制结构普遍被认为可以增加责任感，但是在绝大部分公司中，这种结构还是让人难懂的。事业部很少对销售业绩或者地域差异附有责任或者产生阴影，但在很多公司中关于定价或者支持的决定会影响整个公司并不仅仅局限在事业部层面。因为这个原因很多事业部和其相关的责任是很少和理论相关的。. 最近出现的Google集团在很多大公司中都是唯一的且极少见的特例。很多认为Microsoft有很多重点的事业部和各自的盈亏表现的人能更好地辨识Microsoft是如何管理销量，市场和地域的。
10）扩大事业部门是具有挑战性的。事业部门不是能很好扩大无论是在一个事业部门内部或是因为你有1000人以上的员工，扩大的结果是产生更多的事业部门，增加更多的管理结构。
04 关于组织设计的普遍真理 Universal Truths
和商业世界中的每件事一样，组织设计是一门社会科学并且高度地依赖于特定情境-无论是面临的具体问题，历史，人员或是更多。由于从来没有一个正确的答案，所以尽可能多地考虑所选择路径的影响总是值得的。很多企业在职能型组织和事业部制组织两者中选择让人们相信组织设计就在两者之间来回摇摆。公司选择某一组织机构可能是因为改变现在无能为力的状态，因为一个新的领导。当然也有可能是因为某种组织形式更能迎合时代风潮，或者仅仅因为可见的成功或者失败。
实际上对于这个问题有着细微的差别。 CEO和高官们能很少对大规模的挑战产生直接的影响，相比于他们，组织设计是应对这些挑战更重要的工具因为一个简单的选择会产生深远的影响。
不管不同的企业类型和情况，有些重要的因素是普遍正确的。当设计一个组织时，以下因素是不得不考虑的：
- 1. Synthetic P&Ls are, always, evil. 综合的盈亏评估永远是恶魔。回到会计的历史，盈亏分析是被高管作为工具用来分析关于资源，资金分配，定价等方面的决定的。在一个大型组织中，分配收入和成本到一个具体的部门是很难的，给每个部门领导明确的掌控范围和责任感是更加困难的。将盈亏评估用来衡量商业方面的表现不可避免的造成了过多的内部关注，推卸责任和内斗。除非盈亏分析能真正代表一个领导的控制和责任感那么这种评估比起熟悉的决策更容易阻碍创新协作和分享。我很少看见综合的盈亏评估能起作用-最糟糕的情况是它加速了内部的管制；最好情况是它给人留下成功的错觉。
- 2. Sales and geography.在全球范围内，有着多种产品线和事业的集团公司几乎不可能让具体的事业部单元独自承担管理责任。无论企业再大或再多元，消费者都需要一个相同的标志去识别一家公司。所以本质上组织设计一定要考虑最重要的方面一定是总部去定目标，组织以及管理。这意味着，对于许多业务单元来说，销售配额和提议、市场推广，甚至更多的上游营销和品牌建设都将通过全球化视角的统一筛选，而不可能代表某一个事业部领导所设想的理想。这样做的好处是，一个事业部只需一点点努力就能立即实现全球规模。
- 3. Resources not generally fungible. 资源并不总是可替代的。高管的首要角色是分配资源。现实是分配资源比简单使用数据透视表要困难多了。因为很多原因，人不总是可以完全替代的。产品的技术局限需要特定的人去解决。一些人不想为某些产品或者人工作。一些项目需要超出常理的资源。还有很多原因会最终导致组织设计不会按着图纸走会根据实际情况有很大程度的妥协。Innovation in process v. outcomes. 权衡过程创新和结果创新在组建一个组织和创造责任的过程中，必须意识到对过程的创新应超过对结果的创新。组织越大，组织设计更应该开始去反思如何得到结果而不是得到什么样的结果。同样刚成立的组织或者是小组织应较少考虑过程的创新。组织设计很大部分开始于对过程的在改造。在改造之前，了解这两个概念的区别和适用范围仍然是很重要的。
- 4. Mixed messages get mixed results.改革释放出的混合信息会带来混合结果。高管努力达到改革的中间状态- 用一种方式来构建组织已达到某一特定结果然后又用相反的方式来达到其他的结果。具体来说，往往是要创造一个事业部制组织但是同时又采取策略性的手段去鼓励合作共享和融合。最终混合改革会造成混合结构，在哪些地方进行妥协是无法预测的。可能是你得到了最需要优化的地方，至于其他的都是额外奖励。
- 5. Functional and unit orgs both work.职能型结构和事业部制结构可以同时起作用。因为对于最佳的组织结构方式没有一个正确的答案，很可能任何规模的公司可以同时实施职能型结构和事业部制结构。将产品线、不同的市场或地域叠加在一个高管身上，可能会导致组织设计的混合。这种情况下对结构的一致性或清晰性的渴望可能会是实用性的敌人。
- 6. Golden Rule: Ship schedule is everything.黄金法则：时间计划表是根本。我故意把这点留到最后，是因为我认为这不是变化的或是不起眼的。 在组织设计中，要保证执行，协作和一致性，时间计划表是根本。执行意味着，对于一个运转良好的团队来说，有一个截止日期并按时完成它是很重要的。对于协作来说，产品或团队之间的合作也只能在时间表一致的情况下才能进行，否则，就会造成一个团队在徒劳地等待或消化另一个团队的工作。最后，为了确保客户需求的消息传递、销售和整体市场的一致性，只有当产品按照计划交付给客户(以预发布和最终形式)时才能实现。时间计划表看起来比组织结构更为重要，因为这是一个更实用的工具，它不仅定义了各种产品的品质，更将这些产品以一种有力的方式连接起来。
