业务流程管理
每个业务都是独特的，都需要自定义的管理策略。定义业务目标以及如何执行它们是非常关键的。业务管理的另一个重要方面是管理变更，因为企业的策略会随时间而变化。有效的业务流程管理需要受过专门训练的实践，包括：
- 流程建模
- 启用工作流
- 定义业务度量
- 监视性能结果
理想情况下，您希望尽可能使管理流程自动化。通用化语言以便能够修改流程而不影响基础 IT 实现，这也是非常可取的。业务流程管理是工作流和应用程序集成之间的逻辑结合。它将流程流从 IT 级别转移到更抽象的业务级别。
业务流程再工程集中于简化和自动化流程，以更高效地实现业务目标。用于流程重定义的步骤是：
- 对现有的或当前的流程建模和模拟
- 对提议的或将来的流程建模和模拟
- 生成流程比较度量报告，以证明再工程后的流程价值。
若要做出改进，则必须熟悉现有的或当前的流程步骤。首先，分析人员捕获模型中的当前流程以及相关支持数据，以便能够模拟该流程并在以后与再工程后的流程进行比较。对当前的流程建模将允许业务分析人员确定并量化现有的流程难点。
对当前的流程进行分析并作文档记录之后，业务分析人员可以通过自动化以用户为中心的任务（例如将书面工作替换为业务应用程序和集成应用程序以防止冗余数据条目）来开始重新定义子流程。
定义业务流程
简单地对流程流建模与实际捕获业务流程之间是有区别的。分析人员还必须了解所有关联的业务模型，才能真正监视和管理整个业务流程。这包括添加资源值，可以根据确保业务满足已定义目标的业务目标来对这些值进行计算和测量。
分析人员必须记录流程的所有重要方面：
- 流程流是什么？
- 流程中使用的资源是什么？
- 流程所操作的业务项是什么？
- 涉及到什么组织和位置？
当分析人员研究流程和收集数据时，他们将记录下列内容：
- 活动的输入和输出
- 任务变化以及那些变化的出现时间
- 替代任务
- 完整的任务描述
- 与任务关联的角色
WebSphere Business Modeler 允许对与业务相关的每个元素建模。这其中包括业务项（如文档、工作产品或商品）、通知（如警报）和资源（如人员、设备和材料）。此外，可以对业务中用来执行流程或任务的每一个项（如人员、设备或材料）建模以便在流程图中使用。还可以对角色建模（为资源添加更多特征）和对时间表建模（对资源或角色的可用性建模）。
此外，可以创建业务中存在的每一个组织实体和位置的模型。组织实体的示例包括企业、公司、部门和团队。位置的示例包括地理区域、办公室、工厂和销售地区。然后可以将它们与业务流程图中的元素关联起来，或使用它们来创建结构图以对模型元素之间的组织关系建模。
总而言之，可靠的流程定义中涉及的多维业务模型包括：
- 流程模型——流程的图形表示形式。
- 资源模型——确定与流程关联的资源类型和实例。
- 信息模型——定义流程中使用的数据。
- 组织模型——关联资源的定义和结构。
- 分析模型——静态分析中的重要流程值和动态分析中流程模拟结果。
- 协作模型——支持在建模和部署时进行有关流程模型的协作。
- 业务度量模型——关键性能指标 (KPI) 和业务度量的定义。
IBM Global Services 为业务集成产品套件提供了全套课程。有关更多信息，请参考 IGS 培训网站。
除了捕获需要做的工作、谁正在做该工作和该工作所针对的目标以外，还务必从组织和地理的角度了解谁负责每个任务。这可以通过对各个任务、资源、角色、组织单位和涉及的位置之间的关联进行建模来实现。
存在四种类型的组织元素：
- 组织目录
- 结构
- 组织定义
- 组织单位
组织目录执行文件夹功能，允许您对相关的组织、位置和结构集分组。每次创建一个项目，就会自动为您创建两个组织目录。第一个目录名为 Organizations，可用于存储您自己的元素。第二个目录名为 Predefined organizations，其中包含缺省组织定义，您可以使用这些定义来创建组织单位，而不必首先为它们创建定义。
结构允许您创建可重用的模板和定义一组可跨多个组织定义而使用的属性。使用模板来创建的每个组织定义都继承该模板的属性。此外，对模板所做的任何更改都将由直接或间接引用被更改模板的所有其他组织定义模板、组织定义和组织单位所继承。
组织定义用于定义特定的组织单位。每个组织单位都必须引用某个组织定义。在创建组织定义之后，可以使用它们来创建组织单位以及结构定义。
组织单位代表组织内的特定组织部门。每个组织单位都必须基于某个组织定义，后者定义了该单位的属性。
除了组织元素外，Modeler 工具还支持位置元素。位置模型对组织感兴趣的特定地点建模。与组织一样，每个位置都基于某个位置定义，后者规定了用于定义该位置的属性。通过为位置定义中定义的属性提供值，可以创建唯一的位置实例。
业务项表示诸如业务文档、工作产品或商品等由业务操作所使用的对象。它们经历更改并从一个流程步骤传递到下一个流程步骤，并且它们形成了基础流程数据或信息模型的基础。
与组织一样，数据目录可用于对业务项模板、定义和实例分组。类似地，业务项模板提供了在可重用的结构中捕获一组属性的方法，然后该结构可由项定义所利用。然后通过为相关属性提供特定的值，可以将业务项定义实例化为业务项。
每次创建一个项目，就会自动为您创建两个资源目录。第一个目录名为 Resources，可用于存储您自己的元素。第二个目录名为 Predefined resources，其中包含缺省资源定义，您可以使用这些定义来创建资源实例，而不必首先为它们创建定义。
资源与业务不同。正如前一部分所述，业务项是工作所针对的实体。资源表示谁在做该工作或所需的先决条件，并包括人员、设备或材料。存在两种类型的资源：单独和批量。单独资源是需要特定实例情况下的资源，而批量资源是可以使用池中的随机实例时所使用的资源。单独资源的示例包括人员和计算机，批量资源示例包括电力和水。
批量资源可以表示用于执行项目或任务的材料。它们可以是非消耗性的（如员工、车辆或设备）或消耗性的（如燃料或打印机纸）。消耗性资源在流程过程中减少甚至用尽。
可以将批量资源定义为非唯一地确定的资源，但是资源是否可确定可能取决于使用它们的方式。因此资源的建模取决于被建模的流程中的角度及流程的用途。
资源可能已指定了可用的时间段。若要指定可用性，您可以使用现有时间表或创建新时间表来指明可用时间段。如果不指定某种资源可用性，则假设该资源始终可用。还可以为资源添加成本和资格。资格是该资源所必须满足的特定角色。
一经定义，即可将资源与流程流中的各个任务关联起来。还可以使用资源定义模板以允许一次性创建模板和定义属性。这对于具有共同属性的资源非常有用，并且此类资源代表资源定义的值或实例。此外，与组织一样，资源目录是可用于包含资源定义模板、资源定义和资源的容器。
角色和时间表为资源添加了额外的特征。角色用于定义特定资源的一组功能。时间表用于对资源或角色的可用性或者适用特定成本的时间进行建模。
流程是实时业务流程的表示形式。流程由各个步骤或活动、指示这些步骤和活动发生时间的条件以及流程的性能或执行所需的资源组成。
流程和任务都表示业务中执行的活动。但是流程比任务更复杂，并且可表示为通过控制和数据流链接起来的活动序列。该序列作为一个整体称为流程流。相反，任务是原子活动，无法划分为更小的操作。
存在两种类型的流程：全局和局部。全局流程显示在 Project Tree 中，并且可以跨项目中的多个流程使用。局部流程（或子流程）仅显示在其父流程的流程图中。
流程可以包含下列局部元素：
- 流程
- 任务
- 存储库
- 开始、停止和结束节点
- 连接
- 决策
- 分支
- 接合
- 循环
- 映射
- 合并
- 通知广播器
- 通知接收器
- 观察器
- 计时器
- 注解
在流程中使用决策可允许以许多不同的方式执行该流程，具体取决于每个决策的结果。每条可能的执行路径称为案例。
流程的定义包含以下部分：
- 流程图，是流程流的可视化表示形式
- 规范，定义流程的输入和输出。还可以定义成本和持续时间以及负责该流程的组织单位。请注意，负责的组织单位与执行该流程中的任务所需的资源之间没有任何隐含的关系。
全局流程必须从 Project Tree 打开以便进行编辑。例如，可以将全局流程拖放到某个图上，然后在它与图中的其他流程或任务之间创建连接，但前提是该全局流程包含适当的输入和输出。否则，您必须打开全局流程的规范并做出更改。
可以在图中显示所有流程的标签，以便能够一眼看到某些特征。最多可以指定两个标签，一个在上面，另一个在下面，并且可以从下列内容中选择：
- 描述
- 处理成本
- 启动成本
- 收入
- 处理时间
- 组织单位
- 位置
- 分类器值
连接指定流程中的活动的年代顺序。每个任务、子流程、决策或其他元素沿某个连接将控制传递到下一个任务或元素。
如果您要创建的流程从接收输入开始，则不需要使用在创建图时缺省添加的开始节点。相反，您要通过直接连接到图的边框来向流程指明输入。类似地，您将连接到右手边的边框来向流程表明期望的流程输出。可以在图中利用停止节点来表明流程已完成特定的决策流。
最后，您需要将业务项与需要在流程流中的元素之间传递该业务项的每个连接关联起来。
如果需要对任务和其他流程元素分类，以便优化流程和容易地识别具有特定特征集的元素，您可以使用分类器。存在几个预定义的分类器，您也可以定义自己的分类器和分类器值。在流程图中，分类器允许您快速查看具有某些特征的元素。例如，您可以查看现有流程中的哪些任务专门用于质量控制，或者快速确定没有为流程增添实际业务价值的所有任务。分类器使您可以对具有某个共同特征的元素分类，然后为该特征分配某种颜色。
每次创建一个项目，就会自动为您创建两个分类器目录。第一个目录名为 Classifiers，可用于存储您自己的元素。第二个目录名为 Predefined classifiers，其中包含缺省分类器定义，您可以使用这些定义来创建分类器，而不必首先为它们创建定义。
存在两种可用的流程布局：泳道 (swimlane) 和自由格式。泳道布局使您可以按照特定属性显示流程活动，从而帮助您可视化地识别具有某些特征的活动。自由格式允许您将元素放在编辑器表面上的任何位置。
泳道布局允许您通过将活动移动到不同的泳道行来调整属性。它还按照您指定的类别显示图中的元素。当在图中创建许多元素以后，如果不分别选择每个元素并检查其属性，要取消那些元素的特定属性将变得非常困难。通过切换到泳道布局，您可以按照某些特征（如资源定义、角色或位置）来快速显示活动。
Modeler 帮助系统提供了指向下列主题的链接，其中包含了可以使 WebSphere Business Modeler 的使用更快、更容易的想法和捷径。
- 一般提示和技巧——包含使用 WebSphere Business Modeler 的一般技巧。
- 流程编辑器提示和技巧——包含使用流程编辑器的提示和技巧
- 活动流建模——描述通常使用的流模式和建议用于实现它们的元素。
- 全局和局部元素——为了创建逼真和精确的模型，您需要知道何时使用模型种特定的元素。
- Project Tree 提示和技巧——包含使用 Project Tree 的提示和技巧。
- Expression Builder 提示和技巧——包含使用 Expression Builder 的提示和技巧。
- 模拟和资源提示和技巧——包含运行模拟和分配资源的提示和技巧。
- 报告和查询提示和技巧——包含使用报告和查询的提示和技巧。
- 导入和导出提示和技巧——包含适用于导入和导出的技巧。
- 快捷键和导航——如何使用键盘和组合键来执行也可以通过鼠标操作来完成的操作。
- 自定义 WebSphere Business Modeler——如何自定义 WebSphere Business Modeler 环境。
定义一组标准以便维持一致的流程模型是很好的做法。流程建模标准为团队提供了公共语言。拥有公共语言可以提高项目效率和减少误解的发生。
建议对要包括的元素名称和详细级别进行标准化。最重要的是，要保持模型与业务上下文相关。尽量选择业务操作中出现的名称和模型关系。务必记住，模型代表业务分析人员的视图，以便能够根据业务目标对其进行测量。模型应该与 IT 实现无关。
流程和任务应该遵循“动宾”命名约定，如创建销售订单。任务名称应该简练。决策和选择可以简化流程图，应将它们陈述为诸如贷款是否已获批准？ 之类的问题。
最后，范围界定对于业务流程模型的成功非常关键。应该对项目目的和目标作文档记录、确定相关涉众并确保他们的参与，以及清楚地定义项目时间表和计划以监视和跟踪正常进度。
导入和导出
WebSphere Business Modeler 允许您从各种来源导入信息，以便于快速构建业务流程模型。
WebSphere Business Modeler 所使用的信息可能已经在另一个应用程序、工具或 WebSphere Business Modeler 的另一个副本中或以另一种文件格式存在。WebSphere Business Modeler 提供向导来帮助您将该信息导入新项目或导入现有项目中。该向导支持下列类型的导入：
- WebSphere Business Modeler 项目
- WebSphere MQ Workflow
- WebSphere Business Integration Workbench V4.2.4
- 分隔文本
- XML 模式
- Microsoft Visio
- WebSphere Business Modeler XML
一旦完成导入向导，它就开始导入过程。导入过程检查所导入的元素是否与现有元素具有相同的名称。如果存在重复名称，则导入过程将对所导入的元素重命名。但是在进行 WebSphere Business Modeler 项目导入时，您可以改写现有元素。如果选择不改写，则导入过程就不会导入具有重复名称的元素。
导入过程还会对内容进行验证。如果发现诸如非法字符等问题，该过程将修复问题以便能够继续导入。当该过程完成导入时，您可以查看它所遇到和修复的问题。在导入完成以后，WebSphere Business Modeler 将对新内容进行验证。
在对业务流程建模以后，WebSphere Business Modeler 允许您将信息导出到另一个应用程序，例如为了实现该业务流程。还可以导出项目以便其他人能够导入它以进行查看和处理。
WebSphere Business Modeler 提供向导来帮助您将该信息导入为另一个应用程序能够读取的格式。该向导支持下列类型的导出：
- WebSphere Business Modeler 项目
- UML 业务建模概要
- WebSphere MQ Workflow
- WebSphere Business Integration Server Foundation V5.1
- 分隔文本
- WebSphere Business Modeler XML
- WebSphere Process Server
重要：WebSphere Business Modeler 中创建的模型不保证能在其他工具中正确工作。在转换文件时，您应该知道以下事项：
- 如果计划导出 FDL、BPEL 或 SCA 构件，您应该首先确保是在适当的模式（分别为 WebSphere MQ Workflow、WebSphere Business Integration Server Foundation 或 WebSphere Process Server）下工作，并且您的模型没有错误。这些模型强制了 WebSphere Business Modeler 中对模型的约束，以确保能将该模型导入其他应用程序并且能正常工作。
- 基于模型中指定的内容，可能无法生成完整的流程定义。例如，如果模型中的决策分支没有与它们关联的形式表达式，则不会生成任何 BPEL 或 FDL 转换条件。
- 导出文件时不会生成与部署相关的信息。该信息将会在您将文件导入 Application Developer Integration Edition、WebSphere Integration Developer 或 WebSphere MQ Workflow 时生成。
WebSphere Business Modeler Publishing Server 支持在基于 Web 的协作团队环境中对模型进行检查和注释的能力。模型发布涉及到将一致的模型发送到发布服务器。为实现一致性，必须存在来自不同 WebSphere Business Modeler 实例的模型元素的集成。
发布服务器为不拥有 WebSphere Business Modeler 来查看和注释业务流程模型的人员提供了一种方法。它使用一组 Portlet 在 Web 浏览器中显示模型。那些 Portlet 一般与 WebSphere Business Modeler 所使用的四个窗格对应。
发布项目的建议方法是将发布与建模分离。因此，发布项目应该涉及下列步骤：
- 建模，其中建模人员团队联合创建模型。
- 集成，其中某个个人在建模团队提供的内容基础上构建一致的模型。
- 发布，其中充当发布人员的人将一致的模型发送到发布服务器。
为了支持协作业务建模，项目版本控制允许团队成员从某个公共源工作，并随着模型的演变而对模型变更进行跟踪。Repository 视图支持并发版本系统 (Concurrent Versions System, CVS) 或 Rational ClearCase®。
在做出任何变更时，可能会发生冲突，当团队成员同时对项目的同一个版本做出变更时尤其是如此。具有传入和传出变更的任何元素都可能会导致冲突。发生冲突时，用户可以显式改写变更。他们必须注意仔细检查变更以确保模型的一致性。在公共存储库的需要（以在团队成员之间共享模型项目）与用于管理和控制变更的成本之间，您必须进行平衡。
请注意，使用共享存储库并不保证一致的集成模型。该存储库包含可能具有相互依赖性的不同版本的模型元素。不同的版本使得构建一致的模型非常困难。
可以使用导入和导出来在团队成员之间共享项目。这种共享使得多个人可以对模型的开发做出贡献。在使用导入和导出来共享项目时，建议采用以下过程：
- 创建将用作合并项目的项目。如果可能，则在此时创建所有目录。
- 导出项目以供每个人进行处理。建议的导出格式是“WebSphere Business Modeler 项目”。每个团队成员都将该项目导入他们各自的工作区。
- 团队成员处理该项目并添加他们的元素，同时遵守下列规则：
- 为每个新元素或目录提供唯一的名称（以避免名称冲突）。
- 不要对从合并项目导出的目录或元素重命名（以避免标识信息冲突）。
- 在每个团队成员完成某个添加阶段后，他们要导出模型。然后其他团队成员和合并项目的拥有者将导入那些模型。
- 在每个稳定阶段，备份该合并项目。
原文链接： http://blog.csdn.net/jaminwm/article/details/2340148
67
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
