对业务用例和参与者建模的主要目的是描述外部代理、(重要的是还有)客户和合作伙伴如何使用业务。 可以显示直接关系到客户或合作伙伴的任务以及间接关系到外部当事方的支持或管理任务。
模型用业务用例(它们与通常所称的“流程”相对应)来描述了业务。
办理登机手续柜台处的参与者和用例。
查看业务中的任务时,您至少能够确定对应于三种业务用例的三种工作:
-
核心 - 它们是提供价值链的对外业务用例,例如,购买产品。
-
管理 - 它们是协调价值链的内部业务用例,例如,策略规划。
-
支持 - 它们是支持价值链的内部业务用例,例如,采购原材料。
我们会在稍后详细描述“内部业务用例”的意义和说明。
通常,管理类型的业务用例概述 CEO 和业务用例中工作人员之间的关系。它还描述如何开发和实例化(启动)业务用例。
在此图例中,餐厅的核心业务用例是销售和提供餐饮,支持业务用例是进货。
注意:您认定的核心业务用例有时在另一业务中可能是支持业务用例。例如,软件开发公司中,软件开发是核心业务用例,但是在银行或保险公司中,它会被分类为支持业务用例。请注意,如果您对软件开发业务建模,将要开发的许多详细业务用例不会出现在银行最顶级的业务用例级别中(也就是说,这些详细业务用例的出现是为了开发它自己的软件),甚至也不会作为支持业务用例而出现。它们可以在以后作为下级用例出现(请参阅概念:对大型组织建模)。在银行的这个级别,您可能希望只看见反映银行的策略和目标的支持业务用例,其中某个用例很可能是“运作软件开发业务单位”。
若干不同的业务用例的实例以及单个业务用例的若干实例通常并行执行。用例实例可遵循的路径数目可能近乎无穷。这些不同的路径代表可供工作流程描述中的用例实例使用的选项。根据特定事件或事实,用例实例可沿着几条可能路径中指示的某一条路径继续,例如:
对业务用例建模时,您可以假设用例实例可在不发生冲突的情况下同时处于活动状态。在业务开发的这个阶段,您应关注业务应该做什么。稍后,在您尝试了解事物在业务中如何运作的这一阶段的业务用例实现建模过程中解决潜在的资源冲突。或者,可以在新组织的实施过程中解决这些问题,例如,通过增加能够执行关键任务的员工的数量来解决这些问题。
每个核心业务用例必须与一个业务参与者建立相互的通信关系。该规则强化了必须围绕业务用户请求的服务来构建业务这一目标。若您的业务用例模型包含无人请求的核心业务用例,即是警告您该模型存在问题。
可定期触发业务用例,或是长期运行业务用例;监视功能是后者的一个示例。甚至这些业务用例包含最初启动它们并期望从它们获得不同的服务的业务参与者。否则,它们就不属于业务的一部分了。尽管其他的业务用例不是由业务参与者明确启动的,但是它们也为业务参与者生成结果。例如,对分发广泛的产品的开发很少是由某个可确认的客户启动的。相反,对新产品的需求是从市场研究和许多用户的累积需求认识到的。
管理和支持业务用例(即上面所描述的内部业务用例)不一定要与业务参与者相关,尽管它们通常具有某种外部联系。例如,管理业务用例可能将业务所有者或董事会作为其业务参与者。
假设“用例”代表某人或某物与业务的交互,并且会提供价值,则此时没有参与者的业务用例看起来就很奇怪,但您可以将这类业务用例当作没有业务参与者的业务用例的扩展(可能是概念性的)。 指南:业务用例模型中的扩展关系中讨论了显式扩展关系的使用,但此处的基本(扩展)业务用例可能是概念性的,您可以选择不对它建模。此时,管理和支持业务用例是此概念性基本用例的扩展,由开展业务过程中出现的条件(产生工作产品:业务事件)触发。按照这种方法,就不再需要引入人员业务参与者,但您不得不考虑支持和管理业务用例如何增值。
由于抽象的业务用例从不自行实例化(启动),所以它们不需要业务参与者。
业务流程是业务用以执行工作的载体。由于很难将业务策略直接转换为行动,这就需要其他的因素。这个其他的因素就是业务目标;业务目标通过朝着最终业务目标(业务构想)在组织的所有级别上操纵行动,来确保业务流程执行业务策略。
出于这个理由,每个业务用例至少应支持一个业务目标。在不同级别上将策略转换为目标将提供具体的、可评估的目标,业务流程可直接支持这些目标。在目标和流程之间定义支持关系将确保业务流程与业务策略保持一致。这还有助于查找正确级别的业务用例,而通常是很难确定的。仅有一个直接支持企业战略目标的业务用例(例如,获取利润)因过于复杂和麻烦而无法将它建模为一组任务。另一方面,用于组织中每个单个的操作任务的、单独的业务用例(例如“来电转移”或“预定会议室”用例)将产生过多的业务用例,以至于没法理解。定义业务用例所支持的业务目标将指出业务用例是“过高”还是“过低”。
当业务用例明确支持一个或多个业务目标时,用数量来表示业务用例的价值就变得较为容易了。可以评估业务用例的结果对实现目标所作的贡献。也可监视业务用例的性能以提供价值与成本的客观比较。
这些关系的存在有助于区分业务用例的优先顺序。支持许多业务目标的业务用例或重要而有风险的业务用例最有可能被认为在体系结构方面非常重要。许多目标还可能涉及不必要的高度复杂。若某个业务用例支持许多不同的目标,那么极有可能出现冲突情况。在这些用例中,可能无法明确哪些目标占主导地位,从而导致低效行动。
业务用例的类别(核心、支持或管理)并不直接决定它所支持的业务目标的类型。虽然类别确实提供某种指导,但是业务策略将最终决定某个特定业务用例所支持的业务目标。例如,对采用积极增长策略的企业而言,“市场”和“销售产品”业务用例可能支持“竞争价格”业务目标。数年后,这家企业可能会将客户满意度和客户保留作为目标,借此希望使企业在这些产品和市场上的投资最大化。“市场”和“销售产品”业务用例就可能必须支持(差别极大的)“优质”这一业务目标。请参阅指南:业务目标以获取关于对业务目标建模的更多信息。
例如,请考虑在指南:业务目标中用作示例的大型家具店。这样一间家具连锁店的“业务用例模型”可能如下所示:
客户可选择产品,从与展厅连在一起的仓库中提取产品然后付款。可退回有缺陷的产品。“确定客户需求”这一业务用例通常被称为“市场研究”。一旦找到适宜的产品,即推出该产品,“销售商”就变成了“供应商”。尽管“产品销售”是单独的业务用例(如上图所示)还是属于“市场研究”的一部分仍是个有争议的话题,但是必须对产品销售进行监视。如果我们将上述业务用例映射到指南:业务目标中所描述的业务目标,则会产生以下内容:
“查找适宜的产品”业务用例支持略有冲突的业务目标。必须明确如何权衡价格和质量,以确保同时满足两个业务目标。若按退回的缺陷产品的数目(或百分比)评估产品质量,那么就必须确定造成缺陷的原因,以追溯到供应商。例如,可能是由于交付团队造成产品损坏而使交付给客户的许多产品被退回。但是,若仅对交付次数进行评估,就无法揭示交付的质量。
“支付货款”业务用例可能支持“付款方式”而非“低定价”,这是由于定价是在(单独的)“查找适宜产品”业务用例过程中确定的。
在某些公司中,许多业务用例不支持业务目标。这可能是将“监视销售”(例如)合并到“确定客户需求”中的原因,因为“监视销售”不直接支持任何业务目标。然而,由于缺乏对业务目标的支持可预示应使业务目标更具体,所以不应太仓促地做出这样的合并。在最糟糕的情况下,“监视销售”将提供对“确定客户需求”的输入。
“交付产品”业务用例支持“交付时间”业务目标。不应让客户长时间等待交付他们选购的产品。考虑如何实现该目标可能将提供某些基本的、新的观点。例如,城市的地铁可连接仓库和住宅,它能以每小时 100
英里的速度在客户到家之前将产品快速运抵客户住宅!虽然这是不切实际的,但是这样的头脑风暴经常产生关于改进业务的许多构想。
以下举例说明了考虑业务目标可如何揭示那些看起来普通的业务用例的重要性。假设许多客户在进餐时间选购商品。由于一个业务目标是改进设施质量,另一个是吸引客户,我们可能决定开一家餐厅,让客户在购物之前或之后可在此享用快餐。以下显示了支持该目标的业务用例“进餐”。结果可能餐厅成了业务的主要吸引因素之一!
从上图中,我们还会发现调整业务边界的影响。在此,引入了一个新的业务参与者,即“承运人”,是负责从仓库提取产品并将它们交付给客户的伙伴。可能该方法让我们可以最小化交付时间,而这正是业务目标之一。
构建业务用例模型的主要理由有三个:
-
使业务用例更易于理解
-
复用多个业务用例共享的部分工作流程
-
使业务用例模型更易于维护
为构建业务用例,我们有三种关系。您将使用这些关系来分解出业务用例的某些部分,这些部分可在其他业务用例中重复使用,或者是业务用例的专门化或选项。代表修改的业务用例被称为附加用例。被修改的业务用例被称为基本用例。
-
若基本用例的某个部分代表了某种功能(业务用例只依赖于该功能的结果而非用于产生结果的方法),您就可以将该部分分解出来作为附加用例。这个补充明确包含在基本用例中,二者属于包含关系。另请参阅指南:业务用例模型中的包含关系。
-
若基本用例的某个部分是可选的,或对于理解用例的主要目的不是必需的,您就可以将此部分分解出来作为另一个用例,以简化基本用例的结构。这个补充隐含在基本用例中,二者属于扩展关系。另请参阅指南:业务用例模型中的扩展关系。
-
若某些业务用例在行为和结构上存在共同性,而在目的上存在相似性,可将它们共同的部分分解出来作为一个基本用例(父用例),该基本用例被附加用例(子用例)继承。子用例可以在从父用例继承而来的结构中插入新行为和修改现有行为。另请参阅指南:业务用例模型中的用例泛化关系。
上图显示了参与者、用例和办理登机手续柜台。在此我们还显示包含用例“行李处理”和扩展用例“办理登机手续”。
可以使用参与者泛化关系显示参与者如何作为相互的专门化情况。另请参阅指南:业务用例模型中的参与者泛化关系。
另请参阅指南:用例模型中关于构建系统用例的讨论。
特别是在开发业务模型只是为了采取措施促进软件工程项目的发展时,必须小心地对业务建模工作进行界定。这种情况下,即使您仅对业务流程的某个子集进行建模,也很少值得横跨整个组织。为保持工作重点和产生符合期望值的结果,应将整个公司的某个部分视为“业务系统”。您选择的这部分应该是可能直接使用要构建的系统的那部分。您决定作为模型外部部分进行处理的、组织的那些部分可被描述为业务参与者。
示例:
公司已决定着手为销售和订单管理构建一个新的应用程序。要了解组织需求以及调整整个组织中处理业务的方法,第一步是构建一组业务模型。公司中将不积极使用新的订单应用程序的部门被看作在模型的外部且以业务参与者表示。
上图显示了订单管理组织的业务用例模型中的业务参与者和业务用例。该组织销售根据每个客户定制的、复杂的解决方案。
以下是一些对业务用例的简短描述:
订单流程 -
该流程描述了公司如何采取适当的行动来按一系列客户需求中定义的那样向客户交付解决方案。当作出业务决策,决定继续完成达成一致的解决方案时,流程即开始。这可能经常表现为公司从客户接收采购单的形式。当客户对该部分工作表示满意,并且解决方案的佣金和付款收到后,流程即结束。目标在于以可盈利的方式来满足客户需求。
建议书流程 - 该流程根据客户需求生成建议书。客户查询将触发该流程,而当客户接受(或拒绝)建议中的任何报价时,流程就结束。目标在于就客户和公司均可接受的报价达成一致。
报价流程 - “报价流程”是包含在“建议书流程”和“订单流程”中的、一个抽象的业务用例。当有客户需求需要产生相应的报价时,该流程就开始了。“报价流程”的目标在于产生满足客户需求的解决方案,并与价格一同提供该解决方案。
业务用例模型的调查描述必须:
-
概述组织目的
-
指出模型的界限 - 未包含的事物及其原因
-
指定主要业务用例
示例:
由于对将业务建模的结果用作输入的软件工程项目而言,公司中管理客户订单的这一部分是唯一具有重要性的,因此该业务用例模型涵盖了该部分。出于这个原因,我们不包含公司中处理帐单、制造、产品管理和产品开发的部分;它们被视为外部部分,并且因此以业务参与者表示。
在该组织中,销售不仅涉及对解决方案的赞同,还涉及解决方案的实际构建。为定义解决方案的价格,您需要进行策划并使它达到一定的详细程度。这是在“建议书流程”中完成的工作。一旦与客户达成一致,将对解决方案进行全面的详细设计,然后在客户站点安装该解决方案。这是“订单流程”中描述的内容。“建议书流程”和“订单流程”都包含抽象的业务用例“报价流程”。
-
按具体业务目标描述的那样,业务用例应与业务策略一致。
-
用例应与它们描述的业务一致。
-
找出所有的用例。将用例组合在一起执行业务中的所有任务。
-
业务中的每个任务至少应包含在一个用例中。
-
在用例数目和用例大小之间应保持平衡:
-
少量的用例将使模型更易于理解。
-
过多的用例可能造成难以理解模型。
-
较大的用例可能较为复杂且难以理解。
-
较小的用例通常易于理解。但是,确保用例描述了可为客户产生有价值的事物的、完整的工作流程。
-
每个用例必须是唯一的。若工作流程与另一用例相同或相似,以后就难以使两者保持同步。考虑将两者合并到一个单独的用例中。
-
业务用例模型的调查描述应对组织作出很好的、全面的描述。
|