來源：老溫 系統工程
《任務工程指南》（Mission Engineering Guide，MEG）是美國國防部于2020年11月新鮮出爐的一份指南，其價值如同沉甸甸的黃金。
還記得當我首次看到這份文檔時，一開始并沒有意識到它有多么珍貴。翻看了幾頁之后，才發覺它是多么的寶貴！感謝匯聚了無數專家學者的CCOSE社區，專注于系統工程，共創共享的文化氛圍滋養了心靈，也讓學習的旅程變成無比美妙的體驗。當然或許只是于我心有戚戚焉。對我而言，它的“美”來自于如下幾處：（1）來自于.mil
網站的公開發布，這類文檔非常珍稀，可以讓我們管中窺豹，了解美軍的最新動向和認知結構；（2）這份冊子只有短短的 40
多頁，按照潘長江的說法，“凡是濃縮的，都是精華”；（3）所講述的主題是“任務工程”（Mission
Engineering），立意又新又好，很欣賞國外同行的這種創意和切入點；（4）作為一本“指南”（Guide），頗為實用，可以指導實踐。
此外，還有一點，我近來從事各種復雜的任務，常常感到缺少框架的苦楚。問題如此復雜，甚至盤根錯節，想要作出改革或創新，總感到現實中有絲絲縷縷的掣肘。放之任之，對不起自己的天地良心；格之革之，又覺得手中缺少一件順手兵器。對于常年在各類系統邊緣走江湖的人來說，倚天劍藏于何處，屠龍刀匿在何方？看到這份文檔，頓感眼前一亮！
回到現實問題，系統工程師在解決工程問題時，常常需要一個指導框架，也就是俗稱的“套路”。例如，在寫報告時，常常想有沒有類似的文檔可以參考，重點是參照其框架作為模板；在解決實際業務時，常常問前人（或前任）是怎么解決這類棘手問題的，重點是找尋實施方案的框架和思路。這些都說明，這類“參考架構”（Reference
Architecture，RA）或指導框架是多么的重要。如果能夠找到一套經過抽象、具有普適性的指導架構，會十分有助于深化和強化我們的系統思維。扯遠點，如果由于我們的抽象提煉能力不足，或者由于問題過于復雜，這類指導框架只好從理想的“顯性”狀態退化為次選的“隱性”狀態，然后通過靈感和“頓悟”來實現這層突破。比如，國資委在推進國企改革時十分注重選樹標桿，還有哈佛大學商學院的案例教學法，中國佛教的各類禪學，都借鑒了這種知識（或智慧）傳遞的方式。
言歸正傳，該指南建議的適用于復雜任務的架構到底是什么？我將歸納為“兩域三分法”，如果用“3+3”這個數學公式來表述。其中，“兩域”分別是指問題域、方案域；三分法是指每個域分解為 3 個子部分。
任務工程 = [ 問題域，方案域 ] ……公式 1
問題域 = [ 問題描述，任務定義，任務度量 ] ……公式 2
方案域 = [ 系統設計，分析仿真，歸納結論 ] ……公式 3
注：這里采用的方括號[ ]，而不是大括號{}，主要考慮是借用了計算機Python 編程語言的語法：方括號表示有先后次序的對象序列，而大括號則表示沒有先后次序的對象集合（字典）。細分后的整體結構見思維導圖。
下面逐一進行講解。
公式
1 中，將一個任務工程分解為問題域和方案域。首先，什么是“任務工程”？對應的英文就是Mission
Engineering。如果你愿意，將任務翻譯成為更有神圣色彩和情緒感染力的“使命”也未嘗不可。Mission
好理解，簡單說就是要達成某種目標，那么Mission 和 Engineering
放到一起，又是什么意思呢？那就是要用工程的方法將任務轉換成現實。理想和現實之間總是有一條“河流”，而系統工程師的職責就是尋找到過河的辦法。這里借用毛主席的一句詩詞，“一橋飛架南北，天塹變通途”。而這座橋就是本文所要著力討論的主題——MissionEngineering（下文統稱為“任務工程”）。
為什么分為問題域和方案域？這樣劃分是否科學？自古以來，問題和答案是一種經典的范式。古希臘提出問答法的哲學家和思想家最著名的就是蘇格拉底，他將這種方法稱為精神或思想的“助產術”。在中國古代，儒家經典《論語》，也充分利用了問答方式，來記錄孔子的思想。即使在現代，見諸于英文文獻之中的FAQ，以及各級考試之中的“問題-答案”結構，均是這種“Q&A”范式的體現。甚至，還可以深深植根于人類的“刺激-反應”心智模型（MentalModel）。總之，將一項任務或使命，分解為問題域和方案域，是天然的二分范式，類似于不證自明的基本公理。
提出正確的問題，往往等于解決了問題的大半。——海森堡
有人認為問題域并不重要，解決方案才重要。實則非也。能否提出正確
的問題。德國著名物理學家，量子力學的主要創始人，哥本哈根學派的代表人物，1932年諾貝爾物理學獎獲得者海森堡曾說過，提出正確的問題，往往等于解決了問題的大半。托尼·羅賓斯是一位白手起家、事業成功的億萬富翁，是當今最成功的世界級潛能開發專家。托尼·羅賓斯說,思考就是提出問題并回答問題的過程。他強調提出正確問題的重要性，認為這樣才能得到正確答案，從而獲得正確結果。因此，問題域的扎實工作對于任務成功，占據50%的貢獻度并不過分。
其次再來看公式 2：問題域被分為 問題描述、任務定義、任務度量。其中：
問題描述就是要識別關鍵問題，尤其是痛點和難點。以此為始，也就是常說的“問題導向”。對于各類管理問題，更是識別“痛點”在哪里，然后才能對癥下藥；對于各類技術問題，往往是識別難點，若有突破，便是創新；對于復雜體系、組織發展等問題，要考慮能力差距（capabilitygaps）在哪里，也就是常說的“補短板、強弱項”。其他待分析的關聯因素包括：相關任務概念、技術能力、成熟度、演示驗證、時間進度、交互產品、接口標準、聯合打擊、可用資產、新興技術等。
任務定義部分堪稱本文的亮點之一。最大的特色是將其又分解
為 4 個子部分：時間幀（TimeFrame）、任務劇情和場景（Scenarios &
vignettes）、假定和約束（Assumption &
Constraints）、任務定義小結（Summary）。我們都處于一種“時空”之中。時間是最特殊、不可壓縮、不可延展的單向維度，驅動著萬事萬物處于不斷的“流變”狀態和過程之中。連孔老夫子也不禁在川流旁感慨，“逝者如斯夫”。因此，拋開時間因素妄談任務或使命，是一種科學上的不嚴謹。之所以這里稱為“幀”，就像是電視、電影畫面由1
秒鐘數十幀組成，但是由于人類視覺器官的遲滯效應，已經感覺不出來了。由于分析成本和保真度（Fidelity）之間正相關，而人們總有一個可以承受的成本上限，所以選擇合適的“幀頻”，是比較重要的。劇情和場景的作用是將任務從戰略層（strategic）下沉到戰術層（tactical）。劇情和場景的區別在于，劇情是貫穿全局的重要情節，包含了所有的關鍵節點，撐起了整個任務，往往是戰役級；而場景就像是一出好戲中的若干“幕”，一切精細的操作都要在場景下予以細化，往往是戰術級。比如，遼沈戰役是解放戰爭時期三大戰役中作為關鍵的戰役，事關解放戰爭的全局，是scenario級別，而塔山阻擊戰是其中重要的組成部分，關乎“關門打狗”策略能否成功實施，需要頑強阻擊國民黨部門的拼死增援，是vignette級別。對于工程任務來說，在選擇參數設定時要經過深思熟慮，做到“精心選擇、合理設定”。假定和約束，往往是人們容易忽視的，以為是不言自明，實則非然。比較嚴謹的作法是有效識別這些假定前提和不得不遵守的約束條件，將其顯性地表達出來。同時，要定義好進入條件和邊界，準確識別環境/時代召喚或上司意圖。一旦設定，任務定義就要盡量保持不變，從而保證延續性和連貫性。最后就是任務定義的歸納小結（summary），陳明以上三個部分的要點。
任務度量（Mission Metrics）也是本文的亮點之一。印象最為深刻的就是成功度量（Measureof Success，MoS）。以前看到的比較多的是 有效性度量（MoE）和性能度量（MoP），這次看到 MoS，還是感到眼前一亮。因為對成功的度量，進一步澄清了任務目標，比有效性度量（MoE）更加明心見性！雖然后文為了表述方便，將MoS淡出，仍沿用 MoE/MoP的分層架構，但MoS 一詞仍不啻為天音裊裊，時刻提醒著系統工程師不忘初心。對于 MoE 和 MoP，可以用下面這個公式簡單表示：
MoS = f(MoE s)， MoE = g (MoPs)
即任務成功度量可由若干個有效性度量來綜合表征，有效性度量可由若干個性能度量來綜合表征。指標的選擇要充分考慮高層指揮官的意志和意圖，常見的包括：滿意度、損失情況、成本開支、時間消耗、回報率（Returnon Investment，ROI）。
關于度量，本文特意提到了度量追溯性（Traceability
of Metrics）。指標要有科學性、嚴謹性，能夠經得進一步深究和驗證（can befurther expanded and
verified），可以為系統的優化提供關鍵支撐。在此也深感實踐中，隨著數字化轉型的深化，各類統計數不勝數，上層的本意是好的，但是在深入實踐中，由于度量追溯性的不健全，導致統計數據被嚴重扭曲，甚至誤導上級決策。日本鋼鐵公司、德國汽車公司都因為統計數據造假，使企業信譽一落千丈，遭受到市場和監管部門的嚴厲懲罰。究其原因，除了科學素養、人文素養的缺失，更在于缺少指標追溯性的深入認知和系統工程方法。站在組織管理角度，建議要加大指標追溯性的閉環管理、監督審計和嚴厲追責，要依靠審計、紀檢、監察、專家委員會等部門的通力合作和介入，嚴懲數據造假者，使其不敢冒天下之大不韙、利用信息的不對稱性來欺騙組織、欺騙世人。
公式
3
中，方案域包括系統設計、分析仿真、歸納結論。系統設計強調了任務架構（MissionArchitecture），包括各類視圖（views），因此注入
DoDAF、MoDAF、ToGAF、Zachman
等各種體系框架可以在這一步大放異彩，分析各種裝備/資產、組織單位、職能/交互的序列。由于比較紛繁復雜，需要多視角、多層級才能表述清楚。康威定律說，設計架構克隆自組織架構。因此，為了更好的設計得以實施，往往需要對組織進行重新設計，這就是某些組織機構需要重組調整的內在原因之一。本文還強調了端到端的線程（Thread）。從任務線程（MissionThread，MT）到任務工程線程（Mission
Engineering
Thread，MET）的共性都是從開始端到結束端的全流程、全周期，差別在于后者為每一項活動指定了關聯的系統、技術、人員，從而勾畫了從問題域到方案域之間的現實映射關系。有時還包括能力、技術、戰術、系統、條令、組織、培訓、材料、學歷、人員、設施、領導力等諸多因素。對于上述各類變量，還要替換其中的一個或一組，以進行敏度分析。這種方式類似于中國航天的“雙想”、“過電影”，從而實現全線程、全覆蓋。最后，就是定義各類模型、數據和定量分析方法。任務工程十分重視各類基于分析和計算的模型，從而確保其一致性和復用改進。甚至可以說，模型是任務工程的核心。不僅包括傳統的仿真模型，還包括數學表達式、邏輯表達式、概念過程或者上述幾種方式的混合使用。典型的模型有設計模型、制造模型、驗證和確認模型、系統模型、產品支持模型、專業工程模型以及管理模型等。各類模型的可視化（Visualization）有助于分析和研究的深入。
基于上述模型，可以開展分析和仿真。這還包括對各類變量的敏感度進行實際分析，以及基于假設和參數輸入選擇合適的優化算法來開展分析。敏度分析能夠揭示一定的不確定性（uncertainty）和魯棒性（robustness），可以用于探究輸出與輸入之間的一階或二階的關系。可供選擇的分析方法，包括蒙特卡洛模擬、馬爾科夫鏈、回歸分析、成本分析、仿真工具等。要識別分析系統模型中的誤差和不確定性的傳播方式。一般來說，分類矩陣法、敏度分析法、優化算法這三類分析方法的效率逐級遞升。對于任務工程團隊來說，最重要的任務之一就是深刻理解模型、輸入數據、誤差傳播這三者之間的關系，以確定分析結果的置信水平(Confidencelevel)。
最后一步就是記述研究結論。包括分析報告或決策摘要，為上級領導輸出相關的計劃、策略和建議方案。關于摘要，文中列了13 個方面：
-
-
-
-
-
-
-
-
-
-
-
-
-
結論部分還要提及參考架構（Reference
Architecture）。這里的參考架構源自于本任務的分析，包括任務定義、假設、約束、方法論、置信水平、不確定性，以及其他支撐分析結果的理由。本文還特意附了2
個參考架構，分別是政府任務參考架構（GMRA）和政府能力參考架構（GCRA）。
結論部分還要附上相關的專業數據、模型和架構（Curated
data，models，and
Architecture），從而為未來的研究鋪平道路。數據是模型、線程和架構的“頂梁柱”（backbone）和基石。任務工程師有責任夯實數據的根基，使其可信、可靠、完整。如果研究的周期較長，還要考慮各項數據隨著時間的蠕變，要動態更新相關數據。為了確保數據的質量，同行分析師間的協作（peeranalyst
collaboration）也甚有必要。起碼要考慮所有數據以下6
個方面特性：簡介（Profile）、來源（Source）、精度（Accuracy）、時效性（Timeliness）、可信度（Validity）、關聯性（Linkage）。
末了，我還想畫蛇添足地說幾句。首先，系統工程永遠支持裁剪。因此這篇文章并不主張削足適履，千篇一律地套用這種架構，但是也別忘了在學會“跑”之前，最好先學會“爬”和“走”，否則難免會摔更多的跟頭，不妨借鑒華為的策略——“先僵化、再固化、最后再優化”。其次，6個模塊，不多也不少；“3+3”也很容易記憶和應用，如果想要進一步簡化，可以簡單記為“（描述，定義，度量）+（模型，分析，結論）”，或者摘取上述6
個關鍵詞的英文首字母記為“DDM+MAC”，這是極致濃縮版本。最后，再不厭其煩地嘮叨一句，千萬別忘了，定義問題和解決問題同樣重要！
致謝：感謝趙獻民、鄭新華、何強、王國新、王公韜、魯金直、陳紅濤、王忠、解士昆等老師的審閱和指導意見。
2021.1 于 北京