业务的流程被定义为若干不同的业务用例,其中每一个都代表业务中的一个具体工作流程。业务用例定义当执行业务用例时业务中应发生什么;它描述了为特定的业务参与者产生有价值的结果的一系列操作的性能。业务流程产生业务价值或降低业务成本。
旅客可以单独旅行或随团旅行。当随团旅行时,旅客会伴有一个导游。
业务用例描述“业务中执行的一系列操作,它为业务的单个参与者产生具有可见价值的结果”。因此,从单个参与者的角度,业务用例定义的是产生所需结果的完整工作流程。这类似于人们常说的“业务流程”,但“业务用例”的定义更为精确。
业务用例概念的定义包含若干关键字,它们对于了解什么是业务用例是基本的:
-
业务用例实例,上面的定义实际上描述了某个特定的业务工作流程,即实例。现实中,有大量可能的工作流程,它们中的许多非常相似。
要使用例模型能被理解,请将类似的工作流程分组到一个业务用例(指对象模型的“类”)中。确定和描述业务用例意味着确定和描述类(如业务用例),而不是单个的用例实例。因此,业务用例将定义决策点和备选流;采用的途径将取决于业务的状态、业务事件和业务参与者的输入。
-
单个参与者 - 参与者可能是找到正确的业务用例的真正关键。从单个参与者(或实际上是参与者的实例)开始有助于避免过大或过于复杂的业务用例。
当确定合适的参与者时,请先至少尝试指定两三个将充当所讨论的参与者的不同的人,然后谨慎地评估每个人所需要的支持。例如,假设您最初确定了一个称为“客户”的参与者。
稍后,当您更深入地观察每个个人客户所需的支持时,您可能发现三种大有不同的客户:产品的普通“用户”、“购买者”和“评估者”,他们能够将该产品与其竞争产品相比较。他们中的每一种都可能需要一个独立的业务用例,因为他们代表在业务中可以扮演的不同角色。
-
具有可见价值的结果 - 这种表达对于确定业务用例的正确范围(不应过小或过大)非常重要。声明业务用例应提供具有可见价值的结果(即,可以感知和度量)可以帮助您找到一个完整的流程,并避免过小的业务用例。
好的业务用例可以帮助参与者执行具有可确定的价值的任务。对成功执行的业务用例提供一个价格是可能的。过小的业务用例的范围将有限,因此再设计的可能也很小。
-
在业务中 -“在业务中执行的操作”不仅表示业务向参与者提供业务用例,还表示该业务用例仅包括在业务中实际执行的操作。不包含在其他地方执行的支持工作。
-
操作 - 操作在从参与者向业务请求时调用或在某个时间点调用。操作包含内部任务和决策,以及对调用的参与者或其他参与者的请求。
业务用例指定主体业务与其(外部)业务参与者之间的交互以及它们对业务的影响 - 业务用例的执行可以更改业务的状态(从而可以更改业务响应以后的事件或交互的方式),业务用例必须指定这些状态更改。
业务直接且显式地对环境所提供的是服务(从这个角度而言,业务仅仅是顶级业务系统,因此,应该包括其资源并将明确定义的服务提供给其环境 - 请参阅指南:业务系统),并且,如“业务用例”中所述,业务参与者和业务之间的交互是通过调用一个或多个这类服务而发生的。请注意,对于开发新业务(例如,业务创建)或更改业务而言,业务用例是确定业务必须提供的服务的一个方法。
收集的业务用例集合构成使用业务的所有可能方式。另请参阅指南:业务用例模型。
在用例驱动的业务建模项目中,您开发业务的两个视图。
业务用例本身提供了业务的外部视图,它定义了对于业务来说,执行什么对于向参与者交付所需的结果是重要的。它还定义了在执行业务用例时,业务和参与者之间应该有什么交互(业务参与者 - 业务输入 -
响应顺序)。当您在确定在每个业务用例中应进行什么操作并达成一致时,必须开发这样一个视图。业务用例的集合提供了对业务的概述,这对于通知员工业务的不同部分正在做什么以及期望产生什么结果非常有用。业务用例描述进行此项工作,而不提及业务的实际内部结构。请注意,业务用例还应描述在执行业务时业务中发生的任何状态更改,以及出现或接收到的任何重要业务事件。业务用例不规定如何确定业务状态并在内部保持该业务状态,或者业务事件如何在内部传送,而指定了状态更改是
什么以及重要业务事件是什么,以能够提供所需业务行为的完整视图。
另一方面,业务用例实现提供了业务用例的内部视图,它定义了为了实现相同的所需结果,应如何组织和执行工作。实现包括执行业务用例中涉及的业务工作者和业务实体以及执行该工作所需的它们之间的关系。必须开发此类视图以确定必须如何组织每个业务用例中的工作以实现所需结果并达成一致。业务设计人员确保对于业务状态更改和业务事件而言,业务用例中的规定(
什么)和业务用例实现中的实现(如何)之间应存在一致映射,以在所有业务用例中获得预期行为。
业务用例的这两个视图都主要用于业务内的人 - 外部视图用于在业务用例外工作的人,内部视图用于在业务用例内工作的人。
当一个业务操作时,您将发现您可以确定几乎无限数目的独立工作流程。用例实例只是一个具体的工作流程或场景。它对应于若干协作业务成员以对象模型中定义的角色执行的工作,而不是任何特定的业务成员或该成员正在扮演的任何角色。
业务用例是您通常处理以使用例模型可以理解并避免陷于细节的东西。它代表带有类似但通常不完全相同的工作流程的若干业务用例实例的并集。
通常,能够充当某个角色的雇员将在若干不同业务用例的实例中充当该角色。
示例:
在机场检入台,两个业务用例(“个人检入”和“团体检入”)都要求检入台处的雇员有相同的能力,以及可以访问关于某次起飞的相同信息。因此,这两个用例可以并应该使用相同的“检入员”业务工作者和“起飞”实体设计。
有时难以确定一项服务是一个还是若干业务用例。将业务用例的定义应用到机场检入流程。旅客将其机票和行李交给检入员,检入员为该旅客寻找一个座位,打印一个登机牌并开始处理行李。如果该旅客的行李正常,检入员会打印行李标签和客户取货单,并通过将这个标签贴在行李上、向旅客提供客户取货单和登机牌而终止这个业务用例。如果该行李形状特殊或内容特殊,以至于不能正常运输,则旅客必须将其带到一个特殊行李台处。如果行李很重,旅客必须继续到机场售票厅为其付款,因为检入员不管钱。
您是否需要在检入台有一个业务用例,在特殊行李台有另一个,并在售票厅有第三个呢?还是您只需要一个单一的业务用例呢?当然,这个事务涉及三个不同类型的操作。但是问题是,如果一个带有特殊行李的旅客不进行其他业务用例,则它们中的任何一个对该旅客有任何价值吗?没有,只有整个过程(从旅客走近检入台到他支付了额外费用)具有价值(并对该旅客有意义)。因此,涉及这三个不同柜台的完整过程是一个完整的使用案例
- 一个业务用例。
除了此标准,将密切相关的服务的描述放在一起具有实用价值,这样您可以同时复审它们、一起修改它们、一起测试它们、为它们写手册并通常将它们作为一个单元管理。
还请注意两个独立的业务用例可以有类似的开始。
示例:
在一家保险公司中,业务用例“处理索赔”和“处理请求”都在某人(一个参与者)联系索赔处理员时开始。索赔处理员和该参与者交换某些信息以弄清楚该参与者是在提出索赔还是在请求某种信息。然后(并且只能是然后)才可能确定执行哪个业务用例。尽管这两个业务用例具有类似的开始,但它们没有任何联系。
业务用例的名称应该表达当执行该业务用例的实例时发生什么。因此,名称的形式应是主动的,通常通过动词的动名词形式(Checking-in)或动词和名词一起来描述。
这些名称可以从外部角度或内部角度描述业务用例中的任务,例如下订单或接收订单。尽管一个业务用例描述业务内发生什么,但是通常从业务用例的主要参与者的观点命名该业务用例是最自然的。一旦您决定了在您的用例中使用哪种样式,您应对业务模型中的所有业务用例遵循同一规则。
业务用例的目标应至少从两个角度指定:
-
对于与业务流程进行交互的业务参与者,指定他们期望从业务中获得的价值(外部目标)。
-
从执行业务流程的组织的角度,定义使该业务流程就位的目标是什么以及您希望通过执行它而实现什么(内部目标)。
一些常见的度量类别是:
-
时间 - 执行工作流程或部分工作流程所需的大致时间。
-
成本 - 执行工作流程或工作流程的一部分的成本的近似值。
-
质量 - 例如,“当产品离开生产线时,有缺陷的产品不应超过 2%”。
一个主要的挑战是了解哪些场景(业务用例实例)与度量有关。要使用的标准是场景的频率或场景的业务相关性。如果您可以确定工作流程的某个特定部分很重要,就可以通过仅度量该子流程的成本或时间来减少工作。
多数工作流程可以被视为若干子流程,它们一起形成整个流程。有时,业务中的若干业务用例具有一个公共的子流程,或同一子流程出现在一个业务用例中的不同部分中。如果此公共行为的量很大,它应由相同的业务工作者执行。
如果一个子流程的量很大、在若干业务用例中公用并形成独立和自然分隔的部分,则将此行为分割出来成为独立的业务用例会使模型更清楚。这时,此新业务用例包含在初始用例中(请参阅指南:业务用例模型中的包含关系)、初始用例的扩展用例中(请参阅指南:业务用例模型中的扩展关系)或者初始用例的父用例中(请参阅指南:业务用例模型中的用例泛化关系)。
示例:
在机场检入台,两个业务用例(“个人检入”和“团体检入”)都使用同一过程处理个人旅客的行李。因为该子流程独立于票务处理,并在逻辑上有联系,所以它在业务用例“行李处理”中独立建模。
可以使用活动图使业务用例的工作流程可见,请参阅指南:业务用例模型中的活动图。
关于构造和描述业务用例工作流程的更多信息,请参阅指南:用例中关于事件流的讨论。
下面是在一个销售为每个个人客户配置的解决方案的组织中,业务用例“建议书流程”的工作流程的描述。在技术:业务用例模型中的活动图中关于“使用示例”的那一节中,可以找到一个显示该工作流程的活动图示例。
1. 基本工作流程
1.1. 初始联系
该流程以客户和公司之间的初始联系作为开始。这可能以下列方式之一发生:
-
客户以查询或一组需求联系公司
-
公司确定它有能为客户增加价值并为公司增加收入的产品。
公司与客户进行交互可确定:
-
客户联系人,
-
公司联系人,
-
是否对公司来说是新的客户,
-
关于与此协议相关的建议书或投标状况的任何竞争对手信息。
1.2. 初始机会工作
本节有两个主要目的:
步骤“收集初步客户需求”、“创建销售计划(可选)”和“执行机会分析”可以迭代的方式执行,并可以在某种程度上并行执行。
1.2.1 收集初步客户需求
通过进行以下工作收集产品需求和客户业务需求:
-
询问客户
-
考虑所有客户输入
-
执行初步现场调查(可选)
-
查看任何可用的客户信息
完整的一组需求将包含:
-
对技术的选择(如果客户想要了解替代选项,可以是若干个)
-
任何产品首选项
-
功能需求(市场分析)
-
构建结构和环境特征
-
人口统计特征
-
机动性/容量
-
网络增长预测
-
已安装的基本信息
1.2.2 创建销售计划(可选)
公司与客户合作确定要如何建议满足客户需求的解决方案。创建的此文档称为销售计划,并包含潜在解决方案的网络和交换机特征。也讨论公司及其网络的战略定位,这样我们可以为将来的需求而做好准备。
然后,与客户一起复审此销售计划以求精确和完整。然后,当确定建议哪些产品、市场套装和订单商品以及在汇总建议时做哪些假设时,它将在整个建议书流程中用作指南。
1.2.3 执行机会分析
公司将获悉潜在解决方案的高抽象级别的价格和成本。这样做是为了理解这个机会的潜在价值,而不是向客户提供精确的金额。
然后公司查看客户需求以确定:
-
机会中的风险(产品可用性、竞争、客户风险)
-
与收入相比较的成本
-
机会类型(简单、复杂等)
-
销售概率
-
预期销售规模
-
估计进度
基于此评估,公司决定是否继续该机会。
1.3. 制定建议书项目计划
公司将制定一个创建和提出建议书的计划。该计划将包含分配给个人的、完成建议书一部分的任务。
1.4. 制定交付项目计划
公司基于以下信息来制定一个交付解决方案的暂定项目计划:
-
客户需求中的时间线
-
资源可用性
-
工厂容量
-
新产品可用性
-
第三方产品的可用性
此项目计划将用于将来的工厂规划。
此外,此项目计划将在“报价流程”中更新和修改。
1.5. 准备报价
该流程在业务用例“报价流程”中详细定义,并包含了该流程。
“报价流程”的结果是经过设计的可以有多个级别的确定性的解决方案,并且带有价格。
1.6. 编辑其他信息
公司编辑信息,以便对可能是客户业务需求的一部分的任何查询(通常关于将来的产品开发)作出响应。这也可以包含公司认为客户应该知道的信息。这些查询通常有以下类型:
1.7. 分析和完成建议书
公司编写包含以下各项的建议书:
-
报价
-
市场营销文献(现成)
-
产品信息(现成)
-
融资条款和条件
-
进度安排信息
-
将财务分析上滚到建议书级别
-
客户与公司的处罚与责任
-
法律“环境”声明
-
在建议书中创建解决方案时所做的任何假设
1.8. 交付建议书
公司对客户提供/提出上述信息。
1.9. 获得客户决策
客户将提供对建议书的反馈。公司获得客户对建议书内报价的同意。此类同意的格式可能因解决方案的特点和客户是谁而异。
它可能是:
-
经签署的购买订单
-
客户将提交购买订单的口头协议
-
经签署的合同
-
口头协议
-
当没有决策和有效性过期时,会出现负面的决策
2. 备选工作流程
2.1. 放弃商机
如果在 1.2. 中,如果放弃该商机,则可以采取以下措施:
-
完全放弃
-
尝试与其他供应商建立合资公司
-
重定向到其他区域
-
将该请求传递到另一经销商/供应商
-
尝试更改客户需求
2.2. 无法满足客户需求
如果在“执行机会分析”或“准备报价”中,公司无法提出满足客户需求的解决方案,则可以采取以下措施:
-
建议另一个制造商的设备
-
重新评估客户需求
-
联系公司以了解将来的产品
-
尝试更改客户需求
-
决定开发新产品
-
寻求合资公司或供应商
-
寻求融资的替代形式
-
应用不同的折扣策略
2.3. 关键信息未知
如果在“建议书流程”的任何时间,公司确定一些关键信息未知或不可用,则其进行以下操作之一:
如果做出任何假设,则将它们记录下来并作为建议书的附件提供给客户。
2.4. 新的/不完整的或不正确的一般客户概要信息
如果公司确定一般客户概要信息由于某种原因不正确,则可以采取以下措施。
-
如果客户是新的,则协商一个协议
-
包含/确定客户首选项
-
确定已经安装的基础
-
请求对记录的更新
业务用例的可能性应反映您可能在流程或在范围方面对该业务用例进行改进的可能性。请参阅您为该业务用例指定的标准。
扩展点展开业务用例,使其有可能扩展。它具有一个名称和对业务用例工作流程中一个或多个位置的引用的列表。
另请参阅指南:业务用例模型中的扩展关系。
-
其名称和简短描述清晰并易于理解(即使对业务建模团队之外的人员)。
-
从外部(参与者的)角度看,每个业务用例都是完整的。例如,保险公司中业务用例“处理索赔”在客户提出索赔时开始。除非“处理索赔”业务用例包含保险公司向客户提供的关于决策的通知和(如果适用)补偿支付,否则该业务用例是不完整的。
-
每个业务用例通常涉及至少一个参与者。业务用例是由参与者启动的,它们与参与者交互以执行任务并交付结果。
-
支持用例不与参与者交互是有可能的,但不常见。如果业务用例是由内部事件启动的,并且不必与参与者交互以执行它的任务,则属于这种情况。
这看起来似乎与用例的 UML 定义相反,请参阅指南:业务用例模型中描述“内部业务用例”的那一节来弄清这一点。
-
它必须清晰并易于理解(即使对业务建模团队之外的人员)。
-
它描述工作流程,而不只是该业务用例的目的。
-
它仅描述业务内部的那些任务。
-
它描述业务用例中所有可能的任务。例如,如果满足一个条件会发生什么,以及如果没有满足会发生什么。
-
它不提及不与其通信的参与者。如果提及其他参与者,可能会使该描述难于理解和维护。
-
它仅描述属于它的那些任务,而不是在与它并行工作的其他业务用例中进行的任务。
-
它不提及与其没有关系的其他业务用例。如果该业务用例在能够开始之前,需要在业务中存在一些结果,则这应被描述为前置条件。前置条件不应对创建该结果的业务用例有任何引用。
-
它指示为业务用例而描述的任何任务的顺序是否不固定。
-
它是结构化的,以使其易于阅读和理解。
-
该描述清晰地描述工作流程的开始和结束。
-
每个扩展关系都清晰地描述,使如何以及何时插入该业务用例很显而易见。
-
它是充实的。记住,一个具体的业务用例及其抽象的业务用例都必须易于阅读。因此,一个抽象业务用例不应过小。如果某个抽象的业务用例不充实,则应除去它,并在受影响的具体业务用例中描述其任务。
-
它包含在逻辑上相关的任务。
-
它因特定原因而存在。抽象的业务用例应包含以下三种活动中的任何一种:跨多个业务用例的公共任务;可选任务;或者非常重要以致于您想在模型中着重描述的任务。
|