任务:评估目标组织
此任务描述了如何评估组织的当前状态,并从当前流程、工具、人员技能、市场环境方面来描述这种状态。
用途
  • 描述要在其中部署应用程序的组织的当前状态,描述的方面包括:其当前流程、工具、人员的能力、人员的属性、客户、竞争对手、技术趋势、问题和改进领域。
  • 启发为什么必须设计目标组织。
  • 确定业务建模工作的项目干系人。  
关系
角色主要: 其他: 辅助:
输出
主要描述

为了通过业务建模选择最有效的路径,您需要理解目标组织在人员、流程和工具方面的当前状态。此任务的目标是了解问题区域和改进的可能性,以及关于外部问题(例如竞争对手或市场趋势)的任何信息。此任务完成时,您应该了解:

  • 目标组织的当前状态。
  • 存在哪些类型的人员,他们的能力、技能和动机的级别。
  • 当前在目标组织中使用哪些业务工具。
  • 当前业务流程得到了何种程度的描述,并得到了何种程度的遵循。 
  • 哪些领域最具有改进可能。 

评估当前状态的原因是,通过评估您可以:

  • 选择要遵循的业务建模场景(请参阅概念:业务建模的范围)。
  • 确定哪些领域应首先考虑。 
  • 启发为何您需要更改(如果您的确需要更改)目标组织中的流程、工具和人员。
  • 在目标组织中的直接或间接受变更影响的人员中间产生激励和共识

此任务只有在您执行业务建模以设计自己的业务时才会增值。如果您只是构造现有组织的图以得到系统需求,则没有必要进行完整评估。另请参阅概念:业务建模的范围。 

步骤
启动评估

建议您以聚集(当时已知的)关键项目干系人的研讨会启动评估。这样一个初始研讨会的主要目的是使业务分析人员与业务建模工作的项目干系人会面,并从项目的项目干系人那里收集问题的综合列表。请参阅技术:评估研讨会,以获取关于如何举行这样一个初始研讨会的详细信息。

确定项目干系人

确定业务建模工作的项目干系人。确定目标组织以外的项目干系人,例如:

  • 客户。谁是客户?客户在投放市场时间、功能、安全性、健壮性和复杂性方面对产品有些什么需求。
  • 竞争对手。谁是竞争对手?竞争对手在哪些领域较强? 从竞争对手身上能学到什么?
  • 其他项目干系人。涉及到任何其他项目干系人吗?涉及到供应商和合作伙伴吗? 与他们的关系存在问题吗?是否有需要保留在循环中以避免惊奇的,具有很大影响力和自己的看法的人?

确定目标组织中的项目干系人,例如:

  • 项目经理
  • 销售人员
  • 客户代表
  • 市场人员

询问每个项目干系人(代表),他/她对目标组织的期望是什么。这可以作为评估研讨会的一部分执行,也可以通过问卷调查的形式执行。 

与人员面谈以了解他们对变更的态度。如果人们对变更持否定或者怀疑态度,则变更不可能成功,除非您能将否定的态度转变成肯定的态度。

您必须分析和量化客户当前的和将来的期望。请勿对客户的期望作出臆测 - 应从客户处获取该信息。您可以正式或非正式地与客户面谈,也可以使用其他市场研究技术,例如电话推销。

描述目标组织的结构

简要描述他们当前具有的组织结构、角色和团队。还请查看目标组织的不同部分之间的关系。例如,销售和维护之间是什么关系,或者产品开发和销售之间是什么关系?

使用业务建模表示法来提供此信息可能具有吸引力,但使用任何一种项目干系人习惯的描述样式常常更好,它可以是文本、“组织图”或统一模型语言。 

确定关键人员

确定目标组织中的任何关键人员。 关键人员是指具有以下一个或多个特征的人员:

  • 执“团队牛耳”。
  • 可以担当指导者。
  • 是某个(某些)领域的专家。
  • 与业务建模工作相对。
  • 负责预算。

要使业务工程工作取得成功,项目中需要有关键人员,这很重要。您将需要让关键人员参与以下活动:

  • 在评估的剩余阶段收集信息。
  • 作为专家,帮助确定对目标组织作出的变更。
  • 为试验性项目出力,然后成为指导者。

注意:要提防想要讨论业务建模原理而不是实施有效新组织的人。

评估业务理念和业务策略

大多数组织均将他们的业务理念和策略很好地记录下来了。如果您在记录“虚拟”目标组织(意思是您在执行业务建模以理解目标客户的业务流程,从而构造更好的产品),则可以排除此步骤。 

探索评估策略:

  • 当前流程是否符合策略。 
  • 它的具体程度是否足以让在组织中工作的人员理解。 
  • 它是否可度量。 
  • 是否能感觉到它是现实的。 

另请参阅工作产品指南:目标组织评估以获取更多信息。 

基准评测

确定以下问题:

  • 谁来执行基准评测。如果您的目标是进行详细的基准评测工作,您应寻找非竞争对手、但仍有足够的相似性的组织。 
  • 什么度量值用于基准评测。相关的度量值通常是时间、成本和质量的组合。 
  • 如何执行基准测评 - 是与其他组织合作,还是寻找公用信息就已足够?

另请参阅工作产品指南:目标组织评估以获取更多信息。 

度量目标组织

对组织进行度量是理解其业务流程并对它们进行度量。您需要考虑以下各项:

  • 定义一组要使用的度量值,这些度量值是客户认知的度量值(例如准时交付)和内部认知的度量值(例如生产成本)的最佳组合。 

  • 确定从谁那里收集度量值。 

  • 定义收集度量值的有效方法 - 它必须简单,且“干扰”尽可能少,否则人们会认为他们没有时间提供信息。 

请参阅工作产品指南:目标组织评估以获取更多信息。 

确定变更的根本原因

询问项目干系人为什么希望变更业务流程和业务工具。以下是一些典型回答,以及它们对您如何选择探索和引入业务流程的影响:

  • “我们希望使用这项新技术,并需要了解它如何影响我们的工作方式。”
    例如一家已决定构造电子商务 Web 站点的公司。在许多情况下,完成此工作最不会引起争议的方法是,考虑将变更作为新业务线,而不是对一组现有的业务流程的变更。 
  • “我们需要使我们的业务流程更有效,以满足竞争要求。”
    在这种情况下,您需要询问一些接下来的问题,以理解需要将效率提升到何种程度 - 我们是在谈论小幅度的改进,还是谈论大的返工和许多新型技术支持。您还需要理解那些竞争对手是谁,哪类度量值用于比较。 
  • “我们的旧系统支离破碎,我们需要在它们崩溃之前更换它们。”这还要求一些后续问题,以了解对于业务流程是否变更是否有预测。如果不是,该方法常常执行一些高级业务建模,以获取当前组织图,有时候一个领域模型可能已足够。 
估计应变能力

分析目标组织中的应变能力。组织和个人一样,它可以经受变更,但变更的范围有限。一些组织比起其他组织更愿意进行变更。为理解组织应变能力,我们建议您与组织中的人员面谈,以了解他们对变更的态度和意愿。

要考虑的因素是:

  • 是否对当前条件加以谨慎的态度 - 随之而来的风险是认为所有建议的变更都不错,而未正确进行质疑。 
  • 是否对变更加以谨慎的态度 - 组织可能已由于各种原因经历了多次重组,但项目干系人认为并不成功。在这种情况下,需要使任何建议的变更相当具体并得到很好的激发,以便让在组织内工作的人员考虑他们是否有任何价值。研究先前变更工作不成功的原因也是有价值的。
  • 在目标组织内工作的人员中,总体态度如何。他们是“渴求变更”还是“无动于衷”? 
  • 目标组织是现有组织,还是想要从头开始构造的组织。如果是后者,那么您需要了解新组织中人员的期望能力,以及可能为他们提供多长的上升时间。 

除了上面提到的软性因素以外,您还应评估任何新技术的准备情况,例如那些构造电子商务解决方案所需要的技术。这样的技术有 [CONA99]:

  • 客户端/服务器。

  • 数据库管理。

  • 编程语言,例如 HTML、XML 和 Java。

  • 编制了脚本的服务器页和 servlet,例如 Microsoft 的 Active Server Pages,以及 Java Server Pages。

  • 对象通信协议,例如 OMG 的公共对象请求代理体系结构(CORBA)、Java 标准远程方法调用(RMI)或 Microsoft 的分发式组件对象模型(DCOM)。

  • 组件,例如 Microsoft 的 ActiveX/COM。

  • Web 应用程序框架,例如 IBM 的 WebSphere 或 Microsoft 的 Windows DNA。

在形成解决方案体系结构时,这一评估将在很大程度上影响您愿意承担的风险程度,另请参阅活动:评估项目范围和风险。 

确定问题

确定问题的最好方法是召集许多关键人员来召开问题确定会议。请参阅指南:集体讨论并整理提议以获取关于如何组织此类会议的一般建议。

询问诸如以下的问题:

  • 目标组织中的问题是什么?
  • 能感觉到什么东西坏了吗?
  • 项目常常落后于进度安排或超出预算吗?
  • 它们有什么问题?
  • 已收集了所有可以分析的度量值吗?

确定在没有解决或减少问题的情况下,每个问题对项目造成的或即将造成的负面影响。了解问题的影响可帮助您了解消除或减小问题是多么重要。

确定每个问题的根本原因。了解问题的根本原因可帮助您了解如何消除或减小问题,以及消除或减小问题的成本。鱼骨图可能会有所帮助。如果问题存在几个根本原因,您需要将它们相互对照以进行权衡,在这种情况下排列图可能有所帮助。 

警告:人们往往会急着直接找解决方案,而不会先花时间去把问题弄明白。把问题写下来,看看您能否让每个人都同意问题的定义。

根据问题造成的影响,对问题划分等级。例如,使用 1 到 5 的标度,其中 5 代表影响最危险的问题,1 代表无害的问题。主要目的是理解问题的相对重要性。

要获得问题的定义的共识,其中一个最简单的办法就是把问题写下来,看看是不是每个人都表示同意。将问题列在表中:

问题 

影响 

根本原因 

等级 

交付的软件质量很差。 

- 客户不满意。
- 我们不得不在发布主发行版之后发布错误修订程序。 
- 测试用例未涵盖所有情况。
- 测试不是自动的。
- 测试人员接受培训的程度不够。 

#5 

... 

... 

... 

... 


得出结论

分析收集到的信息的结果,并编辑一份要关注的领域和问题的列表。应尽早解决的问题通常可归于以下一类或几类:

  • 主要问题领域。您可以大幅度改善业务流程绩效的领域。
  • 您可以获得短期收益的领域。您可以显示快速结果的领域。
  • 改善效果很明显的领域。

将收集到的信息和结论记录在工作产品:目标组织评估中。

作出建议

作为评估的一部分,您需要包含一些对今后工作的建议。建议应描述对业务建模采取什么途径。请参阅概念:业务建模的范围以获取一组典型场景。



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