级别： 中级 Marc Fasbinder, 顾问 IT 专家，WebSphere Software Technical Sales, IBM
2007 年 9 月 11 日 目前很多企业都特别关注其业务流程的捕获，都在尝试了解最佳的工具集和方法。本文将对几种常见方法进行比较，从而说明构建流程模型的优势。另外，本文还将说明为何 IBM® WebSphere Business Modeler® 是用于创建流程模型的强大工具。
引言
现在各个公司由于种种原因而开始积极进行捕获其业务流程的工作。经过合并的公司希望对其跨业务部门的流程进行检查，从而发现哪个流程最好。其他公司希望改进现有流程，或甚至想实现其自动化。在有些国家/地区，政府法规要求对业务流程进行恰当地记录。例如，美国的 Sarbanes-Oxley 法案要求必须为某些特定的流程制定良好的文档。当今业务环境中存在众多驱动因素，促使各个企业开始更为关注其流程，而这些只是其中的一部分。
总的说来，业务流程驱动因素可归为三个主要类别：
-
文档说明。公司需要捕获业务流程，以便其他人能够了解其工作方式、涉及人员以及活动从头至尾如何进行。通常，业务分析人员知道流程工作如何建模这些流程。
-
重新设计。很多企业希望改进其业务流程，以减少效率低下的情况、促进成本降低和更快响应客户请求。在理解流程之前，无法对其进行重新设计，因此必须首先将其捕获。只有恰当地记录了流程之后才能进行重新设计。通常，将由既了解业务需求同时也熟悉 IT 系统的技术分析人员或者业务的 IT 联系人对这些流程进行建模。
-
执行。在大多数情况下，提高业务流程的效率的最好办法是对其实现自动化。如果可以减少或消除手动工作，则流程能以更低的成本更快地运行。要实现流程自动化，业务的 IT 人员或咨询师必须编写代码或使用中间件产品。对低效的流程进行自动化并不明智。由于这个原因，此阶段应该仅在获得了重新设计后的流程后进行。
其他类型的建模不在本文的讨论范围内，例如软件架构师作为代码开发周期的一部分进行的 UML 建模，或影响分析中使用的企业建模。本文将重点讨论业务建模，您仅仅需要概念产品知识即可。
工具
要捕获任何业务流程（无论目标如何），将需要使用工具。通常最常使用的三个工具为：
-
基于文本的文档。可以使用 IBM Lotus® Word Pro 之类的文字处理程序来创建包含关于流程的信息的文档。
-
绘图工具。可以使用 IBM Lotus Freelance Graphics 之类的图形工具来创建表示流程流的图片。通常此图片与包含更多细节的文本文档配合使用。
-
业务建模工具。可以使用 WebSphere Business Modeler 之类的工具建立业务流程的模型。模型本质上是图片，但不仅是图片。
本文将说明这些工具在三个业务流程捕获目的方面的用法。
基于文本的文档
记录流程的最简单工具之一是使用基于文本的文档处理程序。文本文档在捕获业务流程方面已有多年的使用历史。其优势在于，几乎每个公司都已经有了文字处理工具。
文档说明
- 有些概念仅使用文字不足以表达清楚。例如，在存在嵌套子流程或具有六个不同输出的转移判定的复杂流中，如果仅仅使用文字进行描述，则很难理解流程流。图片可以更为容易地表达这些概念，而仅仅使用文字则可能导致混淆不清。而且仅仅使用文本进行记录时，跨国企业则会面临语言障碍。
- 文本长于表述在业务流程的单个步骤中完成的工作。不过，文本却很难表述总体的端到端场景。
- 如果更改流程，则很难确定文档中需要更新的所有位置。例如，如果要将三个步骤合并为一个子流程，并能够在稍后的更抽象的流程中加以重用，就会很难确定需要更改的所有文本位置。这就意味着，当流程随着时间的增加而发生更改时，文档的准确性将降低。
- 同时只能由一个人处理一份文档，因为它只是一个简单的文本。不可能进行协作开发。
重新设计
- 除了记录业务流程的实际情况外，基于文本的文档对流程的重新设计没有任何帮助。
执行
- IT 使用技术工具集来构建自动化业务流程。分析人员记录的所有内容必须重新输入到技术工具集中。这可能会花费大量的时间。
- 业务分析人员和 IT 专业人士采用不同的语义和不同的方法来表述概念。分析人员认为清楚而简洁的内容可能被 IT 人员视为不够明确。
基于文本的文档相关推荐
使用基于文本的工具记录用例，但不要使用其记录总体业务流程。即使在记录用例时，IBM Rational® ClearCase 之类的工具也具有很多普通文本文档所没有的优势。文档处理程序不是用于捕获业务流程的最优工具。
绘图工具
由于一个简单的原因，各个企业已有多年使用流程图和其他类型的图像的历史：图片通常能够更快捷简单地表述有些东西，而相应的文字可能需要数千字。流程图非常适合展示总体情况，而不会像文本文档一样让您陷入细节的泥潭中。
文档说明
- 流程图就是一张图片。其本身并不能描述流程的每个步骤的细节。绘图空间并不能提供足够的空间来包含所有细节。还需要独立的文本文档来包含图片中所没有的细节。必须在对其中任何一个进行修改的时候保持图片和文档同步。这个工作并非无足轻重的小任务，特别对于大型的复杂流程更是如此。
- 所绘制的流程图具有很强的静态性。并不能了解其各个不同的方面。例如，无法单击按钮来按组织或角色查看流。您所看到的仅仅是一个图片。
- 大部分绘图工具都提供了大型形状和图形图标库，供在图片中使用。这就提供了所需的灵活性，但也意味着很容易创建出表述不明确的图片。可以创建圆圈来作为判定使用，也可以使用菱形、方框或任何此类形状。其他人查看图片时，可能会造成理解错误。
- 如果组织设置了相应的标准，规定哪些形状表示流程中的不同对象，则没有办法进行错误检查，无法确定形状是否使用正确。需要由每个作者负责执行这些规则。
- 同时只能由一个人进行绘图工作，因为这是在编辑简单的文档。不可能进行协作开发。
重新设计
- 简单的图片不能表示业务流程的任何动态方面。由于这个原因，除了进行记录外，绘图工具对业务流程的重新设计没有任何帮助。
执行
- IT 人员仍然需要将流程图中的所有信息以及随附的文本文档重新输入到自己的工具集中。仅仅图片并不能产生有用的 IT 构件。此手动工作要花费大量时间，而且造成误解的机会相当大。
- IT 可能会构建与业务用户预期不符的组件，从而会导致在达到业务预期之前进行开销很大的重复返工。
- 绘图工具并不能帮助促进重用。它不能使用 Web 服务描述语言（Web Service Descripiton Language，WSDL）、XML 模式定义（XML Schema Definition，XSD）或其他基于标准的构件。绘图工具不能查询注册中心（如 IBM WebSphere Services Registry & Repository）来确定是否已经存在可重用服务了。所有这些工作都必须由 IT 人员进行，从而延长了开发周期。
绘图工具推荐
仅仅绘图工具并不能表述业务流程。为了捕获细节，需要将其与文字处理工具配合使用。此外，这两个文档还必须保持同步。二者结合的效果超过单独使用其中任何一个的效果，但仍然不是满足捕获流程的三个业务驱动因素要求的最优解决方案。
业务建模工具
使用 WebSphere Business Modeler 之类的建模工具可得到流程图的所有优势，因为其中包括了流程的可视表示形式。不过，它还具有文本文档的优势，因为模型中的每个对象都可以包括注释和文档之类的属性。
文档说明
- 与绘图工具一样，模型表示业务流程的可视图像。但这不仅是图片：模型中的每个元素都具有能用于进行文档说明的属性。它将流程的视觉方面和文本方面结合在了单个实体中：模型。
- 模型不仅是图片。屏幕上的视图仅是模型的一个方面而已。例如，可以随时从自由格式流程图切换为泳道图（行式视图）。
- 这样的建模工具使用一致的对象集来表示业务流程。例如，判定始终使用菱形表示。模型可准确地表示业务流程的各个重要方面。
- 建模工具可以将基于标准的构件（如 XSD 和 WSDL）导入，或在注册中心对其进行搜索。这不仅意味着它可以帮助鼓励重用现有资产，而且 IT 并不需要重新输入或创建信息，从而节约了时间，并能确保准确性。
重新设计
- 很多业务建模工具都支持模拟流程模型，而这在简单的图片中是不可能实现的。通过模拟，用户可以了解业务流程的动态行为。流程中时间耗费在哪些位置？成本耗费在哪里？瓶颈在哪里？是否存在资源短缺？这些问题可帮助对业务流程进行重新设计。
- 重新设计了流程后，也可以对其进行模拟。可以将原始（当前状态）流程与将来的流程进行比较，以验证流程重新设计的影响。
- 通过这些功能，业务部门就能自己进行重新设计，而不用雇请收费高昂的咨询师。
执行
- 业务建模工具能够将业务模型转换为对 IT 有用的构件。这样可减少或消除 IT 人员重新将信息输入其技术工具集所需的工作。这些构件本身通常基于 WS-BPEL 之类的运行时标准。
可以这样说，针对执行的建模可以由针对运行时环境设计的工具来进行，如使用 WebSphere Integration Developer 来创建 WS-BPEL。不首先使用业务建模工具，而直接创建技术 WS-BPEL 模型有几个缺点：
- 技术建模工具不能执行模拟来在部署前确保流程的高效性。
- 在没有业务建模工具的情况下使用技术建模工具，意味着 IT 需要从头创建模型，并以图纸或纸质文档为基础。正如前面讨论的，这可能会导致误解，可能会延长开发周期。
由于这些原因，最好在使用技术建模工具前使用业务建模工具进行针对执行建模。
建模工具推荐
建模工具的这些功能远远超过了简单的绘图工具和/或文字处理工具所能够提供的功能。可以更为详细地捕获流程，而且准确度更高。鼓励对现有资源进行重用。模拟可为流程重新设计提供支持，而且可以为 IT 开发人员生成有用的构件。图片只是图片，但模型是如何构建某个东西的计划。
无论目标是为文档说明、重新设计还是执行进行建模，这些功能都让 Business Modeler 成了一款理想的工具。
将 WebSphere Business Modeler 作为业务建模工具
业务建模工具显然是最好的解决方案。WebSphere Business Modeler 是业务建模领域的一款行业领先工具。对于所有三个建模原因，Business Modeler 均提供了很多有用的特性和功能。
文档说明
除了任何建模工具的基本文档说明功能外，Business Modeler 还具有以下的额外功能：
- 非技术业务分析人员并不希望了解模型中的技术细节。而 IT 人员恰恰想了解这些细节。Business Modeler 采用了不同的模式来支持这一点：基本 (basic)、中级 (intermediate)、高级 (advanced) 和 WebSphere Process Server。更多的技术用户可以查看对业务用户隐藏的技术属性。不过，虽然业务用户看不到这些属性，但它们仍然属于模型。
- Business Modeler 中的泳道图不仅可以基于工作角色。还可以使用个体资源定义 (individual resource definition)、批量资源定义 (bulk resource definition)、分类器 (classifier)、组织单位 (organization unit) 或 位置 (location)。可以创建自己的分类器，从而基于所定义的任意属性组织泳道图。
- Business Modeler 使用模型，而不是简单的绘图文件。这样就允许多个用户进行协作，使用 IBM Rational ClearCase 之类的存储库进行签入/签出、版本控制和资源锁定。
- Business Modeler 可以使用 IBM WebSphere Publishing Server 发布模型，以便创建的用户直接使用 Web 浏览器查看该模型。用户还可以提供建议和反馈。通过这样，就能让更多的业务用户开展协作，为所建模的流程做出自己的贡献，从而帮助确保流程的准确性和全面性。
- Business Modeler 不仅捕获流程本身。它可以捕获有关组织、角色、资源、限定等等的信息。业务流程的这些方面对于理解流程所运行的环境至关重要。
- Business Modeler 可以生成有关业务流程的静态部分的报告，或者生成跨整个流程目录的查询。
重新设计
- Business Modeler 中的模拟引擎提供了很多高级功能，从而能准确地模拟您的流程。如果模拟不准确，则生成的报告也不准确，可用性也不强。为了更为准确地模拟现实流程行为，可以使用分布、稳定状态模拟、业务项实例和其他功能。
- Business Modeler 中的动态分析包括很多报告，可通过这些报告帮助理解模拟结果。如果标准报告中不包含您希望查看的信息，还可以创建自己的自定义报告。还可以将报告结果导出为带分隔符的文件，以进行进一步的脱机分析。
执行
- 通过模拟验证了流程的重新设计工作后，IT 可以向模型添加额外的技术细节。可以随后导出模型，使用 WS-BPEL、XSD 和 WSDL 等标准为 IT 创建有用的构件。
- 还可以在 IBM Rational Software Architect 重用这些业务模型，从而支持软件架构师基于业务分析人员捕获的信息创建 UML 模型。
- Business Modeler 的技术模型对模型执行更为深入的错误检查。例如，WebSphere Process Server 模式将对模型进行检查，以确保所生成的 WS-BPEL 的正确性。
案例研究
以下案例是绘图工具的模糊不清和建模工具的准确的对比示例。在每个案例中，图形中有待进行进一步解释的内容都在模型中得到了很好的定义。
模糊不清的工作流
我们的第一个案例（图 1）将说明绘图工具通常如何处理工作流关系图（可能非常容易混淆）。从 review request 出来的流是否进入下面的步骤之一？或者同时进入两个步骤中？绘图工具不能提供足够的信息来确定这一点。
图 1. 模糊不清的工作流关系图
将图 1 与图 2 进行比较。Business Modeler 使用分叉 来清楚地指示两个步骤同时执行。模型不存在不明确的地方，而图 1 中的图片的内容则有待进一步解释。
图 2. 不存在不明确内容的流模型
未指示流方向
图 3 显示了一种没有流方向指示的常见关系图样式。流从 verify address 开始？或者，流从 verify part numbers 开始？这完全取决于看图片的人的解释。
图 3. 没有流方向的关系图
将图 3 与图 4 进行比较。Business Modeler 中的连接器可始终说明流的方向。对于哪个任务是第一个任务就不存在任何问题。
图 4. 流方向模型
形状使用不一致
图 5 同时使用圆形和菱形作为判定点。其他人可能会将圆形解释为并行分支的节点。绘图工具不能保证恰当地使用不同的形状。
图 5. 图片中形状使用不一致
在 Business Modeler 中，判定始终使用菱形表示。流程模型保证一致性。请注意，合并 (Merge) 活动将两条路径合并为单条路径。判定还提供业务分析人员认为采用其中每个分支的频率。
图 6. 模型中形状使用一致
图形含糊不清
图 7 说明了绘图工具中的图形混淆的情况。图中的剪贴画小人代表什么？此外，对于跨国企业，相同的图形可能在不同的文化中代表不同的东西。
图 7. 绘图工具中模糊不清的图形使用
在 Business Modeler 中，可使用泳道来指示每个步骤所需的资源，如图 8 中所示。虽然没有使用剪贴画，但现在已说明得相当清楚，verify address 步骤由担任 verifier 角色的人员执行。
图 8. 泳道清楚地说明了所需的资源
或者，还可以给任务添加标签，显示角色信息，如图 9 中所示：
图 9. 模型中的任务标签
数字参考信息
由于需要将图画工具生成的图片与包含文本形式的细节的文档结合使用，因此经常对每个步骤使用数字。随着对流程的不断更新，编号可能变得令人混淆，例如：
- 图 10 中的流程最初的步骤包括 1.0、1.1、1.2 和 1.3。
- 后来在 1.1 和 1.2 之间添加了子流程步骤，其编号为 1.11。
- 再后来将步骤 1.2 删除了。
现在流程流看起来似乎缺少一个步骤。如果需要在 1.1 和 1.11 之间添加步骤，所得到的数字可能会进一步加深混淆。
绘图工具生成的图片中的数字参考信息
在 Business Modeler 中，流程中的每个对象都具有描述它的属性，不需要为步骤维护外部文档。由于不需要外部文档，因此不再需要对步骤进行编号。
Business Modeler 使用了不同的图标来指示 update request 为子流程，而绘图工具中对子流程和任务使用的都是长方形。最后，业务模型还显示数据流，这是在绘图工具中所不包含的内容。
图 10. 模型中的数字参考信息
对其他流程的引用
在绘图工具中，需要引用其他流程时，必须采用文字对其进行描述，如图 11 中所示：
图 11. 绘图工具所生成的图片中对其他流程的文本引用
在 Business Modeler 中，可以右键单击全局流程，然后选择 Launch Global Process Editor，即可自动打开流程，如图 12 中所示。用户不必记录其他说明信息。流程模型提供了指向全局流程的链接。由于这样，管理模型的工作比管理一组图片的工作要容易得多。
图 12. 模型中的自动流程链接
缺少错误检查
在绘图工具中，没有错误检查，也不执行任何规则。图 13 显示了包含 yes/no 判定的流程，但“no”判定没有输出条件。
图 13. 绘图工具中没有错误检查
在 Business Modeler 中，IT 人员可以使用 WebSphere Process Server 模式之类的技术模式。它可标记各种错误，既包括未连接的链接，也包括未定义的条件或其他缺少的属性。这可确保模型的完整性和正确性。
图 14. 模型中的错误检查
含糊不清的逻辑
创建图片的领域专家经常对自己的领域非常熟悉。对于这样的专家，所绘制的图片非常清楚和完整。但对于没有领域专门知识的其他人员而言，绘制的图片可能看起来让人困惑或含糊。
图 15. 绘图工具生成的图片逻辑含混
Business Modeler 可清楚地显示每个路径和逻辑。其模型非常清楚，没有含糊不清的地方，甚至对于不是领域专家的人员也是如此。
图 16. 模型中逻辑非常清晰
结束语
本文说明了为何建模对业务非常重要以及 WebSphere Business Modeler 能够如何帮助针对文档说明、重新设计或执行进行建模。
参考资料 学习
获得产品和技术
关于作者  | 
| | Marc Fasbinder 是密歇根州 Southfield 的 WebSphere Technical Sales 团队的一名 IT 专家。您可以通过与 mfasbind@us.ibm.com Marc 联系。 |
对本文的评价
| 
