系统生命周期过程 之协议流程组

作者简介 姚轶崭：研究员，长期从事系统工程研究与实践，在企业架构、项目管理、信息安全等领域有非常丰富的实践经验。

一、系统工程认识

（一） INCOSE 手册的系统工程

系统工程是什么？本身如盲人摸象，因其“横断性”，故可渗入各个领域；因其“复杂性”，故说“这是一项系统工程”。虽众所周知，但也众说纷纭。（笔者认为，系统学的“二阶性”是系统工程“横断性”的基础，问题域的“多样性”是系统工程“复杂性”的根源。系统科学是“横断性的二阶科学”，是学科的科学，抽取各门学科中的共性原理；系统工程是“横断性的二阶工程”，是实践的工程，抽取领域工程中的共性方法。）

为何有此一说？系统工程有方法说、管理说、技术说、实践说、建模说等多个维度的解释，都暂且搁置一边，只从辩证思维角度认为：INCOSE 系统工程手册是半部系统工程手册，仅解决了“正确的做事”（Tackling the problem in the right way）问题，而未解决“做正确的事”（Tackling the right problem）的问题。所谓“系统工程”（Systems Engineering）是由“理解系统”（Understanding Systems）+“工程过程”（Engineering Process）两部分组成（图1）。理解系统适合东方的哲学思维，关注于问题本质；工程过程适合西方的工程思维，关注于过程科学；只有东西方思维的辩证交融才构成一部完整的系统工程。但这并不妨碍《INCOSE Systems
Engineering Handbook》在“工程过程”（Engineering Process）领域的权威性，也许 “理解系统”（Understanding Systems）这部分工作已经交给了系统思维和系统科学范畴解决。（注：《INCOSE Systems Engineering Handbook》和《The Guide to the Systems Engineering Body of Knowledge》可结合在一起参考） 。

图1-系统工程认识

正因为侧重于“工程过程”（Engineering Process），INCOSE 系统工程手册是按照过程组织知识点的，知识点由IPOCM 的结构展开，每个过程知识域由输入（I-Input）、处理（P-Process）、输出（O-Output）、控制（C-Control）、机制（M-Mechanism）五个部分组成。而本人认为，这种知识点的组织方式是不够的，各个过程域仅仅是目录罗列，无法构成整体的知识体系（Body of Knowledge）。
为了构成整体的知识体系，需要用系统思维的方式重构系统工程知识，使知识不仅在“过程”中产生，也要在“结构”中体现。“所有模型都是错误的,但有些模型是有用的（All models wrong, but some useful）”。在后续章节中，将尝试建立这些错误的、但也许是有用的模型，以助于大家更好的理解INCOSE 系统工程手册。

（二）组织层面的系统工程

国外的诸多专业认证常常被称作“一英里宽、一英寸深”，INCOSE 的系统工程专业认证Systems Engineering Professional (SEP)也同样如此。INCOSE 系统工程手册中的“协议过程”（Agreement Processes）和“组织的项目使能过程”（Organizational Project Enabling Processes）更是“一英里宽”中的边缘。系统工程中最核心的部分是在技术过程和管理过程，也是IEEE-1220 系列、EIA-632系列的主体，ISO 15288 是把系统工程更泛化，宽度更广（图2）。

图2-系统工程标准（重要）

“协议过程”（Agreement Processes）和“组织的项目使能过程”（Organizational Project Enabling Processes）就是在组织 层面的系统工程知识，由对外的“协议”和对内的“使能”两大过程知识域构成。为了从系统的视角理解ISO 15288 中组织层面的组织协议过程和项目使能过程，可以将此知识结构重构成如下的系统模型（图3）。

图3-组织层面的系统工程知识域

对外的“协议”：协议系统（Agreement Systems）是为目标系统（System of interest）的生命周期活动提供接口的系统，有能 力交换的作用。组织间的系统能力交换通过“协议”流程完成。

对内的“使能”：使能系统（Enabling Systems）是为目标系统（System of interest）的生命周期活动提供支持的系统，有支持服务的作用。组织内的系统能力服务通过“使能”流程提供。

二、组织协议过程

在社会分工细化的今天，“协议（Agreements）”无处不在，更为正式的协议即合同（Contract）。协议存在于两个组织之间，一个组织（采办方/甲方）可以让另一个组织（供应方/乙方）为其提供产品或服务，一个组织往往既是采办方又是供应方。理论上，所有的组织都需要与工业、政府、院校、消费者、合伙伙伴等进行外部关联。协议过程旨在理清与外部的两大接口关系：来自于外部实体的输入（Inputs）和为外部实体提供的输出（Outputs），这些网状的关系即构成“业务运行环境”。采办过程（Acquisition Process）和供应过程（Supply Process）就像是一枚硬币的两面，是从甲乙双方不同的视角陈述同一件事情。

1、目的

采办流程的目的在于获取符合要求的产品或服务，系统工程所关注的采办要比单纯的购买更复杂，牵涉到要求的变化，需要变更管理和配置管理的支持配合。

供应流程的目的在于向采办方提供满足协定需求的产品或服务。大规模生产的产品或服务，市场营销部门（代理人）可代表采办方并建立客户期望。

2、定义

（1）采购人员

采购人员被分为两种：Buyer 和Sourcer。

• 采购员-Buyer：主要从事传统的工作，包括需求与订单的处理、交货期的控制，称为purchasing；

•  供应商发展-Sourcer：更多侧重于市场上技术和成本的变化，负责供应商控制、评估和开发，称为procurement。

（2）采购活动

与采购有关的词有：Purchase，Procurement 和Acquisition，分别将其译为“订单采购、发现采购、系统采办”，从其出现的顺序上可以看出虽然最终都完成了采购的业务，但含义和执行工程是不同的（图4）。

图4-采购活动

• 订单采购-Purchase只是简单的买，完成了“买”的动作和买入了某样物资或服务，侧重于下单，并跟踪订单。订单采购包括申请、批准、填写采购单、订货、及收货。

• 发现采购-Procurement（也叫Sourcing）是根据客户的需求，寻找，发现，评估，审核，发展合格的供应商，一般对应中文是供应商开发或发展，同时也包括新BOM（Bill of Material）报价和谈价的工作。发现采购包括市场调查、厂家调查、合同谈判、及订单采购，偏重于对整体项目的分析，侧重于技术层面，是去寻找和确定符合资质的新供应商或新产品的供应商。

• 系统采办-Acquisition  所代表的意义最广，按美国国防部的定义，包含了设计、开发、生产、装备及维护等等过程，包括所有Purchase和Procurement的过程，再加上从概念到产品开发到维护及服务的一系列活动。  

（3）采购文件

采购文件用于征求潜在卖方的建议书。如果主要依据价格来选择卖方（如购买商业或标准产品时），通常就使用标书、投标或报价等术语。如果主要依据其他考虑（如技术能力或技术方法）来选择卖方，通常就使用诸如建议书的术语。不同类型的采购文件有不同的常用名称，可能包括信息邀请书（RFI）、投标邀标书（IFB）、建议邀请书（RFP）、报价邀请书（RFQ）、投标通知、谈判邀请书以及卖方初始应答邀请书。具体的采购术语可能因行业或采购地点而异。

	信息邀请书RFI REQUEST FOR INFORMATION	报价邀请书RFQ REQUEST FOR QUOTATION	建议邀请书RFP REQUEST FOR PROPOSAL	投标邀标书IFB Invitation for Bid
目的	获得与产品、服务、供应商相关的信息	取得供应商对所需产品、服务或服务的承诺	要求供应商对需求提出最好解决方案的建议	为所有的供应商做出最好的方案而提供平等的机会
使用条件	适用于具体申请之前	对所需要的物料或服务的具体要求已经明确	用于评估供应商，或采购方不清楚的流程、质量、服务、准标或其他元素	用于定价比价高的物料，或者该物料存在最低价格
灵活性	非正式的、不是招标	正式的、提出具体要求	采购方可以开始谈判、信息收集，在最佳来源确定前，不承诺一定采购	对采购和供应双方都有约束
结果	目录、价格表和产品信息	比较供应商提交的方案	可供选择的大量潜在解决方案	最好的和最终的方案
优点	简单、快捷	供应商受限于报价的承诺，而采购方可以就所有问题进行谈判	采购方可以对提交的方案中的任何问题与某一个或所有的供应商进行谈判	正式的流程。各招标或流程文件都是可比较的
缺点	没有确定目标，仍然需要RFQ或IFB	如果没有很好地准备报价申请书请求，各个供应商的投标可能无法比较	如果允许一个供应商修改方案，就必须允许所有的投标者修改方案	因为其他方法为采购提供了更多的灵活性。最好不使用这个方法

• 信息邀请书（RFI）- REQUEST FOR INFORMATION (RFI) 信息邀请书用来取得产品，服务，或供应商一般资讯的请求文件。这是一个资讯的要求，并不能成为对供应商或采购的约束，通常使用在请购之前。

• 建议邀请书（RFP）- REQUEST FOR PROPOSAL (RFP) 建议邀请书用于采购方要求供应商提供问题的解决方案的建议，允许采购人员在没有发现最佳资源之前，还没有决定向谁采购时，可以去广泛地搜集供应商信息并进行谈判。

• 报价邀请书（RFQ）-XREQUEST FOR QUOTATION (RFQ) 报价邀请书通常被认为与RFP相同，但在某些组织中，RFQ则被用于取得为计划目的之约略资讯，此时在要求中需明确说明。

• 投标邀标书（IFB）-Invitation for Bid (IFB) 投标邀请书为所有供应商报价提供他们最佳方案的平等的机会。因为招标流程会约束了采购方和供应方，IFB只有在满足以下条件时才可以使用：已经清楚地定义了规范书和工作种说明书（Statement Of Work）；采购金额足够大；法规或企业规程条例强制的要求；其他方法不适合。因为正式的招标流程对采购方和供应方来说都是花费比较高的，所以当其他方法可以提供必要的信息时，就不应该使用IFB方法。

3、流程

一般使用顺序：都使用在采购规划阶段，RFI：征求供应商意见，以使需求明确化，如果需求很明确，则用RFP，征求供应商的建议书（Proposal）, 招标或要求供应商报价前，使用RFQ，以作为招标底价及比价的参考（前提是给所有供应商的报价格式都一样的，如果不一样，则无法比较，也失去了意义），在这些过程中，能够降低需求不明确及预算不精确的风险。

通常，公司中的合同部门（或政府中的合同官员）负责谈判合同。总指挥/项目经理很少领衔合同谈判，然而领衔合同谈判者只有在项目经理批准之后才同意对范围、成本或进度作出任何更改。系统工程师则需要为总指挥谈判提供风险/变更评估、备选方案，明确验收标准（Criteria）等支持。

图5-系统工程师在采办中的作用

系统工程师在采办中的作用如图5所示，系统工程师要为采办提供干系人期望（Need）和确认准则（Validation），技术需求规格说明（Requirements）和验证准则（Verification），可研方案（Feasible Study）和验收矩阵（V&V Matrix）,以及工作要求说明（SOW）和系统任务分解（WBS）；沿着采办流程，项目经理需要将系统工程师提供的信息转化为采办流程中的RFx文档，分别是信息邀请书（RFI）、建议邀请书（RFP）、报价邀请书（RFQ）和投标邀标书（IFB）。