小型组织和大型组织之间的区别在于产品所涉及的范围更宽,通常是在若干个完全不同的产品系列中。 一般情况下,产品的复杂程度越高,组织和市场分布得越广。 这会产生大量更复杂的业务用例,涉及更多具有专门任务的员工。
这里提出的几种技术可以独立应用或组合应用。
公司的高级管理人员以及公司的流程拥有者都很关心他们公司的业务模型 - 管理人员必须制定公司的策略目标,而流程所有者和负责人则需要详细了解他们的流程应该如何执行。
如果高级管理人员和流程所有者对于组织的看法存在太大分歧,则您可以通过开发两组不同但相关的业务用例来满足他们的需要。 一个模型针对高级管理人员,将包含一组显示了组织意图和目标的高级业务用例。
另一个模型针对流程所有者,将包含一组详细的用例,这组用例可帮助阐明组织内部需要如何运作。 对于每个高级业务用例,可以定义一个或多个代表组织中相同活动的详细业务用例。
例如,您可以从主要的业务参与者开始,详细描述他/她所关注的结果或服务,甚至可以使业务参与者专门从事某方面的工作,然后为每个细化的领域开发单独的业务用例。
如果您想按一次一个业务用例的方式为您的组织进行设计,则可以递增方式应用此技术。 首先建立整个业务的高层用例模型,在概述中区分各业务用例的等级,然后为最高等级的高层业务用例确定一个或若干个详细业务用例。
高层业务用例与其那一组详细业务用例之间存在一一对应的关系。 这两种类别的业务用例之间的关系表示为 <<refinement>>
关系(依赖关系的构造型)。高层业务用例和它所代表的那一组详细业务用例可以在同一个图中显示。
高层业务用例和详细业务用例。已通过详细描述客户和潜在客户所关注的结果来确定了详细业务用例。
到目前为止我们已介绍的用于业务用例建模的技术,能很轻松地应用到只有单个业务领域且业务活动集中在一个地理位置的公司。 对于分布在多个位置的较大的公司,可能需要增加所使用的技术。
因此,要对由独立但彼此合作的各部分构建而成的公司建模,可以构建一个描述整个业务的上级业务用例模型,随后针对每个业务领域构建一个下级业务用例模型。业务系统可以用来定义不同的职责范围、不同的物理位置,或业务的交互部分。
要探索上级业务用例实现,您可以确定业务系统并显示它们如何协作执行工作流程。 在此级别,一个业务系统对应于一个业务领域。可以使用业务级别的接口来明确定义业务系统之间的协作并阐明这种协作。 这些“接口”描述由业务系统提供的一组职责。
组织的上级模型和下级模型
在此示例中,我们可以看到,上级业务用例“请求提议”被细化为业务系统级别的下级业务用例“请求提议”、“计划和评估项目”以及“估计资源成本” 。上级业务用例“提供资源”被细化为业务系统级别的下级业务用例“确定资源需求”和“购买原材料”。
然后,可以将每个业务系统都当作它自己的一个组织,实现上级业务分析模型中定义的接口。
下级业务用例(已建立每个业务系统实现上级业务用例所必需的接口)可按概念:用例分解中所描述的类似方式进行派生。
在软件工程中,用来控制庞大系统的复杂程度的技术被称为分层。该技术中所隐含的思想是将特定于应用程序的部分与系统中较一般的部分分开,从而使程序单元和程序服务能够被复用。构建组织结构时,自然常常会应用这些原则。例如,您可以在底层找到提供一般服务的资源;在中间层中可以找到支持特定于业务的活动的资源;而在顶层中可以找到特定于业务领域或特定于产品的专家、研究和开发以及销售人员的活动。
核心业务用例使用所有层中的资源。
因此,进行分层时所考虑的问题并不是资格或资历,而是针对公司的业务构想的独特性和重要性。 由一般技能层次的业务工作者处理的任务可能与其他任何层次的业务工作者处理的任务一样合格。
在核心业务用例和支持业务用例中,如果开发特定于业务的信息系统、生产线和其他类型的业务基础结构,其中的工作就可能需要相应分层结构中相应的专项业务技能。
指南:业务系统包含业务系统的示例和它们的接口。 尽管该示例没有显式说明各个层次,但该示例中的业务系统是经过隐式分层的。
关于对术语“核心”、“支持”和“管理业务用例”的说明,请参阅技术:业务用例模型,尤其是关于不同类别的业务用例的那一节。
分层模型中的业务用例和类
因为仍然需要产生相同的结果,对组织结构进行分层不会更改业务用例。 但它会更改业务用例实现。
与未分层的业务分析模型相比较,开发分层的业务分析模型时建议您注意以下两个限制:
-
除非较高层次中的人员发出明确的请求,否则某个层次中的业务工作者绝不会与较高层次的业务工作者联系或者对较高层次的业务实体执行操作。 同样,较高层次中的业务事件不会传播到较低层次。
-
业务工作者只在他/她自己的层次中工作。
如果没有这些限制,分层结构会很快退化。请注意,这些限制适用于这样一种情况,即业务的大多数一般部分在较低层次中,而大多数特定部分(对应于特定市场部分)在较高层次中。组织图会从相反的方向表示,即,顶部为一般部分,底部为特定部分。
在确定业务工作者并对他们分配活动时,需要了解执行活动所需的技能。 为那些特定技能组织资源的层中的业务工作者必须执行由于其特性而需要特定技能的活动。
设计业务用例时,不应按照通常的经验(即业务工作者越少越好)进行设计,而应该让每个层次中的业务工作者尽可能少,同时他们的职责范围尽可能宽。
设计较低层次中的工作流程、业务工作者、业务实体和业务事件时应考虑通用性,以提供可在多个域重复使用的服务。 可以根据业务工作者和业务实体的业务特性将他们组织到业务系统中。
在底层中可以找到包括大多数一般能力和现象的业务系统;而在顶层中可以找到大多数特定于公司的业务系统。
不同层中的业务工作者将在不同程度上参与业务用例实现。在很大程度上涉及到顶层(非常特定)的业务用例实现设置公司的概要情况、实施业务构想并且充当利润中心。它们对应于核心业务用例以及某些支持业务用例(这些业务用例给核心业务用例提供必需的、特定于业务领域的基础结构)。
较低层中的业务用例实现(不包含顶层业务工作者)提供保持公司运作所需的一般服务。
它们可以是抽象的,并且定义作为其他业务用例的一部分而执行的工作流程,例如,结束某个销售业务用例的结账活动。它们还可以是具体的、可以独立执行并且不需要特定于业务领域的能力的执行活动,例如,记帐。它们通常对应于支持业务用例。
分层结构反映那些对于业务构想来说很关键的技能(核心业务用例或支持业务用例中需要它们)以及那些较具有一般性的技能。这对于系统地分析公司的可用资源来说是一个不错的起点。
在很多情况下,您只关注一个或少数几个业务流程的详细信息。但是,为了提供环境,实际上可以确定一整套业务流程并简要描述其中每个流程。 这会产生一个包括核心业务用例、支持业务用例和管理业务用例的模型。请参阅技术:业务用例模型中关于不同类别的业务用例的那一节。
支持业务用例(例如核心业务用例、特定于业务的信息系统、计算机网络和场地)负责构建和维护公司的基础结构。从建模的角度来看,核心业务用例和支持业务用例之间没有实际的差异。
这两种类型的业务用例同样需要具有可用性和有效性。要成功执行,这两种业务用例可能都需要相同类型的资源。
一个组织中的支持业务用例(例如软件开发业务用例)可能是另一个组织中的核心业务用例。 主要的差异是业务用例为谁工作。应业务所有者的要求,支持业务用例与受影响的业务用例所有者和操作员合作发展业务。
在整个业务的模型中,典型的业务参与者是董事会。当建模被限定为仅包含支持业务用例时,典型的业务参与者是业务用例所有者和业务用例操作员。
另一方面,管理业务用例负责管理业务;即,负责根据所有者的指示来运作和开发其他业务用例,以根据所有者的指示启动并监视核心业务用例和支持业务用例。业务分析模型描述执行官、资源所有者、业务用例所有者、业务用例领导和业务用例操作员需要如何合作。典型的业务参与者是所有者或董事会。
整个组织的模型
另一方面,必须注意许多次要任务,例如,使计算机网络保持运行、接听电话和清洁咖啡机。但这些任务并不是已定义业务用例的一部分。 例如,如果您打算通过 ISO 9000 标准认证,则还需要将这些活动包括在模型中。
根据经验,有一个简单直接的方法:如果它是全职工作,则将活动分配给特定业务工作者。 如果它是兼职工作,则将活动分配给具有适当技能要求的现有业务工作者,而不必尝试将它包括在任何业务用例中。
|