合同的签订在线下进行，EAS系统只负责维护合同信息，并将合同扫描版上传到系统中归档，以便市场人员查询合同信息，因此，业务流程中的签订合同活动并未出现在合同管理的业务服务图中。市场人员创建合同的目的其实是归档，以便相关人员（主要是市场人员）查询，故而“归档合同”体现了该业务服务的服务价值。
需求订单管理的业务服务图如图20-11所示。
在梳理客户合作流程的业务服务时，我发现几个领域概念的定义并不清晰：合同、市场需求客户需求和需求订单之间的关系是什么？存在什么样的区别？
当我们发现有多个混乱的领域概念需要澄清时，就要建立统一语言，就这些领域概念达成一致共识。
通过与市场人员的交流，我发现市场部对这些概念的认识也是模糊不清的，甚至在很多场景中交替使用这些概念。在交谈过程中，他们有时还提到“市场需求订单”这个概念。例如在描写市场需求时，他们会提到“录入市场需求”，但同时又会提到“跟踪市场需求订单”和“查询市场需求订单”。在讨论“客户需求”时，他们提到了需要为客户需求指定“承担者”，在讨论“市场需求”时却并未提及这一功能。这似乎是“客户需求”与“市场需求”之间的区别。对于“合同”的理解，他们一致认为这是一个法律概念，等同于作为乙方集团或子公司和作为甲方的客户签订的合作协议，并以合同要件的形式存在。
鉴于这些概念存在诸多歧义，我们和市场人员一起梳理统一语言，一致认为需要引入“订单”（order）的概念。订单不是需求（无论是客户需求还是市场需求）。它借鉴了电商系统中的订单概念，用于描述市场部与客户达成的合作意向。每个合作意向可以包含多个客户需求，相当于订单中的订单项。例如，同一个客户可能提出3条客户需求：
（1）需要5名高级Java程序员、10名中级程序员；
（2）需要8名初级.NET程序员；
（3）需要开发一个OA系统。
这3条客户需求组成了一个订单。一个订单到底包含哪几个客户需求，取决于市场部与客户洽谈合作的业务背景。
引入订单概念后，市场需求与客户需求的区别也就一目了然了。市场需求是市场部售前人员了解到的需求，并未经过评估；公司也不知道能否满足需求，以及该需求是否值得去做。这也是市场需求无须指定“需求承担者”的原因。市场需求在经过各子公司的评估以及财务人员的审核后，就可以得到细化，并在与客户充分沟通后，形成订单。每一条市场需求通过评估，转换为订单中的客户需求。
我们仍然保留了“合同”的概念。“合同”领域概念与真实世界的“合同”法律概念相对应。它与订单存在相关性，但本质上并不相同。例如，一个订单中的每个客户需求可以由不同的子公司来承担，但合同却规定只能有一个甲方和一个乙方。订单没有合同需要的那些法律条款。未签订的合同内容确实有很大部分来自订单的内容，但也只是商务合作内容的一部分而已。在确定了订单后，市场部人员可以跟踪订单的状态，并且在订单状态发生变更时，修改对应的合同状态，但合同的状态与订单的状态并不一致。
在全局分析阶段执行业务需求工作流时，一定要使用统一语言。我们通过业务服务图将业务服务可视化后，对于每一个可能产生歧义的领域概念，一定要大声说出来，及时消除分歧与误解，形成团队内部的统一语言。
（2）项目管理
当项目管理人员（通常为指定该项目的项目经理）开始发起项目立项的服务请求时，就形成了从立项到结项一个完整的项目管理流程，其服务蓝图展现如图20-12所示。
项目管理流程由项目管理人员提交立项申请开始，从管理角度经历了一个项目的完整生命周期。项目管理人员扮演了服务蓝图的客户角色，整个流程的各个阶段都是为项目管理人员服务的。诸如子公司、项目管理部、项目成员和服务中心等只参与项目管理流程，提供交互或支撑行为。
项目管理流程为项目管理人员提供了业务价值。如果要体现目标系统为项目成员提供的业务价值，就需要将项目成员当作服务蓝图的客户，思考它的客户旅程，例如处理迭代问题的流程。可以单独为这个流程绘制服务蓝图。由于视角不同，参与角色的身份也会发生变化。
项目管理流程根据业务目标的不同，分成了4个业务场景：项目管理、项目成员管理、项目计划管理和问题管理。此外，服务中心对硬件资源的分配属于项目管理场景的支持场景，也需要考虑。
在项目管理流程中，同为项目管理目标的业务场景被拆分到首尾两个阶段。在确定项目管理场景的业务服务图时，需要将这两个阶段的业务服务统一，形成图20-13所示的项目管理业务服务图。
服务中心对硬件资源的分配支持了项目立项活动，为整个项目的项目组分配了资源，作为一种支撑活动放在一个单独的业务场景中。其业务服务图如图20-14所示。
