《任务工程指南》（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 于 北京
系统工程公众号是由一群系统工程爱好者所发起，目的是推进系统工程在中国应用，纯粹公益性质。
