在他最近的博文中,Keith Swenson 注意到,就业务流程仿真的有用性,人们经常进行争论,他还描述了参与其中的两大阵营。
仿真乐观者可能期待对未来的用例在整个流程里如何运转的更为详细的了解。
乐观主义者期待着,对于流程里面的每个人所做的事情有着精确的量化手段。仿真能提供这一信息,但为了能做到这一点,仿真器对于将要发生的用例,处理每一活动所需的时间,以及执行任务的工作者的模型都必须提供精确的量化手段。只在当你拥有大量本质上一样的用例时,而且工作者个人的技术、知识或背景差异并不会对工作造成任何影响时,这勉强是管用的。就算在这种情况下,追踪活动时间和用例分发的精确信息所花费的努力,都远超从仿真结果中能获得的价值。尽管这些乐观主义者对此的期待过于膨胀,但对于仿真能够在相对直接的场景下给予你一些很好的信息,这一点却从未有过否认,比如“如果我的负载增加 20%,我需要在哪里增加资源”或“如果我消除了一步 90% 不太可能出现的用例,其节省出来的时间与低概率问题预计所带来的成本相比,孰高孰低?”
悲观主义者通常对于仿真没有什么期待,但这样他也假设到:
……运行一个仿真提供了观察模型内部自身动态的能力,这有助于理解流程是如何被建模的。正规的图形化模型对于大多数人们来说并非完全是自然的,而我们都可以通过帮助来理解这一模型。这种类似“调试”的能力使得业务分析师在进入下一步开发之前可以找出一些基本的问题。
评估仿真对于这两大阵营的重要性,Keith 写到:
对于悲观主义者而言,仿真非常重要,因为它允许业务人员赶在问题转换成系统领域的模型之前,在业务层次处理问题模型。因为在一定层次的错误在转换之后会被放大,所以在进入下一层次之前想尽办法进行调试显得尤为重要。
他同时注意到:
对于乐观主义者来说,其问题是:关于业务领域模型的仿真与系统领域或规则制定领域,或许相关,也或许无关。如果这一模型为了实际的执行而转换,花费大量的时间来构建一个精确的工作者和用例负载的模型,可能得不到任何东西。一旦模型发生了转换的话, 所找到的一个特定的资源层次所产生的通过业务模型的最佳的运行流,可能最终会变为不是那么适宜了。在系统领域或规则制定领域进行仿真会给你更好的结果,但这些模型对于业务分析师而言没有意义,而且如何合适地将其转化为业务领域内的用例并不十分明显。仿真乐观主义者会发现当模型转换了的时候,仿真会变得非常复杂。
Bruce Silver 进一步详细阐释了这一话题,他发现流程仿真“有着极大的价值”,但只有在仿真工具非常好的情况下才是如此。他定义了七个仿真工具应该支持的最重要的特性:
- 事件机率与发生时刻。在 BPMN 中,事件为描述现实流程中发生的异常提供了一个易于表达的可视化语言。实际上,这些异常通常是现有流程性能问题的根本。为了达到所预期的改进,你需要能为流程模型中的事件分配一定发生机率与平均发生时间。
- 重复活动。BPMN 有两类重复活动,称作循环 (DoWhile) 和多实例 (ForEach)。你需要一个仿真参数来对迭代次数进行建模。
- 实例性质。在许多仿真模型中,每个节点的机率是互不相关的。在真实世界的流程中,他们是高度相关的。比如,一个特定任务持续的时间,从某个特定网关输出的机率,还有一些事件发生的机率,通常是相互追踪的。换句话说,特定类型的实例可能会需要更长时间,更倾向于从 path1 而不是 path2 的网关输出,并且比一些普通的传输中的事件有着更高的机率……一种办法是不要将仿真参数定义成一个简单的数字 (平均数和标准偏差),而是定义为由一个或多个实例性质而组成的表达式,就像有序值,可以取高,中,低。这使得配置实例生成更加复杂,因为你需要定义每个类型的比率,但这样会得出好得多的结果。
- 灵活的资源分配。大多数仿真工具允许你用一些定义好的每小时成本或每次使用成本等参数来将任务分配给角色,或者分组。但没有多少能够让你进行这样的操作,分配角色 A 作为主要资源,但如果角色 A 的成员都不可用,就分配给角色 B。
- 预先设置积压事件。仿真模型通常一开始是空的,意味着系统中没有实例。除了仿真初始时明显的失真期间以外,这不充许资源分配优化用例在真正需要的时候被实施,比如,当一个真正运行的流程被积压事件所阻塞,而你需要尝试各种替代方案来解决它的时候。
- 获取原始的输出。仿真工具提供的预置矩阵和图表十分方便,但很少能提供你真正分析所需要的细节。对于此你需要的是原始输出,每个流程实例一份记录,同样的每个活动或事件也各一份记录,倾注入 Excel 或数据库。基于此你可以创建历史图表,提供基于活动的成本核算,并执行其它有用的分析。没有它的话,你只是华而不实的。
看似仿真乐观主义者和悲观主义者都能从仿真工具的提升中得到收益,这将提高仿真结果的质量与可靠性。
评论