任务:设置和调整目标
此任务描述如何确定业务建模工作的范围。
用途
  • 界定业务建模工作。
  • 制定目标组织未来远景。
  • 在业务建模工作的目标上达成一致。
  • 设置现实的项目干系人期望。
关系
角色主要: 其他: 辅助:
输入必需: 可选:
外部:
输出
步骤
确定目标组织的边界

讨论您选择要包含到建模工作中的内容的界线。确定组成目标组织的成分。如果涉及的读者可以接受,那么只要用业务参与者业务用例就可以有效地表示出来(但不一定必须用这种表示法)。在对下列问题的回答上达成一致非常重要:

  • 您认为环境中哪些重要的参与方是位于目标组织之外的?这意味着要找出您不能影响其工作、但仍需要跟他们有定义良好的接口的参与方。 
  • 如果您正在执行业务建模来确定某个特定系统的需求,那么组织中有不会受这个系统影响的部分吗?这样的部分可以认为是外部的,因为使用资源来描述此项目不会受其影响或此项目无法影响到的业务流程是没有意义的。 

您为目标组织设置的边界与您认为的“公司”的边界可能有很大区别。例如:

  • 如果您的目标是构造新的销售支持系统,您可能会选择不包含在产品开发部门中进行的任何流程。然而,产品开发部门必须被认为是业务参与者,因为存在与这个部门的、需要澄清的接口。在此示例中,“公司”内部的一方被认为位于目标组织之外,因而建模为业务参与者。 
  • 如果您构建的系统用于增强与合作伙伴或供应者的交流(一个企业到企业的应用程序),那么您就可能会选择将这些合作伙伴或供应者包含到您的目标组织中。在这种情况下,位于“公司”之外的一方就在您的目标组织之内了。请注意,只有您对合作伙伴的运营方式有一些了解和影响,这种分类才有用。如果您只能影响与合作伙伴的接口,那么该合作伙伴就应该被认为是外部的,因而在模型中它应该是业务参与者。 
  • 如果项目的目的是构建一般的、可定制的应用程序(如商业记帐应用程序),那么目标组织就必须表现您关于购买最终产品的客户将如何使用该产品的设想。在这种情况下,您会将抽象的一方包含到目标组织中。 
确定项目干系人

项目干系人是这样的群体(内部和外部,个人和组织):他们有权影响项目的结果,或者需要向他们通知项目中作出的决策。

目标组织评估中,您确定了业务的项目干系人。在业务远景中,您必须指定这些项目干系人中哪一些将是当前项目范围内的项目干系人。您在这方面的决策将取决于业务建模工作的范围(请参阅概念:业务建模的范围)以及您为建模工作确定的边界。 

就工作目标达成共识

要确定业务建模工作的目标并管理项目干系人的期望,就必须设立清晰的目标并得到涉及的各方的同意。这有助于使业务建模团队工作重点集中以及防止期望过于分散。

这里设立的目标不同于后面确定的业务目标。这里的目标专门指将由业务建模工作实现的目标。它们通常是下列期望的组合:

  • 降低成本(运营成本和分发成本)。这通常是一个次要的目标,通过缩短交付周期和提高质量来实现。
  • 缩短交付周期。提高响应性、缩短开发周期、提高生产率等等。
  • 增加收入。
  • 增加客户量。 
  • 进入新的市场。 
  • 提高产品和服务的质量。
  • 改进库存和采购管理。 
  • 改善渠道关系(合作伙伴和供应者)。 
  • 提高客户满意度(包括客观和主观表示的满意度)。
  • 提高员工在团队工作和协作中的效率。 
  • 合并业务。当两个业务合并成一个时,您就可能需要合并两者的一些业务流程。
  • 将部分业务外包。

为了帮助澄清目标,向项目干系人询问下列问题会有所帮助:

  • 如果我们说这不可能,那么您会怎么做?
  • 如果我们成功了,您将把这个消息告诉谁?
  • 如果我们未成功,您不会把这个消息告诉谁?
  • 如果我们未成功,会发生什么情况?
  • 您为什么认为我们能解决这个问题?
  • 您将如何确定我们是否已经解决了您的问题?
  • 什么时候您会认为工作已完成?
确定要对工作施加的约束

您必须考虑各种约束来源。下面是一列可能的约束以及要对这些约束提出的问题:

  • 政治:有没有内部或外部政治问题会影响可能的解决方案?有没有部门之间的问题?
  • 经济:哪些财务或预算约束会有影响?需要考虑销售的货物成本或产品定价方面的问题吗?有没有什么许可问题?事情有没有正在发生变化的迹象?
  • 组织:有没有任何其他当前正在进行的活动可能会受影响?组织正在发生变化吗?涉及的各方知道问题的过去情况吗?
  • 环境:有没有环境或规章制度带来的约束,或者有没有法律问题?有没有可能约束我们的其他标准?
  • 技术:我们在技术的选择上受约束吗?我们被限制为只能在现有的平台或技术条件下工作吗?我们被禁止使用任何新的平台或技术吗?
  • 可行性:规定了日程安排吗?我们被限制只能使用现有资源吗?我们可以使用外面的劳动力吗?我们可以扩展资源吗?如果可以,那么是暂时的还是永久性的?
  • 系统:解决方案要建立在我们现有的系统上吗?我们必须保持与现有解决方案的兼容性吗?必须支持哪些操作系统和环境?
形成问题陈述

大多数业务建模方面的工作都意味着某种变更,而这种变更必须有充分的理由。您必须形成问题陈述并将其记录在业务远景中。这个文档以及(特别是)问题陈述用来让项目干系人相信有变更的需要,并让所有涉及的各方将精力集中到必须解决的问题上。

目标组织评估中,您可能已经指出了项目干系人已经确定存在于目标组织中的一系列问题。在“业务远景”中,您需要将这些问题限制在打算在业务建模工作中要集中解决的问题上。虽然很难为找到的所有问题找到相同的根源,但您也必须始终尝试着这么做。形成问题陈述有助于确定察觉的问题到底是不是实际存在的问题。

与所有小组成员一起,用框架图为找到的每个问题填写以下模板:

问题是(描述问题。)
影响到(列出受问题影响的项目干系人。)
它的影响是(描述问题的影响。)
一个成功的解决方案将(列出成功的解决方案的一些关键好处。)

该模板的目的是帮助您将解决方案和回答与问题区分开来。例如:

问题是客户服务问题没有得到及时、恰当的解决
影响到我们的客户、客户支持代表和服务技术人员
它的影响是客户不满、察觉到质量欠缺、员工不高兴以及收入损失。
一个成功的解决方案将
允许支持代表实时访问故障诊断数据库,加快服务技术人员的派遣,将他们及时派遣到真正需要他们帮助的地方。

确定要优先考虑什么领域

您必须讨论业务建模工作应该优先考虑目标组织的哪些领域,并对此取得一致意见。这种讨论的途径可能稍有差异,这要视您的业务建模工作的范围而定。 

  • 如果您的建模工作是创建图表或作出一些简单的改进,您就必须查看对当前业务(其业务参与者和业务用例)的描述,并一步步地完成工作流程,以确定需要改进的领域。请参阅指南:业务远景中关于查找需要改进的领域的部分。 
  • 如果建模的目的是创建新的业务或对现有的业务作出巨大改动,那么您必须关注的范围就更广了。您可以首先质疑业务的界线。请参阅指南:业务远景中关于“新的或彻底重构的目标组织”的部分。 
记录业务远景

该任务的主要结果是描述未来目标组织的远景的业务远景。此文档必须包含:

  • 目标组织的新的或有巨大改动的业务用例的名称和大纲。
  • 未来业务用例的概述和高级别描述,强调这些用例与当前用例的不同之处。对于每个业务用例,文档都必须指定客户、供应者或其他类型的合作伙伴。此外,它还必须描述输入、任务和产品。这些描述必须直接、客观地表明业务的理念和目标。但是,这些描述不一定要很全面或很详细。这些描述主要是为了促成高级管理层、员工、客户和合作伙伴之间的讨论。
  • 每个业务用例的可测量的属性和目标,如成本、质量、生命周期、交货周期和客户满意度。每个目标都应该可跟踪到业务策略层面,而目标的描述必须表明它如何支持该策略。
  • 将支持业务用例的技术规范,特别要强调技术支持。
  • 可想像的未来方案的描述。只要可能,该规范就应该预测:在未来的几年中,由于新技术、到环境的新接口以及其他类型的资源将使业务用例必须作出怎样的变更。
  • 一系列关键成功因素,即对于成功实施“业务远景”很关键的因素。
  • 关于使业务建模工作成功而必须处理的风险的描述。

关于更多信息,请参阅工作产品指南:业务远景工作产品:业务远景。 

评估结果

在这个阶段检查“业务远景”,以验证您的工作是否在正确的轨道上,但不要详细复审。请考虑核对表:业务远景中“业务远景”文档的核对表。一定要考虑复审进行时在项目中所处的阶段。例如,在“先启”的第一次迭代中,“业务远景”可能只是一些不连贯的初级的描述。

在复审时,一定要有来自下列各组的代表的参与:

  • 行政管理
  • 业务建模团队
  • 将在目标组织中工作的人员的代表
  • 您的业务改进可能会涉及的任何合作伙伴的代表


属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息