一个组织由两个世界组成。现实世界包含组织的结构、实物商品、员工和其他组织。虚拟世界包含组织计算机化的基础设施,包括其应用程序和数据库。工作流系统弥合了这两个世界之间的差距。它们既提供了组织设计的模型,又提供了执行该模型的运行时。
组织不断发展演变。工作流模型以可见的方式表示组织的设计。工作流运行时解释工作流设计。模型可见性和与模型相关的组织执行相结合,促进了组织计算机化基础设施的自上而下和自下而上的演变。
自上而下的演变包括高管、业务经理和业务分析师决定他们希望如何改变组织的目标和运营。修改工作流模型以匹配已更改的目标。当现实世界与虚拟世界之间的不匹配导致组织目标未实现和组织异常生成时,就会发生自下而上的演变。这些不匹配可以追溯到工作流模型,而工作流模型又可以追溯到组织目标。然后更改组织目标和工作流模型以减少不匹配。工作流系统还用于测试更改后的模型是否修复了不匹配。先前工作流执行的跟踪将通过新模型重新运行,以查看它们是否改进了组织的运营。
组织模型必须同时捕获其结构化和非结构化部分。组织的非结构化部分使用各种组织数据流设施,例如邮件、电子邮件、事件和消息。结构化部分使用组织结构图和流程图。工作流模型将数据流、组织结构图和流程图联系在一起。
工作流模型也跨组织边界定义,以促进组织之间的贸易。公司联盟和标准组织正在定义组织间工作流模型。
组织是由共同目标约束的参与者和技术的集合。它与环境形成边界,创造了组织内部和外部的概念。它被组织起来以实现其目标,并具有一定的效率概念。W. Richard Scott 将组织分为以下几类:1
• 理性型 (Rational)。 集体导向于追求相对具体的目标,并表现出相对高度正式化的社会结构(例如,企业)。
• 自然型 (Natural)。 集体,其参与者对系统的生存具有共同的兴趣,并从事非正式结构化的集体活动以服务于此目的(例如,宗教或慈善机构)。
• 开放型 (Open)。 轮班利益集团的联盟,通过谈判制定目标;联盟的结构、其活动和结果受到环境因素的强烈影响(例如,标准组织)。
所有组织都具有所有这三个类别的要素。组织的理性部分是那些最成功地实现计算机化的部分。工作流系统将计算机化扩展到组织的自然和开放部分。
工作流系统取代了组织处理中主要手动完成的部分,并将这些部分与传统的计算机业务应用程序集成在一起。因此,工作流系统的连续统从手动工作流处理开始,在手动工作流处理中,组织员工执行流程并使用计算机作为助手。以下部分描述了工作流系统的连续统,从手动消息传递到建模工作流。这些部分在连续统中按如下方式排列
工作流系统需要处理进入组织的任何类型的消息。组织不会因为不认可客户使用的消息格式而拒绝客户。客户使用语音、传真、短信、电子表格以及二进制或 XML 格式的文档进行通信。如果消息的格式结构良好,例如已知的二进制格式或具有已知模式的 XML,则工作流系统可以直接处理消息;否则,工作人员需要手动执行客户的请求,或手动将其输入到组织理解的消息格式中。
消息可以路由到正确的员工进行处理。仅将消息直接发送给个人是不够的。该人可能不再为组织工作,可能正在休假,或者工作量过大。工作流系统使用角色的概念,角色是组织职位,可以为其分配一个或多个个人。角色分配是一个资源分配问题,工作流系统对此分配进行建模。如果角色包含个人集合,则分配将尝试找到集合中最佳的人员来处理消息。这可以考虑个人的日历、技能水平和负载。
消息也可以路由到工作流。消息要么启动工作流(创建工作流实例),要么发送到正在等待消息的持续工作流实例。消息由其类型和 ID 标识。当 ID 用于与正在运行的工作流通信时,它被称为关联 ID。
注释在消息处理时添加到消息中。这相当于在手动表单上添加便签。例如,对订购项目的注释可以指定已替换等效项目,并获得客户的批准。
工作项指定了组织工作人员需要执行的任务。工作人员由其角色标识;工作项由消息标识;角色由队列标识。当工作项出现在与角色关联的队列中时,工作人员会收到需要注意的工作项的通知。工作项完成后,工作人员向工作项请求者发送消息,指定结果。
在执行工作项指定的任务时,工作人员有很多选择:手动处理工作项,启动其他工作项或工作流以帮助完成任务,或将代理分配到角色队列,该代理自动处理某些工作项,工作人员处理异常情况。
如果工作项发生在工作流系统的上下文中,则系统会启动工作项,并且通常会等待其完成。工作流系统的任务是与所有未完成的工作项进行协调。其中一些任务如下
• 同步 (Synchronizing)。 多个工作项通常被建模为并行拆分和并行联接。拆分发送多个工作项,联接等待它们完成。并行联接的条件可能任意复杂。例如,工作流可以等待所有项目完成,或项目子集完成,或来自一位经理和两位非经理的项目完成,或者当大多数工作项投票接受或拒绝问题时,联接可以完成。
• 超时 (Timeouts)。 工作流实例可以永远等待工作项完成。因此,工作项具有超时。当超时事件发生时,等待的工作流实例将唤醒并开始处理超时条件。
• 管理工作流实例内存 (Managing workflow instance memory)。 工作流系统同时处理大量工作流实例。等待工作项响应的时间可能很长。为了防止系统阻塞,等待的工作流实例被序列化到后备存储中。当消息发送给它时,它会被反序列化并重新激活。此过程也称为工作流的注水和脱水。由于永远不能假定工作流处于运行状态,因此与工作流实例相关的所有消息和事件都首先由工作流系统接收。然后,工作流系统找到工作流实例,并在必要时对其进行注水,然后向其发送消息或事件。
通常,工作人员是工作流系统的奴隶。也就是说,工作流系统决定何时需要处理工作项,并将该项放在工作人员的角色队列中。当工作人员启动工作流以帮助完成任务时,工作人员是主人,而工作流系统是奴隶。这种类型的处理经常发生在建模较松散的工作流系统中,例如自然和开放组织中发生的工作流系统。与预先计划的工作流模型相比,工作人员在此时选择最合适的行动方案方面具有更大的灵活性。
工作人员也可以修改工作人员所属的正在运行的工作流,但这并非总是明智之举。由于正在运行的工作流直接反映了建模的工作流,因此修改正在运行的工作流是对工作流模型的修改。此修改可能仅在正在运行的工作流的持续时间内有效,也可能会保存为建模工作流的新版本,所有后续工作流都将使用新版本。
排队的工作项代表了组织等待处理的工作负载。检查队列可以快照组织的处理负载。可以通过工作项在队列中停留的平均时间以及个人完成工作项所需的时间来衡量组织的效率。
典型的工作流由多个业务逻辑片段组成。业务逻辑表示为业务规则。业务规则可以像布尔谓词一样简单,也可以像 if/then/action 生产规则的集合一样复杂。业务规则可以用计算机语言或伪英语表示。它们用于在工作流中表达简单的条件语句,或在专家系统(例如 OPS5)风格中表达复杂的业务逻辑。
业务规则可以在工作流生命周期的任何时间绑定到工作流。它们提供了在工作流执行时自定义工作流的能力。例如,工作人员可以将公司列入信用观察名单,或更改三月份订单超过 1,000 美元的公司的折扣率。业务规则可以由工作人员编写,也可以从业务规则存储库中检索,这些存储库表达了组织的标准业务逻辑。
业务规则可以通过多种方式触发
• 事件触发 (Event triggering)。 业务规则的作用域限定为组织。它订阅各种组织事件,并在事件发生时触发。
• 数据触发 (Data triggering)。 业务规则的作用域限定为工作流。工作流实例具有数据上下文,其中包含正在执行的工作流的状态。业务规则包含对数据上下文中变量的引用。当变量更改时,它会触发工作流中引用该变量的所有业务规则。
• 控制流触发 (Control-flow triggering)。 业务规则的作用域限定为工作流步骤。当工作流到达该步骤时,它将被触发。
对于事件或数据触发,业务规则是主规则。当它被触发时,它会激活从属工作流。对于控制流触发,工作流是主规则,在到达时调用从属业务规则。
业务规则在组织建模中起着重要作用。它们为工作流系统提供了定义组织业务逻辑片段、维护组织约束以及计算组织分配其资源的有效方式的手段。
工作流系统中的主要建模结构是流程图。它由链接组成,链接包含称为活动的步骤。控制流通过链接流动,并在遇到步骤时执行步骤。低复杂度的流程图相对容易理解。为了创建可理解的组织模型,工作流系统提供了一种将低复杂度的流程图片段组合成足够复杂的工作流以描述和执行组织目标的方法。
BPMN(业务流程建模符号)2 是流程图的建模规范,由 BPMI(业务流程建模倡议),它是 OMG(对象管理组)的一部分,进行标准化。BPMN 将工作流模型分为几个要素
• 事件 (Events) 是协调工作流执行与外部组织事件的触发器。一个常见的例子是消息接收事件。当工作流到达消息接收事件步骤时,它将等待运行的工作流实例接收到消息。
• 活动 (Activities) 代表组织执行的工作。活动可以是工作项(在 BPMN 中称为任务)或子流程。子流程是独立的工作流,具有开始事件和终止事件。子流程可以以内联或调用方式组合到工作流中。以内联方式组合时,可以分层方式查看工作流,细节程度不断提高。
• 网关 (Gateways) 控制流程的发散或收敛。分支条件和 fork/join 是示例。
• 顺序流 (Sequence) 描述了顺序链接在一起的流对象。并行性通过指定图中 fork 的网关建模。
• 消息流 (Message) 描述了在不同参与者之间流动的消息。
• 关联 (Association) 将数据与顺序流关联。
• 池 (Pools) 是主要的组织分区。池只能通过消息流链接,而不能通过顺序流链接。外部组织由池建模。
• 泳道 (Lanes) 是池的子分区。泳道通过顺序流链接。组织内的角色和部门由泳道建模。
• 数据对象 (Data object) 表示消息。
• 组 (Group) 是模型中的子集合。它仅用于文档编制,不影响流程。
• 注释 (Annotation) 是添加到模型的注释。
本文中使用的术语与 BPMN 定义之间的关系如下
• 消息 (Messages) 是 BPMN 连接对象,类型为消息流。
• 工作项 (Work items) 是 BPMN 活动之一。
• 业务规则 (Business rules) 描述了 BPMN 网关上的条件。
BPMN 的使用在随附的侧栏中进行了说明。
理想情况下,工作流由最了解所建模过程的组织参与者建模,而不是由最擅长编程的参与者建模。例如,业务分析师将对主要流程和决策点进行建模。然后,程序员将添加创建可运行工作流所需的细节,但方式应保持业务分析师的观点。工作流模型可以在两种视图中进行修改。此外,工作流执行时生成的历史数据需要在两种视图中都可查看。
工作流模型指定了组织的设计,运行时在设计上执行。运行时语言可以与建模语言相同,也可以从建模语言生成。在 MS-WWF(Microsoft Windows 工作流基础)中,语言是相同的。3 在 BPMN 标准中,它们是不同的。BPMN 是设计语言;它指定了到运行时语言 WS-BPEL(Web 服务业务流程执行语言)的映射,WS-BPEL 正在由 OASIS 标准化。4
运行时通常托管在组织服务器上,尽管它也可以托管在客户端中。工作流系统是复杂中间件框架。它们执行以下任务
启动和终止 (Initiation and termination)。 工作流系统启动和终止工作流的实例。工作流启动后,将为其分配一个标识符(关联 ID),以便可以与之通信。
执行 (Execution)。 系统解释模型,执行模型中指定的动作。
管理长时间运行的工作流 (Management of long-running workflows)。 系统控制等待工作流的注水/脱水,并管理工作流的事件处理。当事件发生时,将找到工作流实例并继续执行。这包括脱水已保存的工作流实例。
管理短事务和长事务 (Management of short and long transactions)。 工作流是手动和自动执行活动的组合,这些活动在很长一段时间内运行。工作流事务按如下方式处理
• 无事务 (No transactions)。 大多数工作流不使用事务。当异常发生时,处理继续,通常沿着异常路径进行。
• 短事务 (Short transactions)。 底层系统事务支持用于控制标记为原子性的工作流活动。
• 长事务 (Long transactions)。 补偿用于协调跨多个活动的长时运行事务。补偿的工作原理是为每个活动定义反向操作。当事务中止时,它会反向追溯其执行路径,为最初执行的每个活动执行反向活动。
管理并行工作流活动 (Management of parallel workflow activity)。 工作流中的许多活动可以并行执行。并行线程的拆分和联接在建模语言中指定,并由运行时管理。
跟踪 (Tracing)。 工作流执行被跟踪。
组织不能关闭。修改后的工作流使用版本控制引入到正在运行的组织中。版本部署后,正在创建的工作流将使用新版本。正在运行的工作流继续使用旧版本。
工作流可以在执行期间进行修改。典型的修改是更改业务规则或添加活动。更改可以针对工作流实例的持续时间,也可以保存为新版本,供后续工作流激活使用。新版本即使是从工作流运行时创建的,也需要在设计时建模工具中可查看。当建模语言和运行时语言相同时,这更容易实现。
工作流模型及其执行提供的组织信息为控制、分析和改进组织的运营提供了许多切入点。提供此功能的系统通常称为 BPM(业务流程管理)套件。5
工作流系统将要分析的数据分为来自正在执行的工作流实例的实时数据和来自已完成的工作流实例的历史数据。
实时数据用于监视和管理工作流。它可以实时洞察组织的运作方式。它允许管理人员发现瓶颈并采取行动以保持组织高效运营。它还允许工作人员监视异常情况并处理它们。此信息可以用作整个组织的数字仪表板。以下是一些衡量组织健康状况的常用指标,通过实时数据衡量
• 工作流未实现其目标 (Workflows not achieving their goals)。 如果大量工作流正在采用异常路径,则需要检查异常以确定组织的哪个部分需要关注。
• 停滞的工作流 (Stalled workflows)。 这是一个比计划时间更长的工作流。可以通过确定工作流正在等待哪个消息或事件来快速找到导致工作流停滞的条件。
• 拥塞的工作项队列 (Congested work item queues)。 这要么是由于分配给处理角色队列上的工作项的资源不足,要么是因为工作项正在等待的某些关键资源不可用而导致的。可以通过向拥塞角色添加工作人员或识别关键资源并使其可用来解决此问题。
历史数据用于关于组织随时间推移的运营报告,发现运营趋势。使用这些数据,修改工作流模型以提高组织的效率。历史数据还用于模拟修改后的工作流的运营。此模拟检查模型的正确性。模拟模型将产生额外的历史跟踪数据,可用于查看修改后的模型是否实际提高了组织效率。
BPM 套件提供了一个存储库来保存工作流片段和业务规则。建模工具使用存储库内容来创建新模型。存储库在一个或多个分类法下对工作流和业务规则进行编目。行业组织(例如 RosettaNet6 和 SCOR(供应链委员会)7)正在标准化分类法及其下的工作流。
编排 (Choreography) 是用于建模组织之间通信的术语。Web 服务形式化了这种通信。它指定了组织准备接受的消息,但没有指定消息的顺序。编排添加了此信息。WS-CDL(Web 服务编排描述语言)正在由 W3C 标准化,以描述组织之间的对等协作。8 BPMN 和 WS-BPEL 都从特定组织的视点描述了消息顺序。WS-CDL 的视点是消息交互的视点,独立于特定组织。这在 图 1 中进行了说明。
定义编排是一个活跃的领域。多个标准组织和行业团体正在定义 B2B(企业对企业)通信的工作流。供应链委员会已制定供应链运营参考模型,RosettaNet 正在定义一组 PIP(合作伙伴接口流程),这些流程定义了贸易伙伴之间的业务流程。ebXML 是一组标准,与本文中已描述的标准重叠。9
工作流系统的核心是其组织工作模型。此模型用于协调组织运营的许多部分,包括其计算机化和非计算机化部分。定义和运行模型是一项复杂的任务。以当前的工作流技术水平,这项工作需要大量的架构、设计和开发工作。这项工作永远不会完成,因为必须不断调整模型以反映其存在的不断变化的组织环境。以下是一些建模和运行时问题
• 流程图编程 (Flowchart programming)。 流程图的复杂性迅速增长。将易于理解的流程图组合成组织流程的完整模型并非易事。流程图还必须在细节层次结构中定义,以便业务分析师可以定义比工作流程序员更不详细的版本。以不同细节级别组合流程图的技术仍在研究中。
• 组织事件 (Organizational events)。 模型序列和对组织事件和消息做出反应。必要的组织事件和消息必须在创建模型时创建。
• 并行性和同步 (Parallelism and synchronization)。 组织中的许多工作并行发生。这种类型的工作难以建模,运行时也难以同步。
• 工作项子系统 (Work item subsystem)。 工作项在工作流中建模,但在与工作流异步运行的子系统中执行。这两个子系统的同步很复杂。工作流通常在一个工作流步骤中生成多个工作项。工作流需要同步这些异步执行的多个工作项的完成。这既难以建模,又导致工作流执行中难以理解的延迟。
• 异常处理 (Exception handling)。 建模工作流的“happy path”比建模多个可能的异常路径容易得多。当发生未处理的异常时,必须将其提请适当的组织工作人员注意。
工作流系统的优势在于,许多提到的难题都被显式建模,而不是隐式地埋藏在程序代码中。
由于这些复杂性,最成功的工作流产品都附带预构建的工作流,这些工作流定义了跨多个组织的通用程序。这些工作流产品旨在易于定制,以匹配特定组织的需求。
BPMN 以池(公司 A、公司 B)和泳道(采购员、采购部门、应付账款、订单处理、发货部门、应收账款)的形式描述了组织结构。控制流由实线指定,消息流由虚线指定。消息流是不同池之间通信的唯一方式。带有 + 号的框是子流程,可以展开为其他流程图,如图 2 所示。没有 + 号的框是可以发送到工作项或由计算机应用程序自动处理的任务。
BPMN 图表可以以不同的细节级别编写。高级图表可以由业务分析师编写。较低级别、更详细的图表可以由计算机程序员编写。
图 2 是图 1 中采购完成过程的扩展。此模型指定接收订单。控制流到达网关(菱形)。这是一个并行 (AND) 网关,因此两个分支都将被激活。一个分支等待接收装箱单,另一个分支等待接收发票。请注意,装箱单和发票将包含 ID(关联 ID),以便将它们路由到正在等待它们的过程实例。控制流到达另一个并行 (AND) 网关,这是一个联接,将等待两种表格都到达。然后执行三方匹配。此过程有一个计时器,因此它不会永远等待表格到达。如果计时器超时,则会调用加急流程。此过程还定义了一个异常(带有闪电符号的圆圈),如果在过程中发生异常,将调用应付账款异常处理。
PETER DE JONG 是微软的高级开发人员。他致力于创建用于构建易于编程、大规模分布式系统的技术和工具。此前,他曾在 Hewlett-Packard 和 IBM 从事分布式和并行计算、声明式编程和关系数据库技术方面的工作。他拥有麻省理工学院计算机科学和人工智能博士学位。
最初发表于 Queue vol. 4, no. 2—
在 数字图书馆 中评论本文
Mark A. Overton - IDAR 图
UML 是表示面向对象设计的实际标准。它在记录设计方面做得很好,但是它有一个严重的问题:它的图表不能传达人类需要知道的东西,这使得它们难以理解。这就是为什么大多数软件开发人员仅在被迫时才使用 UML。人们根据控制层次结构来理解组织,例如公司。当面对人员或对象的组织时,通常第一个问题是“谁在控制这一切?” 令人惊讶的是,UML 没有一个对象控制另一个对象的概念。因此,在每种类型的 UML 图表中,没有对象看起来比其邻居具有更大或更小的控制权。
Eric Bouwers, Joost Visser, Arie Van Deursen - 获得你所衡量的
软件指标 - 有用的工具还是浪费时间?对于每位珍视这些软件系统数学抽象概念的开发人员来说,都有一位开发人员认为软件指标的发明仅仅是为了让项目经理保持忙碌。软件指标可以是帮助您实现目标的非常强大的工具,但正确使用它们非常重要,因为它们也可能打击项目团队的积极性,并将开发工作引向错误的方向。
Duncan Johnston-Watt - 新的管理模式
在竞争日益激烈的全球环境中,企业面临着降低运营成本的巨大压力。与此同时,他们必须具备敏捷性,以应对动荡的市场带来的商机。
Derek Miers - 最佳实践 (BPM)
正如 BPM(业务流程管理)技术与传统的应用程序支持方法明显不同一样,BPM 开发的方法论也与传统的软件实施技术明显不同。以 CPI(持续流程改进)作为 BPM 的核心原则,驱动公司工作的模型不断发展。事实上,最近的研究表明,公司至少每季度微调一次基于 BPM 的应用程序(有时甚至高达每年八次)。关键在于,不存在“完成”的流程;需要多次迭代才能产生高效的解决方案。每个正在运行的基于 BPM 的流程都只是未来的起点。