扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
引言
WebSphere Business Modeler 中最强大的功能之一就是其模拟业务流程的功能。创建业务模型可以获取业务的各种度量标准，例如执行给定任务所需的时间、涉及的资源以及成本。模拟功能使用这些度量标准来了解业务流程的动态行为。例如，您可能需要确定某个流程的成本在哪里，何处是瓶颈以及资源短缺情况。通过模拟可以发现此类动态行为。
  |
|
模拟的基本概念
在 Modeler 中，您可以创建具有任务、决策和其他流程要素的流程模型。在周密计划流程的这些要素之后，您可以添加文档记录和业务度量。例如，您可以指示某个给定任务使用哪些资源，以及该任务需要这些资源执行的时间。可以记录该任务的成本以及这些资源的成本。然后可以执行静态分析，了解该流程的“非移动”部分。
要了解流程的动态行为，您需要设想如果实际运行该流程的多个实例会发生什么情况，如何使用组织的资源（包括人员和设备）。如果一次出现十个请求，但只有三名人员可用于执行此工作，则其他七个请求只能等待资源可用时才能得到处理。如果查看该流程的工作流，则只能了解它的这些动态方面。对于一个具有大量任务的流程而言，在数学计算方面会十分复杂。显然，这时需要使用工具来提供这方面的帮助。
在一个流程使用资源并执行任务时，便会产生相应的资源成本，例如员工工资和材料成本。有些任务还可能会产生收入。在业务层面，了解这些成本对于定义流程回报非常重要。您需要了解某个流程花费的时间，包括资源在执行任务上花费的时间，以及与等待工作相关的时间。需要收集这些业务数据才能了解流程的工作方式。只有充分了解一个流程才能对该流程进行改进。
为实现这些目标，Modeler 中提供了一个强大的模拟引擎。要模拟某个流程，您只需定义如下内容：
不过，如果希望执行更详细的报告，则添加更多属性（例如关于组织的成本和详细信息）可以更好地利用预定义报告。
模拟引擎可以向您显示流程的实际运行方式。模拟流程不需要花数天时间完成，只需在几秒钟内即可运行。这意味着您可以快速查看实际上需要更长时间（例如数周甚至一个月）的流程的结果。还可以对流程进行更改以快速执行条件分析。
|
|
导入演示示例
我在本文中提供了一个演示，该演示含有多个示例。您可以下载这些示例，并将它们导入 Modeler 高级模拟功能中，以便按本文介绍的步骤进行操作。
Modeler Archive (MAR) 文件 simulation-demo.mar 含有用于该演示的流程。要将该文件导入您的工作站：
重要：Windows 对文件名和路径有 256 个字符限制。由于此演示使用多层文件夹，并且 Modeler 还需创建一些子文件夹来存储元数据，因此您可能会收到 Modeler 由于文件名太长无法导入 .mar 文件的消息。如果出现这种情况，则需要使用更靠近根目录的工作区，和/或使用较短的项目名。
|
|
流程案例研究
在本例中共包括三组流程案例研究。第一组使用一些较小的流程片段演示多个不同的流程改进模式。您将了解如何确定流程中的问题，如何纠正问题，以及如何分析流程中的改进。我提供了原有（当前状态）流程及其缺陷，还提供了将来（未来状态）流程及其改进。
第二组流程包含对多个高级功能的研究，以便了解模拟功能的工作方式。通常，从工作示例中更容易学习，不必从头进行构建。
最后一组流程包含一些完整的示例。这些流程显示了一些全面的端到端场景，这与第一组案例中的代码片段不同。这些示例是为了更接近实际的业务流程。
通过综合使用这些示例流程，您将学习如何运行完整的模拟演示，了解 Modeler 的许多极为重要的特点和功能。
对于每个案例研究，我已经运行了模拟。您可以将现有的模拟结果用于动态分析，也可以自己重新运行模拟。已经对每个模拟配置文件进行了设置，可以运行流程的多个实例。在大多数情况下，该设置总共可用于 50 个令牌。使用较大数量的令牌可以得到更高的模拟准确率。如果运行两个模拟实例，并对 yes 和 no 路径将决策设置为 50/50，则这两种令牌可能会得到相同的输出。如果使用更大数量的令牌，则对每个输出，令牌总数更可能接近于指定的 50%。具有大量实例的模拟可以减少任何随机的反常情况，例如减少对结果的偏差。建议关闭动画，以便模拟运行得更快一些。
在每个模拟配置文件中还设置了资源池。如果为其中一个示例创建新的模拟配置文件，则也需要设置此资源池。
|
|
流程改进模式
这一部分介绍一些流程片段，您可以使用这些片段了解原有流程中的一些常见流程缺陷，以及在将来模式中进行的一些改进。对于每个模式，我从动态分析角度介绍了要运行的相应报告。模式的编号与 .mar 文件中的示例相对应。本部分向您介绍如何使用模拟来标识原有流程中的问题，并介绍如何使用模拟和动态分析方法将其与将来版本进行比较以显示改进之处。
1.1 高成本路径
一个流程可能含有多个可能的执行路径。有时候，一个路径会比另一个路径的成本高得多。如果流经高成本路径的案例百分比能够降低，则可以明显地节约成本。
图 2. 使用高成本路径的原有流程
在图 2 的原有流程中， Log Request 任务是自动执行的，并将请求放入数据库。如果需要进行验证，则流程将流向手工 Validate Request 任务。然后将路径联合起来并处理请求。这是一个简化示例，但它演示了该模式。
图 3. 使用自动验证的将来流程
在流程的将来版本中（图 3），将尝试使用一个新任务自动验证请求。有些案例仍然需要手工工作。不过，流程中该路径的百分比减少了。具有高成本路径的运行频率更低，从而可以实现流程的节省。
要运行的报告
动态分析 - 流程案例分析 - 流程案例摘要——在这一报告（图 4）中，您可以看出具有手工工作的路径耗时较长，并且成本也较高。
图 4. 流程案例摘要
动态分析 - 流程对比分析 - 流程成本对比——在这一报告（图 5）中，您可以看出避免高成本路径可以节省资金。
图 5. 流程成本对比
1.2 向人工任务发送电子邮件
许多业务的流程都基于从一人发送到另一人的电子邮件。在将电子邮件发送到下一个人之前，通常附带一个电子表格，用户可以在电子表格中输入数据并进行审批。
对于此方法，存在多个问题。例如，简单邮件传输协议 (SMTP) 电子邮件不是一个有保证的邮件传递机制。它不能进行跟踪，因此不可能知道流程所处的状态。如果电子邮件收件人不可用，则管理员将无法向其他人重新分配工作。如果电子邮件在 Bob 的收件箱中，则在他打开邮件之前将一直放在收件箱里。如果由于 Bob 处于离开状态而向其他人发送新电子邮件以安排完成这一工作，而当 Bob 回来时，尽管工作已经完成，他仍然可以看到该电子邮件并可能试图处理该请求。
这些示例说明了为什么基于电子邮件的流程是反模式的，并且应该避免。
图 6. 使用手工步骤的原有流程
在原有流程（图 6）中，存在三个级别的审核，全部都是手工步骤。从一个人到另一个人的工作流基于电子邮件。当一个人收到电子邮件时，他们必须分离电子表格，编辑它并将其保存。然后创建一个新电子邮件，附加更新的电子表格，并将电子邮件发送到链中的下一个审核人。
将来流程与此相同，只不过应用了工作流，而不是使用电子邮件。所有需要的信息都提供给用户，省去了对电子表格的需要。手工工作越少，每个任务所需的时间就越少。因此，流程就更高效。
要运行的报告
动态分析 - 流程对比分析 - 流程成本对比——在这一报告（图 7）中，很明显，即使使用非常保守的数值，也可以看出明显降低了流程的成本。还可以得到一些其他方面的无形好处，例如可以监视流程状态，将工作从一个用户传递到另一个用户，甚至可以向组分配工作。模拟只能看到流程的一些有形好处。
图 7. 流程成本对比
1.3 手工审核与基于规则的审核
通常在业务流程中，在进一步处理请求之前需要审核请求。许多时候，原有流程包括一个手工步骤，以便相关人员可以进行审核，因为始终是通过这种方式执行的。不过，如果自动业务规则可以用作审核机制，即使是百分之一的时间，也可以实现显著的成本节约。
在原有流程中（图 8），执行审核的步骤是手工进行的。
图 8. 手工审核原有流程
图 9. 自动审核将来流程
在流程的将来版本中（图 9），Approve Request 步骤是使用业务规则执行的，而不是人执行的。
要运行的报告
动态分析 - 流程对比分析 - 流程持续时间对比——在这一报告（图 10）中，您可以清楚地看到，通过删除手工工作，对请求的处理可以快许多倍，并且成本更低。
图 10. 流程持续时间对比
如果相关人员不添加值，而只是检查请求并且做一些可以自动执行的任务，则可以节约时间和成本，必然会改进流程。
1.4 手工查找自动服务
在许多时候，业务流程需要访问驻留在业务系统中的数据。例如，您可能需要验证数据或将请求的数据添加到客户记录。在一些业务流程中，此工作是通过相关人员的手动操作完成的。例如，他们可能要登录到“绿屏”应用程序，检查数据，然后继续处理请求。
不过，当相关人员执行此类工作时，他们不需要添加值。他们通过使用业务流程自动化可以更快地完成工作，而且准确性更高。
图 11.手工查找原有流程
在原有流程中（图 11），Lookup Customer Data 步骤是手工进行的。一个人员登录到遗留应用程序查找信息，并将信息添加到客户请求记录之后才能进行处理。此活动将是服务的一个理想候选活动。在将来版本中，将使用自动活动执行查找任务。
要运行的报告
动态分析 - 流程对比分析 - 流程持续时间对比——在这一报告（图 12）中，您可以看到基于自动审核在流程时间上有明显的改进。
图 12. 流程持续时间对比
1.5 手工流程到自动流程
在有些情况下，某个流程中的所有步骤都是手工的。通常，在流程中保留手工步骤是因为该流程始终是这样完成的，或者使用计算机执行此业务不合适。通过自动化流程，可以显著节约成本和时间，这样做非常值得。
图 13. 使用手工步骤的原有流程
在原有流程中（图 13），工作是手动完成的。分类器显示尽管每个步骤都是手工执行的，业务分析人员相信它们都是可以应用工作流的潜在区域。在此特定的流程中，在各个步骤之间进行的是书面文档传递。传递书面文档需要花费一些时间，因此将任务持续时间设置为 20 分钟，而将资源持续时间设置为 15 分钟。这为每个任务留下了手工交付书面文档的时间。
图 14. 使用自动步骤的将来流程
在该流程的将来版本中，分类器显示该流程现在应用了工作流。处理时间缩短了，因为工作流为用户提供了他们执行作业所需的所有信息，缩短了任务的时间。任务的信息现在通过电子方式传递，省去了等待书面文档的延迟。
要运行的报告
动态分析 - 流程对比分析 - 流程持续时间分析——在这一报告（图 15）中，您可以看到将来流程的速度是手工流程的二倍。
图 15. 流程持续时间对比
1.6 消除瓶颈
有些流程包含一些瓶颈。例如，如果在某个特定步骤中缺少资源，即使其余流程可以执行得特别快，但该工作仍然会在瓶颈步骤受到阻止。确定并从流程中去除瓶颈可以极大地节省流程的时间和成本。
图 16. 具有瓶颈的原有流程
在原有流程中（图 16），在自动验证数据之后，高速打印机将打印物理检查。Print Check 任务只占用打印机的一秒时间。需要用五秒钟的活动持续时间来安排到打印机有序传输数据。不过只有一台打印机，因此模拟运行时，您会看到任务队列排在 Print Check 任务之前。在 Modeler 中，如果在模拟配置文件中将 Print Check 任务的最大模拟任务数设置为 1，则传入令牌将排队等待打印机可用。
图 17. 无瓶颈的将来流程
在该流程的将来版本中（图 17），物理检查打印瓶颈替换为电子资金传输。用于此传输的服务更慢，需要 2 秒。不过，对于此类服务，可以同时运行无限多个此类任务。即使任务占用的时间较长，但消除了瓶颈，并且令牌不用再排队。
要运行的报告
动态分析 - 流程对比分析 - 流程持续时间对比——在这一报告（图 18）中，您可以看到没有瓶颈的限制，流程的吞吐量增加了许多。
图 18. 流程持续时间对比
1.7 资源短缺
流程中有一种瓶颈是长期缺少资源。例如，在一个部门有十名工作人员。如果没有正确分配任务，则可能会造成一组资源工作负荷太重，另一组却无事可做。正确平衡工作负载对业务流程有积极的影响。
图 19. 存在资源短缺的原有流程
在图 19 的流程中，对两个任务都使用了 Payroll Admin 角色。对于原有流程，在模拟中将此角色的资源池设置为用于两个任务，如图 20 所示：
图 20. 资源池设置
在运行模拟时，创建工作的速度比所分配的资源能够处理的速度还要快，因此会出现资源短缺。此流程的将来版本与此完全相同，所不同的是运行模拟时资源没有限制。
要运行的报告
动态分析 - 聚合分析 - 活动资源分配——对原有流程的这一报告（图 21），您将看到流程资源短缺的平均持续时间。在将来流程中（图 22），短缺持续时间为 0。一般情况下，如果看到此资源短缺消息，就可以知道需要分配更多的特定资源，从而达到优化流程的目的。
图 21. 原有活动资源分配
图 22. 将来活动资源分配
动态分析 - 流程对比分析 - 流程持续时间对比——这一报告（图 23）显示了，如果正确设置资源数量，则可以明显改进流程。
图 23. 流程持续时间对比
1.8 顺序执行与并行执行
有些流程是由一系列任务构成的。有时按顺序执行的一些任务也可以并行执行。例如，如果两个任务没有相互依赖关系，则它们可以由两个不同的资源并行完成，从而使总体流程运行得更快。
图 24. 使用顺序步骤的原有流程
流程的原有版本（图 24）有三个步骤，这三个步骤均由不同的资源在收到书面文档后执行。但是，这些任务相互没有依赖性。例如，可以将新雇员添加到电话系统之前或之后将其添加到标记系统。如果使用电子文档而不是当前的书面文档，则这些步骤可以并行执行。
图 25. 使用并行步骤的将来流程
在此流程的将来版本中（图 25），这些步骤现在是并行执行的。步骤使用分叉 分出，并使用联合 返回。在使用联合时，所有传入路径必须在流程继续之前运行。如果使用了合并，则一旦评估任何一个路径，它就会继续执行。可以将合并视为 OR 操作，将联合视为 AND 操作。在此流程中，所有三个路径必须在流程继续之前完成。这里联合操作是必须的。
要运行的报告
动态分析 - 流程对比分析 - 流程持续时间对比——在这一报告（图 26）中，您可以看到，即使任务按照完全相同的方式完成，而且具有相同的成本，但流程时间却减少了一半，原因是这些步骤是并行完成的。
图 26. 流程持续时间对比
流程改进模式摘要
您可以使用每个流程改进模式作为示例，了解一些典型案例，以便优化您的业务流程。例如，在分析原有流程时，可以运行 1.7 部分中的 Activity Resource Allocation 报告，了解是否正确平衡了资源。通过查看流程和了解完成工作的方式，您可以确定按顺序执行的步骤能够并行执行，如 1.8 部分所示。综合运用所有这些模式可以明显改进流程。
|
|
高级功能
本部分分析几个高级模拟功能。
2.1 业务项实例
在运行模拟时，您可以使用决策百分比来控制流。还可以为流程中的业务项定义实际数据值，并使用为决策定义的表达式逻辑。使用此技术可以发送在流程中切实可行的数据，并可以查看结果。此数据称为业务项实例。
图 27. 业务项设置
在图 27 的示例中，我们在一个非常简单的流程上下文中使用了 NewEmployeeData 业务项，如图 28 所示：
图 28. 使用业务项的流程
在此流程中，在一个自动任务验证数据之后，如果被雇佣的人员是返回的员工或者新雇员，则流程将转入不同的路径。为进行模拟，这里没有实现子流程。只对每个流程设置了持续时间。要模拟业务项实例，您需要创建这些实例本身。我根据表 1 创建了四个实例：
表 1. 实例数据
| 名字 | 姓氏 | 社会保险号 | 重新雇用 | 开始日期 | |
|---|---|---|---|---|---|
|
新雇员 1 |
John |
Doe |
123-45-6789 |
否 |
03/06/2007 |
|
新雇员 2 |
Jane |
Doh |
234-56-7890 |
是 |
04/01/2007 |
|
新雇员 3 |
Jim |
Dough |
345-67-8901 |
否 |
03/27/2007 |
|
新雇员 4 |
Jill |
Dow |
456-78-9012 |
否 |
根据下列步骤创建业务项实例：
Rehire 字段设置为 Yes，则会运行 Yes 分支。通过将基本模式更改为中级模式或更高模式，您可以使用表达式生成器为业务决策定义实际逻辑。确保先单击 Apply 然后单击 OK 保存表达式。 
当模拟运行时， Rehire 字段的数据将通过第一个任务，因此它可以由决策使用。当模拟运行时，它不使用 50/50 的百分比，而是使用决策的实际逻辑。您可以在动态分析 - 流程实例摘要报告中查看结果（图 38）。随着示例大小增长，它将更加接近本例中使用的业务项的预期 75/25 比率。
图 38. 业务实例摘要
业务项实例模拟摘要
在模拟中使用业务项实例非常有用，特别是希望测试逻辑或者根据实际数据运行模拟时更是如此。由于您可以设置业务项的值，因此可以通过使用常数值将字段更改为“已验证”，而不使用本例中使用的表达式。
您可以使用 Modeler 中的 XML 导入和导出业务项实例。如果希望使用实际生产数据运行模拟，则可以从 XML 中将其导入，这样就不必手动创建每个业务项实例。如果需要使用大量的不同业务项实例，这会非常有用。
2.2 分布
当在模拟中指定时间时，您可以使用不发生改变的静态值，例如 5 分钟。不过，在现实生活中，任务在每次运行时并不是始终正好用 5 分钟的时间。有时可能用 3 分钟，有时可能用 8 分 47 秒。可以使用分布 将时间多样化，以便给出更实际的结果。Modeler 提供了各种分布方式，可以更准确地模拟现实世界的行为。
在本例中，共有两个流程，表示一个人员在支持部门工作。原有流程对其任务使用 Specific Value，指定该任务需要 30 分钟的执行时间。模拟程序创建任务的速度是每三十分钟创建一个任务。该工作从来不用等待资源，因此也从不会有延迟。我的模拟程序运行了 500 个流程，以确保有足够多的示例大小是相对精确的。在此情况下，客户让一个人在其支持部门，因此将 Maximum Simultaneous Tasks 设置为 1。
在许多任务中，时间可能有非常大的变化。例如，在呼叫中心，大多数电话都可以快速答复，因为传入的大多数问题都是相同的。有时可能会出现较难解决的问题，这可能会导致资源花费更多的时间解决该问题。如果模拟的流程有此类任务，使用分布方式将会取得更准确的模拟结果。
在流程的将来版本中，我使用 Exponential 分布将该任务的持续时间模拟为平均 30 分钟，如图 39 所示：
图 39. 使用分布方式的 Duration 选项卡
如预期的那样，原有流程从来没有延迟。每隔 30 分钟就会有一个任务进入，而且每隔三十分钟前一个任务就会完成。所有案例使用的时间都正好是 30 分钟，如图 40 所示。如果您使用的是这种模型，则会认为用于该任务的资源已足够用，因为工作从不延迟。
图 40. 不使用分布方式的流程持续时间
现在我们分析一下使用分布方式模拟的结果（图 41）。实际对任务执行操作的时间，即 Working Duration，接近于 30 分钟。但是，包括在执行任务前排队等待时间的 Elapsed Duration 却是 11.5 小时！平均下来，任务需要的时间是 30 分钟。不过，使用准确模拟现实世界的分布，您可以看到工作会有明显的延迟。
图 41. 使用分布方式的流程持续时间
分布方式摘要
这里通过使用一个非常简单的示例说明了如何使用分布曲线建模持续时间，这与静态特定值不同，静态特定值会导致完全不同的模拟结果。上例是一种极端情况，但它解释了为什么在模拟中适当使用分布方式非常重要。
2.3 循环
有几种任务需要创建正确模拟并导出到 WS-BPEL 的循环。有关摘要信息，请参阅 Using Loops in WebSphere Business Modeler v6 to improve simulations and export to BPEL（developerWorks，2007 年 3 月）
图 42 显示了具有向后流向连接的原有流程。图 43 显示了使用可以正确导出到 WS-BPEL 的循环正确建模的将来流程。
图 42. 使用向后流向连接的流程
图 43. 使用循环的流程
如果使用向后流向的连接而不是循环，则模拟可以正确运行，但无法将流程导出到 WS-BPEL。最佳做法是避免使用向后流向的连接器。
|
|
完整流程
本部分提供一些完整流程，与前几部分中仅使用一些流程片段不同。
3.1 流程开发
Modeler 是在业务驱动的开发 (BDD) 周期中使用的关键工具。有人可能会问：如果开始使用 Modeler 而不使用传统的开发流程，是否确实可以节省时间和成本？Modeler 的模拟功能可以回答这些问题。
在本部分中，我建模和模拟了一个传统的开发流程。流程的原有版本使用绘图工具来记录流程，而不是开始就使用模型。由于图片捕获的流程信息不能满足 IT 人员在开发中使用，因此还使用了一个文档处理程序。在本案例研究示例中，绘图工具称为 Whiz-IO，文档处理程序称为 Wurt。在记录流程之后，IT 人员开始使用 WebSphere Integration Developer 构建流程。
图 44. 部分流程开发模型
在该流程的将来版本中（图 44），我们将绘图工具和文档处理程序替换为 Modeler。IT 将技术属性添加到模型，然后将其导出，而不是手工创建所有内容。图 44 仅显示了流程的第一部分，有关完整流程，请参阅下载的 zip 文件。
在这两个模型中，您会注意到业务分析人员和 IT 人员反复返工的循环，直到他们对有关如何开发的业务合同达成协议为止。在使用 Modeler 的将来流程中，此返工循环的平均反复次数比较少，因为模型的表现比较准确，而图片则不够明确。
要运行的报告
动态分析 - 流程对比分析 - 流程持续时间对比——在这一报告（图 45）中，可以明显地看出，即使保守评估，减少的时间也有 20%。
图 45. 流程持续时间对比
动态分析 - 流程对比分析 - 流程成本对比——在这一报告中（图 46），您可以看出，流程的将来版本节省的资源成本超过 30%。
图 46. 流程成本对比
流程开发总结
与传统的开发周期相比，模拟清楚地显示了使用业务驱动的开发可以节省时间和金钱。
3.2 贷款审核
此部分的原有贷款审核流程包含流程改进模式部分中介绍的许多流程缺陷。本部分不是分析一些流程片段，而是分析一个完整的流程。将来版本提供了建议的流程改进。您可以比较这两个流程，来帮助调整流程自动化的成本。
图 47. 贷款审核流程第 1 部分
原有流程（图 47）是基于书面的流程。书面贷款申请首先转到数据验证员，验证员在遗留计算机系统中查找客户信息，并将这些信息与书面申请中的内容相比较。如果需要，验证员将联系客户并更新系统。这是一个应用模式的很好机会，以便使用自动服务替换手工工作。只有存在数据误差时才引入手工工作。应将宝贵的人力资源仅应用于能够增加业务价值的区域。此流程的将来版本使用贷款申请的电子版本，包含了这些改进。
继续执行该流程（图 47），贷款处理部门执行三个步骤。他们从计算机系统中调出客户历史记录，打印记录，并将其添加到文件夹。他们还通过联系两个信用机构确定客户的信用记录。在完成这些步骤之后，内部业务规则推理引擎将计算贷款风险。前两个任务相互没有依赖性，这意味着它们是应用并行方式执行顺序工作模式的理想对象。还可以自动执行全部三个任务。例如，不将贷款信息输入业务规则推理引擎然后写入结果，而是使用一个服务执行所有工作，从流程传递数据。
图 48. 贷款审核流程第 2 部分
在评估贷款风险后，下一步是抽出 5% 的贷款申请进行审核，如图 48 所示。审核员重新检查数据的有效性，确保没有出现错误。他们还将重新运行风险评估，并确保风险评估也准确无误。了解其工作可能会被审核有助于贷款处理部门的员工诚实工作，同时可以降低风险。如果任务是自动执行的，而不是手工操作，则可以消除不准确的数据、人工错误和审核的必要。在该流程的将来版本中这些步骤已不必要，如图 49 所示：
图 49. 贷款审核流程第 3 部分
该银行不接受高风险贷款，因为这是一家非常谨慎的金融机构。他们将高风险贷款提交到精通风险贷款的下级主要贷款方。银行必须首先联系客户，以便得到他们的允许将其信息传递到其他贷款方。贷款处理部门的人员联系客户。如果客户同意，贷款处理部门将其信息导入到下级主要贷款方的 Web 应用程序。贷款处理部门的资源然后存档书面材料并更新客户历史记录。在该流程的将来版本中，仍然需要联系客户，但可以通过电子方式完成对其他贷款方的更新，节省了时间和金钱。
图 50. 贷款审核流程第 4 部分
如果贷款被确定为中等风险或低风险，则将书面文件夹提交到负责最后贷款审批的信贷员。他们需要搜索所有文档，查找进行决策所需的信息。在应用工作流的将来流程中，我们将贷款记录中的信息整合到一个屏幕上，这样他们可以随手得到进行决策所需的全部信息。这将能够节省时间和减少错误。
如果贷款得到批准，就会将其发送到贷款完成部门。如果被拒绝，则客户服务将联系客户，贷款处理部门整理书面材料并停止申请，更新客户历史记录系统，并将书面材料存档。在该流程的将来版本中将自动执行这些手工任务。
模拟流程
我使用 500 个流程实例模拟了原有流程和将来流程，并且令牌创建频率为每五分钟一个。表 2 中的数据用于资源数：
表 2. 用于模拟的资源数
| 原有流程 | 将来流程 | |
|---|---|---|
|
数据验证员 |
10 |
0 |
|
贷款处理 |
20 |
10 |
|
信贷员 |
5 |
5 |
|
审核员 |
2 |
0 |
|
客户服务 |
20 |
20 |
由于我们应用了流程自动化技术，应用于原有流程的资源数减少了。
要运行的报告
动态分析 - 流程对比分析 - 流程持续时间对比——在这一报告（图 51）中，您可以看到，从流程中消除书面工作和进行其他改进使流程有了显著不同。这些工作不是需要几天才能完成，而是几小时就可以完成。
图 51. 流程持续时间对比
动态分析 - 流程对比分析 - 流程成本对比——这一报告（图 52）显示了流程的将来版本的成本要低得多。我们减少的资源成本超过 93%！成本的减少说明只需几个月就可以收回项目成本。
图 52. 流程成本对比
动态分析 - 聚合分析 - 活动资源分配。图 53 中的原有流程分析清楚地显示了由于资源短缺而导致工作延迟。除贷款完成角色外，其他所有角色都有短缺。需要向所有其他角色添加其他资源才能得到一个高效的流程。如果将添加其他人员的成本与自动执行流程的成本相比较，可以十分清楚地看出流程自动化是一个更好的长期解决方案。
图 53. 原有流程活动资源分配
通过比较，图 54 中的将来流程显示仅有一个资源是流程的瓶颈：即信贷员。由于大多数任务都是自动执行的，对可以并行执行的资源数量几乎没有约束。银行可能会确定即使存在小小的瓶颈，在性能方面也足足够用。随着规模的扩大，他们了解到需要增加更多的信贷员才能保证流程尽可能有效。
图 54. 将来流程活动资源分配
动态分析 - 流程案例分析 - 案例摘要。在原有流程中运行这一报告（图 55）时，很明显存在多个高成本路径（案例 8-10）。将来流程的目标是尽量避免这些路径，或者至少减少高成本路径的使用次数。
图 55. 原有流程案例摘要
图 56 中的将来流程案例摘要显示了更多可能的路径，但没有一个接近于原有流程中路径的成本。案例 14 花费的时间超过一天，但是看一下详细信息可以知道，它的运行频率为五百分之一。由于它的使用频率特别低，因此不值得花费时间进一步改进此路径。
图 56. 原有流程案例摘要
贷款审核总结
通过本例，您可以在较大的业务流程环境中应用前几部分中的许多流程改进模式。每个单独的改进都可以得到一个积极效果，如果综合起来，则可以获得显著的改进。
|
|
结束语
本文阐述了如何使用 WebSphere Business Modeler 的模拟功能改进业务流程。我们研究了高级模拟功能并分析了完整的流程示例，向您介绍了如何将不同的流程改进模式应用于完整的业务流程。
如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅至顶网技术邮件将是您的最佳途径之一。
京公网安备 11010802021500号