本文所说的“系统工程的玻璃笼子”，是看不见的，却实实在在禁锢着系统工程。让人们只能在笼子外面围观系统工程，或者赞叹、或者批评、或者质疑，而不是把系统工程从笼子里面解放出来，让它发挥影响，释放其潜在的、巨大的能量。
1.1热力学第二定律 热力学第二定律即熵增大原理，揭示了自然界的一个普遍规律，可以用来帮助理解系统工程。熵即系统的混乱程度。非孤立系统的熵减小需要外部能量投入。举个例子。假如家里的房间不打扫，会越来越乱。要想让房间重新变得整洁，就需要花精力打扫。打扫房间所花费的人的精力，对于需要打扫的房间来说就是外部能量投入。 如果任由一个系统自由发展，系统的熵必然持续增大。如果要控制系统的熵，必须以能量投入为代价。系统工程就是这样的一套方法：它力争以最小的能量代价控制人造系统的熵，并使其发展聚焦于既定的目标。系统工程的生命周期管理本质目的之一也是为了控制熵，使项目不至于陷入难以控制的混乱状态。 1.2康威定律的魔咒 系统工程中所说的“系统”可以说是“客体系统”，它是以提供产品或服务为目的而人为构造的相互关联的元素的集合。与“客体系统”相对应的是“主体系统”，它是构造客体系统的主体，是人或者组织（企业）。 对著名的康威定律可以理解为，作为客体系统的产品或服务，其架构是主体系统架构的反映。 康威定律提醒我们，要研究如何更有效地构造一个客体系统，必须同时研究需要什么样的主体系统。因为“能量代价”是要由主体系统承担的，而且主体系统的缺陷必然反映在客体系统上。 1.3系统工程推进工作现状 要评估系统工程推进工作的现状，首先要选择评价现状的尺子，也就是要考察系统工程工作的目的和评价标准。 INCOSE系统工程手册4.0版（机械工业出版社）提出“系统工程以提供满足用户需求的高质量产品为目的”，这显然是站在用户视角的观点。如果站在主体系统（企业）视角，应该是“通过提升研发质量和效率、有效控制风险，以提升企业的核心竞争力为目的”。 不考虑代价谈高质量产品是不现实的。企业生存发展是提供高质量产品的一个前提。系统工程有助于使企业（主体系统）的利益与用户的利益达成统一。 基于以上观点提出系统工程工作效果的评价标准：
采用以上标准，可以评估或者自我审视一下本单位或所熟悉的单位系统工程工作效果。目前国内的现状也许不尽如人意。 我们有必要考虑一下这其中的原因，也许包括以下方面：
除了上面提到的，也许还有很多原因。但是笔者认为，关键原因也许是另外两个：方法论体系不完整；主体系统有缺陷。
系统工程是方法论的局部而非必要的整体。不能对方法论“断章取义”地“拿来主义”，应该全面了解先进的方法论体系，按需剪裁和扩展，聚焦于解决我们的问题。另外，需要解决“主体系统”的缺陷。 为了说清楚这两个问题，需要从最基本的概念谈起。INCOSE系统工程手册中说系统工程是“……结构化的研发流程”，那么“流程”是什么呢？也许可以说“流程”是对活动的有序组织。那么，“活动”又是什么呢？也就是说，对于系统研发来说，研发活动是什么？ 研发活动的本质如图1所示，是在问题空间中“认识问题”、“描述问题”和“确认问题” ；在方案空间中“分析问题”、“传递问题”和“解决问题”。 图1 问题空间和解决方案空间 事实上对“什么是研发活动”却有不同的观点，或者可以说存在另外的现实。现实之一是把“部门的业务包”（如图2）作为研发活动。所说的“部门”在某些科研机构中也称为“专业”，两者在本质上是一样的。在项目执行过程中，工作计划总是按照部门逐层分解下达。事实上所谓的“计划”通常是模糊的，不能清晰完整地描述问题空间。 图2 将部门的业务包作为研发活动 用户的真正需要是服务，而服务主要由客体系统的功能承载和体现。将部门的业务包作为研发活动的问题在于，客体系统的功能会被部门之间的界面割裂。部门之间往往既争名夺利又相互推诿。部门之间的业务关系复杂，业务低效，难以界定对问题空间中的“问题”的责任主体。 现实之二是将系统元素（SE）的“描述包”作为研发活动（如图3）。图3解决方案空间椭圆中的方框表示逐级细分的系统元素。提供给用户的客体系统是一个整体，这个整体承载着用户所需要的功能。功能往往是有多个系统元素共同支撑的。将系统元素的描述包作为研发活动，功能（问题）会被系统元素之间的界面割裂。研发过程中在系统元素之间传递数据的工作量巨大，衰减和畸变严重。此处所说的“传递数据”的一种形式是传递需求使用的规范。 图3 将系统元素的描述包作为研发活动 分析了上面两种定义研发活动的情况后，是否可以考虑一个问题：有没有一种理想的情况，将问题空间和解决方案空间中的问题划分为可管理的小块（如图4），将每个“小块”作为一项科研活动，为每个“小块”配置人力资源。这也许是最简单高效的方式。因为每个“小块”都直接“面向服务”或者说对应具体的功能，且块之间的关系是可以依靠一套方法给出明确定义。 图4 将空间划分为“可管理的小块” 可是，如何将问题空间和解决方案空间划分为可管理的小块呢？在讨论这个问题之前，先扒一扒两个概念：面向过程和面向对象。 将“科研流程”视为科研活动以及科研活动的顺序，本质上是面向过程的方法。当科研活动非常复杂时，面向过程的方法是不适用的，而应该增加面向对象的方法。对于这个认识，《大象》一书中有几段非常精彩的陈述：
接下来看看认知域的四个象限（图5）。已知的是有限的，仅仅是一个小角落 ；未知的是无限的，是事物的绝大部分，事实上第三象限是无边界的。面向过程的方法基于这样一个“世界观”假设的前提，即认为事物之间有确定的因果关系，其关系和行为是稳定的、已知的或可知的（即可预测的）。但事实并非如此。当所面对的系统越来越复杂、越来越接近真实的世界时，就会发现面向过程的方法已经无法应付了。面向过程的方法试图将过程和关系定义清楚，并期望系统按照确定的过程和关系运行。但现实世界并非如此，过程和关系往往是不稳定和不确定的。“面向对象的流程”比“面向过程的流程”更适应不确定和不稳定的关系。 图5 认知域 对于软件领域所说的“过程”和“对象”大家都是熟知的了，可是对于科研活动来说的“对象”是什么呢？结合对问题空间和解决方案空间的认识，可以说科研活动的“对象”有三种形态：问题、活动和文件（图6）。 图6 研发活动的对象 系统工程定义了研发流程（图7），但没有定义研发活动及其关系，没解决研发活动的结构化定义问题，这也许是它落地困难的重要原因。
我们就是要尝试通过面向对象的方法将研发活动作结构化定义，为系统工程提供必要的支持。结构化的研发活动对应结构化的设计文件体系，结构化的设计文件体系支持系统工程落地。
说到这里，不得不再讨论另一个重要的概念——结构化。 结构化概念：在对事物按正交维度分类和描述基础上，用一般性方法解决问题的方法。其优势在于：
与结构化方法相对应的“非结构化”则是针对特定事物用特殊方法解决问题的方法。 结构化的优点：
图8 对事物分类的维度 结构化的基础是对事物的分类方法。对事物的分类方法是结构化最重要的基础。 （美国）国防部体系结构框架（DoDAF）可以支持对研发活动的结构化定义。DoDAF中有几句非常重要的描述引用如下：
图9 （美国）国防部体系结构框架 “概念、结构、行为、关系”是对事物分类的四个基本维度（图10）。DoDAF定义的八个视角52个模型是一种细分维度（图11），可以对问题空间作进一步细分，细分为“可管理的小块”。让人们可以在52维空间里上看、下看、左看、右看……，原来每个视图都很简单。 以DoDAF支持系统工程，两者共同构成了更完整的方法论体系。 图10 对事物分类的维度
图11 四维与52维 再回到前面的问题，DoDAF能把问题分解为“可管理的小块”吗？是怎么做到的？图12就是对DoDAF模型对应的“问题的小块”尝试的理解。而图13是与图12对应的DoDAF模型较正式的描述。需要说明的是，图12和图13是笔者基于自己的业务特点所作的理解和剪裁，不必深究其正确性。尤其是各模型中的关联线，笔者本人也认为不是绝对的。实际上笔者认为DoDAF模型之间的关系恰恰体现了并行流程而不是完全串行流程的特点。大型项目往往需要几百几千人多年协作才能完成，如此复杂系统研发工作，怎么可能是完全串行的呢？！
图12 “问题的小块”
图13 DoDAF模型（剪裁）
为了进一步说清楚工程实践中如何操作，笔者妄自“编造”了两个术语：“元文件”和“集成文件”。 对于问题空间中的问题和解决方案空间中的问题，按照结构化方法将这些问题划分为“可管理的小块”，对每一小块的描述就是一份“元文件”。 在系统研制过程中，为了特定利益攸关者使用方便，将元文件打包并作整体描述的文件称为“集成文件”。例如为了开展方案评审，提供给评审专家的方案报告是集成文件；为了向下层分包商传递系统元素的需求，提供给相应分包商的规范也是集成文件。用集合的思想理解元文件和集成文件之间的关系可以表示成图14。
图 14元文件与集成文件的集合 每个DoDAF模型可以对应一类元文件，对应问题的“小块”。元文件全集是对项目定义的完整数据集。集成文件通过引用元文件的形式建立元文件与集成文件之间的追溯关系。一份元文件可以被多份集成文件引用。也就是元文件“一处定义，多次使用”。 设计活动和元文件都依靠DoDAF的各模型组织和描述。结构化的设计活动划分是结构化的元文件体系的基础。每份元文件在“范围”一章均说明对应哪个DoDAF模型，甚至文件的编号中都可以带有DoDAF模型名称，这样就确定了该元文件在整个文件体系中的地位和作用。 可以以“三棵树” （图15）作为“导航地图”组织大部分元文件：
图15 组织元文件的“三棵树”及映射矩阵 设计文件是设计活动的交付物。结构化的设计文件体系等同于结构化的设计活动。构建结构化的设计文件体系，实际上也是构建结构化的设计流程。 这样作的好处是每个设计员：
设计员容易上手。工作成果可非常方便地复用。既利于技术进步，又利于人才成长。对于多项目并行情况下提升工作效率更是意义重大。 元文件“一次定义，多次使用”。结构化的设计文件是可维护且方便维护的；可以方便地组合成集成文件（如组合形成方案报告、分发给成品厂所的规范、用户资料等）；文件更改的影响范围非常清晰，易于传递变更，易于控制状态。 对应“基于模型的系统工程”，“元文件”其实就是模型。 将项目分解为面向对象的研发活动，其积极意义在于，将人或团队的职责部署到问题上，而不是将界面不清的任务部署到“部门和人”上；不是将产品开发责任部署到“部门和人”上。
最后回到讨论的题目，主体系统的研发活动架构，就是那个“系统工程的玻璃笼子”吧？对对象（问题、活动和文件）作结构化分类，是改造主体系统研发活动架构的基础。面向对象配置人力资源（本质上是配置人员的职责而不是配置人员），以此改造研发活动架构。既利于项目推进，又利于技术积累。可应对多项目并行。 最后，有必要强调一下，分类法是组织数据的核心，是重中之重！
|
|
|
