文/明道创始人任向晖
1、帕累托原则 （80/20原则）
这是意大利经济学家帕累托在上上世纪末留给企业管理领域最好的遗产，尽管他最初是用来描绘社会经济领域的现象，可是自然界中就是大量存在这样的幂次分布现象，企业家们也本能地发现：总是20%的客户带来了80%的收入；80%的绩效是由20%的员工创造的，这个所谓的理论发现却给企业战略和管理带来了最佳的实践指南，因为它帮助企业找到了最大化效率的最便宜方法。
理查德·库奇在1997年出版的《80/20经理人》把帕累托原则详细地解释在了企业管理领域。今天，在企业的成本和销售管理的两大领域充满了这样的应用。比如软件公司在修补bug时，永远优先修复那些影响人数最多的少数bug；企业遇到经营困境，需要削减成本时发现永远有挤不干的成本水分。
如果在管理企业时，你只能秉持一个原则，那必然就是帕累托原则。当我们面对企业目标时，永远都有机会去首先识别出那20%可能的关键任务。
2、MECE （穷尽和互斥原则）
我把MECE放到精华之二，它来自咨询业王者麦肯锡。我所接触的企业咨询业者几乎都掌握了这个原则，他们依靠这个简单的原则从客户那里挣到了很多钱。而我们自己做企业管理的，并非不能理解这个原则，只是容易被企业的具体问题和情绪偏好所遮蔽，最终付钱给咨询公司告诉我们一些常识。
MECE的简单解释就是对任何复杂事物的组合设计出一个合理的分类法，这个分类法能够穷尽所有的情况，各个分类之间不重叠交叉。你看，多么简单的原则。
它对生产力有什么贡献呢？答案在于可靠的原因求解和高质量的计划。比如，你发现销售业绩不佳，团队中每个人指出了不同的原因，于是我们就需要把影响销售业绩的不同要素用MECE原则列举清楚，如果你遗漏了（不穷尽），就有可能忽视了某个原因，如果你列了两个交叉的原因（不互斥），那么自然就无法制定有针对性的解决方案。咨询公司给你一个RCA(root cause analysis），你觉得好高大上，但背后的原则就是MECE这么简单。
MECE还可以帮助我制定高质量的计划。像设计和制造一辆新车这样的复杂项目，如果没有MECE原则在背后，项目必然是漏洞百出，企业要付出高昂的代价。咨询公司一方面深谙这个原则，另一方面通过大量的咨询项目积累了这些项目计划要素，所以自然可以把咨询服务卖出大价钱。而且，他们也不吝于分享这个原则方法给客户，因为当咨询公司和企业客户配合的时候，也希望客户能够用这个原则来进行提供信息。
你可能要问，MECE原则是不是和帕累托原则有点矛盾呢？如果只有20%的原因导致了80%的后果，我们表示应该聚焦在那20%的原因上吗？是的，但是如果我们不能枚举清楚可能的原因，就完全不可能判断出那20%是其中的哪些？
小测试：如果用一个分类法来分类员工，以下哪个分类法是符合MECE原则的？ A：年龄 B：国籍
3. SOP（标准作业流程）
把SOP（Standard Operation Procedures）列为精华之三有点奇怪，毕竟它是一个没有明确作者的概念，逐步在各个行业发展出来。而且它实在貌不惊人，小学生似乎都能够理解。但是，如果要说到对全球生产力的影响，SOP绝对功勋卓著。
SOP的产生有几个主要原因。一是生产活动变得越来越复杂，企业的产出已经不可能是一个人能够从头到尾干完的了。分工专业化必然需要更高效率地把作业方法和技能传递给大量的新员工。
二是因为很多生产活动的安全后果很严重，比如医疗和制药，如果没有标准流程来控制是要出人命的。
第三个原因有点违背直觉，SOP可以帮助工序的改进优化。SOP本来就强调要标准，为什么有利于改进和优化呢？我们后面介绍戴明环的时候可以再细讲。
SOP的特殊之处还在于它是一个知易行难的事情。懂SOP的道理很简单，要撰写出一个有用的SOP却需要艰苦的脑体结合劳动。优秀的SOP产出者既是愿意撸起袖子上手的实践者，又是有抽象和综合能力的分析师。
在卓越企业中，Business Analyst和众多的运营专家构筑出了一个又一个的商业帝国。前面提到的咨询公司也有很多是依靠出售每个行业的SOP最佳实践而发达的。
SOP也不一定是那种冗长难读的文档，像下面这个图文并茂的例子就很友好，因为它有时候需要面向不同文化程度的产线工人。
4. KPI（关键绩效指标）
提到KPI，你也许想到了绩效奖金。其实KPI本身的概念和员工奖惩并无直接联系。它今天被很多企业员工怨恨是一件很无辜的事情。有趣的是，在Wikipedia的英文版中，KPI的解释是一个组织和一项活动的成功度衡量依据。到了中文版的维基百科中，贡献者突然加上了“员工“这个客体。这个随手一加正是让KPI走形的主要原因。
KPI思想对生产力的贡献在于它帮助企业识别出不同阶段中，到底什么对自己的成功是最关键的。所以它也和另一个概念KSF（Key Success Factor，关键成功要素）息息相关。
从这个角度看，KPI思想和帕累托原则似乎比较呼应，但KPI识别的难度在于它不仅仅是从主次中区分，还需要从因果上追寻，更复杂的是，它还要结合企业自己的战略选择。
比如一家企业在某个阶段的KPI是在一个特定行业中获得新客户的数量，这显然是由企业自己的定位和阶段发展目标决定的。
以我个人的经验来看，KPI的选择是一个科学和严谨的过程。有不少咨询公司甚至提供了丰富的行业KPI库，对企业来说，真正的挑战是找出那些少数最关键的指标，用来引导自己的短期聚焦行动。但遗憾的是，今天KPI库最大的用户是HR部门，用来为每个岗位设定绩效指标。
一个企业KPI，能否有效分解到每个员工头上，每个人的KPI又不偏不倚地反映出个人的价值创造，这是我的疑问，但众多管理者疑而不弃。但至少有一点是确定的，如果要保证绩效指标对于企业来说是“关键”的，那谋求从上至下分解到全员的KPI是毫无意义的；反过来说，如果只是关注为每个员工按上一个反映个人绩效的KPI（即使能够），那么它们的加总也一定不能带来企业的“关键成功驱动力”。
思考题：一家只有20个房间，位于上海市中心的新开业设计酒店应该选择哪个或者哪些KPIs？
5. SMART（目标制定的原则）
顺着KPI，我们就不得不提到SMART原则，这是一个在目标管理中，帮助管理者检验目标制定是否科学的黄金准则。SMART分别代表Specific（具体）, Measurable（可衡量）, Attainable（可实现）, Relevant（相关）, Time-bound（有期限）。
SMART原则是马里兰大学洛克教授在目标设置理论中总结出来的。他同时也是一位心理学教授。它的传播是如此之广，每个人在初入职场后不久都会接触到，从而明白了过去的所谓“个人目标制定“是多么地扯淡。
但是，企业目标的设定有时候就不那么明显地愚蠢，我们很容易把任务完成当成目标，把口号当作目标，把长期使命当作目标，把赚钱就可以当作目标，而且丝毫不觉得有问题。训练员工有效地制定目标现在是管理发展的重要任务。
在硅谷流行的OKR工作法之所以日益被重视，和它提供了一个有效的目标制定框架有关，它提示我们企业需要明确目标意图，围绕这个目标意图设定可衡量、高挑战的关键结果指标，再围绕目标设计和制定针对性的任务，并且定期衡量结果的达成情况，从成功和失败中寻找改善之道。这个过程正是下面要介绍的概念PDCA环的核心意义。
6. PDCA（戴明环）
PDCA是Plan-Do-Check-Act的简称，后来也有人把它修正为PDSA（S代表Study，以更好地强调迭代改善的方式）。因为它是质量管理专家戴明提出的，所以又被称为戴明环。这个理念可以简单概括为：企业如果要提升产品的质量，就需要周而复始地执行这个循环。戴明在晚年直截了当地说”质量无须惊人之举“。当CEO面对低下的产品质量可能无比焦虑，或者暴跳如雷，但对于专业的直线管理者，耐心地按照这个原则来改善是唯一的出路。
PDCA是一个非常容易被看低的理念。1946年，日本战败后，因为偶然的原因，留驻日本的几位清教徒海军工程师开始帮助日本重振战后经济，辅导日本落后的生产制造业改善产品质量，戴明在这个时期把他的统计控制办法介绍给日本企业。但此后三十多年，这套理论方法只在日本获得了重视，创造了日本的诸多企业神话。直到1980年，美国企业猛然发现自己在汽车工业已经严重落后过去的战败国日本。NBC在当年拍摄了一个纪录片《日本行，为什么我们不行》，戴明才开始名闻美国企业管理界，以至于后人一旦谈到质量改善，想到的就是戴明。
戴明从来没有被自称为管理学者，实际上他的确是自然科学领域的专家，拥有数学和物理学硕士学位和物理学博士学位。他也认为领导不是指手画脚，惩罚威吓，而是用好的方法帮助成员把工作做得更好。戴明在质量体系之外，还有一段著名的“戴明十四点”，指出了很多管理困境下有效的应对手段。
直至今天，还是有很多企业面对质量问题的时候，要么束手无策，要么就诉诸于人的素质。这是戴明最反对的一点。
7. Checklist（检查清单）
说到检查清单，你也许想到了贴在厕所门后面的一张卡纸，上面写着很简单的检查事项，然后每隔几小时就有人来打个勾。这么简单的管理工具，居然也能够登上TOP10管理概念和方法？是的，而且我对此深信不疑。越是简单的管理工具，越能够给全社会带来生产力的提升。
厕所保洁的检查清单当然创造的生产力有限，但是在医疗、航空、航天、建筑等高风险和高赌注行业中，它同样有效。这是这个清单可能变得更长，检查项目更多。
2009年，美国医学专家阿图·葛文德的畅销书《清单革命》把这个深藏在某些行业内部的管理工具介绍到了诸多行业。它首先被用来解决困扰医疗行业多年的手术后感染风险。阿图在研究了航空、建筑等行业的作业方式后，为WHO贡献了这么一张《外科手术安全检查清单》。就这么一张纸帮助医疗行业在未来几年内大幅降低了差错率和因此带来的病人感染、死亡率（医学行业记录为采用外科手术安全清单使患者手术并发症发生率从11.0%降至7.0%，死亡率从1.5%降至0.8%）。在这张清单中包含了在病人麻醉前，皮肤切开前和病人离开手术台前的三个关键时间点的必要检查项目，甚至包括确认要切除的器官是左侧还是右侧这样的简单问题。
检查清单产生价值的核心原因是世界上最不可靠的生产要素是“人”。只要是人，就会犯错。在高度紧张的作业环境中，犯错的几率其实非常之高。通过检查清单的交叉确认，可以大幅度降低差错率，而又不需要付出太高的成本。
今天，使用检查清单的行业越来越多，包括我自己所在的软件行业，每次的产品版本发布前，工程师们都要依照检查清单逐项操作，以杜绝人为差错。
8. WBS（工作分解结构）
如果你被指派负责一个大型工程，比如要造一个机场，你会做何感想？妈呀，我完全不懂建筑行业啊。但如果你学的就是土木工程专业，而且做了很多年的工程师，是否就一定能够完成这个使命呢？未必，在复杂工作上，专业知识背景是一方面，懂得项目管理的核心思想WBS是另外一件事。WBS提供了把需要复杂协同的项目进行有效工作分解的思维框架。
WBS最早的显性使用就来自最复杂的项目工程，阿波罗计划时代的NASA，后来通过美国国防部系统引入到更多的使用领域。到了1987年，美国项目管理协会发表了著名的PMBOK（Project Management Body of Knowledge），其中提供了WBS的实践标准，并将其推广到更多的民用领域。
我们可以简单理解WBS是一个树状目录，把复杂项目按照某一个维度逐项分解，主任务可以分解为若干子任务，子任务还可以有自己的子任务。这个方法听起来很简单，但在项目管理领域，它有几个原则：
比如100%原则，WBS需要根据项目总范畴包含100%的内外部交付物，每一层分解的子任务也要100%覆盖它的父级任务范畴；
互斥元素：WBS结构中各个元素是相互独立不交叉的（不能有“采购盘子和采购餐具”的并存）；
要按照产出物计划，而不能只是规划行动事件，因为后者要么列多了，要么列少了；
要有合理的最小工作包（work package）大小。
WBS的另一层复杂性在于它还要考虑进度计划、资源计划和成本计划，以及任务的依存关系等内容。
复杂项目的WBS规划需要专业人员和经过项目管理训练的人员配合，所以它是一种高价值的知识资产。比如一个机场或者地铁项目的WBS规划本身就是可以用来复制到其他同类项目中的。也有不少咨询公司依靠积累的WBS范例来提供行业咨询服务。
软件行业也在为这个需求进行变革，过去，WBS的规划依靠的是MS Project这样的项目计划软件，现在，在线协同软件已经发展得越来越强大，可以把复杂的项目规划和项目沟通整合在一起。
掌握WBS理念并不困难，有一定的项目工作经验，花点时间上一个在线PMP课程是绝对可以完整理解并上手的，如果你想锻炼一下WBS的分解能力，可以试着幻想为自己筹备一个婚礼，因为婚礼筹备还涉及不到什么专有知识。
因为项目管理人才的稀缺，这个职业在很多行业都炙手可热，虽然目前绝大多数的PMP持证者都在建筑、软件和医药等少数行业中。
9. Agile（敏捷项目管理）
上面提到的WBS是一个典型的计划驱动的项目管理思想，强调的是边界明确，责任清晰，成本和进度可控。所以，也有人把这个模式称之为“瀑布”模式，计划和执行就像瀑布一样，绝对地从上至下，直到落地结束。
到了1990年代，软件行业的效率极客们发现这个模式有很大的弊病。首先，很多开发项目（尤其是软件产品）的计划过程很难明确边界，因为需要复杂的技能配合，责任清晰也很难在过早的计划阶段落实，更重要的是，一家软件公司的产品是没有瀑布的尽头的，每个产品都希望能够分阶段长期发展下去，即使是一个版本的产品，开发结束也没有一个明显的界限，通常都要伴随长时间的缺陷修复和特性迭代。甚至，在互联网软件时代，还出现了MVP（最小化产品）的概念，极端地提出了一个项目的最早计划只应该覆盖两周到四周的工作时间。
2001年，十几位软件工程师在美国犹他州的一个会议后发布了一个著名的《敏捷软件开发宣言》。其中，Jeff Sutherland成为敏捷项目管理的布道者。
敏捷项目秉持了一些新的原则，包括持续和渐进地围绕客户满意交付，为频繁的变更做好准备，通过高密度协作提高质量。如果说敏捷项目也有WBS的影子的话，那么它强调的就是尺寸恰好的工作包，适合在两到四周内交付成果并开始得到反馈。工作包的出发点不是具体的事物，而是被称为User Story的用户需求描述。它的大意是明确一个迭代周期会解决客户的哪些问题，然后到周期结束来检验这些问题解决得怎么样，从而决定下一周期加入哪些新的User Stories，或者继续保持原有用户需求的迭代。
在过去十几年，敏捷概念已经走出了软件行业，因为很多企业发现，原来基于瀑布流的周全项目计划内容对于自己公司内部的变革项目来说是不必要的。企业内部具备足够的动力来面对变更的需要，从而保持灵活性，也让交付的结果更有意义。一个软件产品的开发是这样，一个企业内部的质量改善项目也是这样。我们可以看出敏捷项目管理结合了PDCA和WBS的思想核心。
其实，早在软件业推行敏捷项目管理理念之前，在生产制造业已经有一个非常接近的管理工具在使用。它被称之为“看板”（Kanban）。上世纪50年代，丰田工程师大野耐一为了解决材料、生产和库存的衔接问题发明了这么一个简单的工具，后来被发展成丰田著名的精益生产和JIT库存生产方法。软件行业是非常善于学习的行业，所以工程师们本能地将其发展成电子化的工具来服务自己的管理需求。今天的互联网协作软件大多都基于这个思想。
WBS和Agile都不是万金油，在不同的项目性质和目标下，不同的思想会占上风。一个接受NASA委托的航天工程，如果只考虑敏捷，也是要付出巨大的财务和履约风险代价的。一个小型的软件产品公司如果迷信使用甘特图来绘制出未来一年的产品开发计划也是一定会遭遇惨痛损失的。
10. GTD（计剔地）
最后一个精华方法我给了GTD，它的全称是Getting things done！听起来像是一句大俗话。
GTD是效率专家David Allen的创造，他认为个人工作效率之所以低下，是大多数人不分青红皂白撸起袖子就干，而对所有要做的事情不够清晰，也没有合理的优先和场景计划。因此带来了盲目工作和焦虑。所以他设计了一个并不简单的流程图来帮助工作人群规划和执行个人任务。它的核心思想是首先要collect所有的想法和待办，然后按照一个逻辑去预处理（process）它们，把筛选出来的事务组织（organize）到不同的“抽屉”里，比如“现在就做”、”也许将来有一天会做“、”等待某任务完成后做“、”某一天做“等等。只要我们把脑中的混乱想法都拿出来，洗干净，摆放好，我们就不会焦虑和失控。
GTD也没有一个中文翻译，所以我随便用“计剔地”来形容它，意思是“有计划地剔出不同的事情，放在不同的地方”。
GTD是一个浅显的道理，却是一个知易行难的事情。能够坚持按照David Allen的标准建议去执行的人可谓凤毛麟角。但这完全不影响大众对它的深度认可，即便我们不能100%地做到，理解这个思维模式，不断地检验自己当下的工作方式，尽可能地向GTD靠拢，也能给我们的个人生产力带来明显的帮助。我曾经写过一篇我的个人效率就靠一张即时贴，其中介绍了我个人的GTD实践。
读完此文，就邀请您试用我们创办的企业协作软件-明道。我们在设计这个协作平台时尽力融入了这些经典的管理智慧和理念。
