我把百年來的管理概念和方法精華總結為10000個字

文/明道創始人任向暉

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實踐。

讀完此文，就邀請您試用我們創辦的企業協作軟體-明道。我們在設計這個協作平台時儘力融入了這些經典的管理智慧和理念。

推薦閱讀：