CN1826610A - 包括带协作过程引擎的特设型工作流结构化处理的面向终端用户的工作流方法 - Google Patents

Abstract

在结构化的工作流系统内，可配置的工作流引擎提供按定义的方式执行和调度工作项目的机制。终端用户使用其判断力并定义其自己的“本地”过程和“本地”规则，用于处理工作项目，或偏离预定过程。可配置的工作流引擎可以安装在服务器上来组织工作流和商务过程，这里终端用户能够通过设置规则和定义工作流作为本地工作流结构的部分来定义所接受的工作项目的处理步骤。通过定义这些规则和工作流，能够自动进行将来接受的工作项目的处理步骤。当管理员将工作流引擎从当前阶段移至下一个阶段时，工作流引擎通过允许管理员顺延工作项目来处理未完成的项目(或可以自动进行)。在顺延决定里面可以包括终端用户的协商内容。把顺延的工作项目作为并行活动添加到下一个阶段。工作流引擎处理在各任务之间施加和执行控制流的相关性，从而提供从完全非结构化的工作至半结构化或完全结构化的工作的平滑过渡。当工作流引擎遇到语义相关的工作项目/任务时，过程引擎就假设这些工作项目/任务属于相同的过程实例。

Description

包括带协作过程引擎的特设型工作流结构化处理的 面向终端用户的工作流方法

相关申请的交叉参考

本申请请求申请号为No.60/469,051，标题为“包括带协作过程引擎的特设型工作流结构化处理的面向终端用户的工作流方法”，申请日为2003年3月7日的同时待审的美国专利申请的优先权，其内容通过引用而并入此处，用于各种目的。

技术背景

当人类和/或计算机应用一起完成共同的目标或兼容目标，就会发生协作。在过去的二十多年里，许多机构和个人已经认为分布团队的电子远程协作是一种实现更高生产力和提高其工作产品质量的途径。在电子通信、协同和内容共享领域内已引进了各种协作技术来提供解决方案。但是，能完全实现电子协作的综合性的解决方案仍是一个很难实现的目标。

CSCW(计算机支持的协同工作)的研究项目为开发软件系统以支持异步协作进行了早期的努力。而且这种研究所产生了渗入市场的产品，如Lotus Notes，除了对现有的电子邮件和文件管理方案的少许改进，这些早期的群件产品没有带来更多的东西。在1990年代后期，在早期的用于异步和同步协作的工具里发现的基本思想被网页浏览器所采用，通过此途径，这些思想对许多人的工作习惯产生了影响。

如今，在软件业的许多产品领域内引进了用于支持团队协作的技术和工具。新的基于Web的群件系统，如Groove和NetMeeting，通过提供联合活动工具(如音频通信、即时消息和内容共享工具)扩展了基本的网页浏览器的能力。传统的群件供应商提供支持更多专门协作活动如电子远程存在和会议的软件产品(如Lotus Sametime和QuickPlace)。嵌入到EAI平台(如Vitria、TIBCO、BEA)和ERP系统(如SAP)内的独立的工作流系统(如Staffware)和工作流引擎已经支持规定的协作活动的有效协同，并开始引进灵活的工作流以支持重复的协作活动和特设型/可选型的协作活动的组合。企业范围的内容管理服务器(如Documentum、Vignette、OpenMarket、BroadVision、FileNET)的供应商正引进包括用于电子协作的基本工具的新的产品。最终，用于协作设计、学习和产品数据管理的特定领域的工具正稳步地获得新的用户并进入新的市场。

用于支持协作的产品的前景和技术的数量正不断扩展，协作技术正不断改进。但是，当前的协作工具的状况是支离破碎的，并且目前的网络基础设施无法有效地支持一些协作工具，如用于屏幕和应用共享的基本工具。协作工具状况的支离破碎是由各种原因造成的，如这些技术本身都不能提供完整的协作解决方案。不同的技术和产品提供不同的能力和工具。而且，由于所提供的工具大多数是通用的，可能有必要开发针对特定应用的工具和用户接口，如情报收集。

因此，当前技术可支持的可伸缩性以及分布的电子团队的规模显著不同。特别是，许多支持联合活动的群件工具只适用于小型的组(如小于十人的团队)。另一方面，能很好伸缩的技术，如用于内容和工作流管理的系统，又缺少基本的群件工具。

生产工作流系统是众所周知的。在一些工作流系统中，工作流被结构化成实例，在大型的结构化工作流系统中，每天可能要处理成千上万的工作流实例。也可以使用非结构化的方法来完成工作流。非结构化的方法包括即时交互，如用电子邮件、聊天、电话等进行的交互。前者能很好地协调大型的组，而后者能很好地协调非正式的协作者小组。

结构化的工作流具有可跟踪和可测试的优点。可跟踪的结构化的工作流，其中，分析员可在事后确定过程是如何进行的，并可以识别其他性能数据和所进行工作的基础数据。而另一方面，非结构化的工作流没有这些优点，作分析时可能需要人工查阅电子邮件、备注等，并且也不可能通过按可检索的表单存储的非正式的交互和通信来通知。

非结构化的工作流有它的优势，因协作者不受管理员所设计的结构限制。当然，这也可能是个缺点，因管理团队更喜欢用专门知识和时间来设计对手头工程进行优化的工作流。在某些情况下，在结构化工作流内的协作者可能使用非正式的渠道，如手动路由、电子邮件等，来绕开结构化的工作流，但是这样该结构的用处也就丧失了。

发明内容

在结构化工作流系统内，可配置的工作流引擎提供用于按定义的方式执行和调度工作项目的机制。终端用户使用其判断力来定义其自己的“本地”过程和“本地”规则，用于处理工作项目，或偏离预定过程。可配置的工作流引擎可以安装在服务器上来组织工作流和商务过程，这样，终端用户能够通过设置规则和定义工作流作为本地工作流的一部分来对接受的工作项目定义处理步骤。通过定义这些规则和工作流，可自动进行将来接受的工作项目处理步骤。

通过本文所描述的改进的工作流引擎，可识别在过程中某个阶段未完成的步骤，并可更智能地对其进行处理。当管理员指导工作流引擎从当前阶段移至下一个阶段时，工作流引擎通过允许管理员顺延(carry over)工作项目来处理未完成的项目(或可以自动进行)。在顺延决定里面可以包括终端用户的协商内容。把顺延工作项目作为并行活动添加到下一个阶段。

工作流引擎处理在各任务之间施加和执行控制流相关性，从而提供从完全非结构化的工作至半结构化或完全结构化工作的平滑过渡。当工作流引擎遇到语义相关的工作项目/任务时，过程引擎就假设这些工作项目/任务属于相同的过程实例。

参考下面的说明书内容和附图可以进一步理解在此公开的本发明的特性和优势。

附图说明

所包括的附图描述了本发明的各方面。

图1示出根据本发明实施例的可配置的工作流系统的例子。

图2示出了工作流系统的另一种可能的布置或视图。

图3示出了所支持的作为门户应用的工作流元件。

图4示出了可配置的工作流的各方面；图4A示出了用于文件查阅过程的标准工作流；图4B示出了对有两个用户的协作室的任务分配；图4C示出了被终端用户修改的过程。

图5示出了用于在协作室创建任务的用户界面的修改版本。

图6示出了可用于安排协作任务的用户界面的例子。

图7示出了使终端用户可远程(on the fly)组织任务的用户界面。

图8示出了阶段改变过程；图8A示出了带完成的和打开的工作项目的分层过程；图8B示出了在有项目顺延的情况下随阶段改变的工作项目的状态。

具体实施方式

在结构化的工作流系统中，通过一组过程来定义工程，每个过程可以有多个步骤、任务、触发器和/或动作(工作项目)。工作流引擎提供用于按定义的方式来执行和调度工作项目的机制。

一些群件应用程序允许各用户联合定义工程的任务，这样可或多或少地仅存储任务信息并确认这些任务已分配给了任务所有人，无需可实际控制这些任务的执行顺序或其他的控制流相关性处理。例如，大多数群件应用程序不能处理这样的工作流，如：“仅在X值大于Y值时，在任务A之后执行任务B。在其他所有情况下，在任务A之后立即执行任务C。”

为了满足此需求，工作流引擎处理在各任务之间施加和执行控制流的相关性，从而提供从完全非结构化的工作至半结构化或完全结构化的工作的平滑过渡。当工作流引擎遇到语义相关的工作项目/任务时，过程引擎就假设这些工作项目/任务属于相同过程实例。当没有明确陈述控制流的相关性时，过程引擎假设所有这些都表示并行的任务。当终端用户定义了这些任务的部分或全部的顺序时，通过明确反映这些控制流的相关性来产生新的过程定义的版本。

在现实生活场景中，需要适应不可预见的活动或频繁执行的顺序变化，同时又不削弱结构化的工作流系统的优点。终端用户期望能处理这些变化。他们常常认识到若不与同事协商或执行一些其他的步骤，他们就无法执行其工作(项目)。由于终端用户使用其判断力定义其自己的“本地”过程和“本地”规则，用于处理工作项目，或偏离预定过程，因此这里所描述的工作流系统能适应这种情况。

在一个实施中，提供一种可配置的工作流引擎。可配置的工作流引擎可以安装在服务器上来组织工作流和商务过程，其中，终端用户能够通过设置规则和定义工作流作为本地工作流的一部分来定义所接受的工作项目的处理步骤。通过定义这些规则和工作流，可自动进行将来接受的工作项目的处理步骤。用于本地工作流结构的输入可以是源于多个所支持的工作列表服务器系统的任一系统的工作项目。除了定义和实例化过程，在过程的执行的同时，过程参与者可修改过程定义。过程修改的例子包括插入/修改/删除活动，绕开过程步骤，引进其他/额外的未在全局工作流中考虑的过程参与者的交互(通过路由等)。

图1示出了可配置的工作流系统100的一个例子。如图所示，用户通过工作流客户端104与工作流服务器102进行交互。如在其他图中所示，不同数量的工作流客户端是可能的。在与工作流服务器102的交互中，用户可以查阅任务、改变任务的状态(从悬挂(pending)至完成、取消、转移、废弃等)及其他。任务、状态信息及其他在工作流过程需要的或使用的数据被存储在存储区106内。标准的工作流被存储在存储区108内，通常由管理系统110提供，但也可以由外部工作流系统124提供。

通过使用这些组件，用户可按结构化的模式执行任务，并用工作流系统100来跟踪过程。当用户期望或需要本地工作流来处理终端用户指定的流时，该用户也可以使用工作流客户端104来输入本地工作流，可由工作流服务器102根据各用户将其存储到存储区120，尽管工作流服务器102(如通过其内的过程引擎103)也可以向其他受影响的用户传送本地工作项目。为了向用户提供一些用于开始的结构，可以把由管理系统110存储在存储区122内的模板连接至工作流服务器102。

在一些实施例中，图1所示的存储区域并不是独立的，仅是公共存储区域中的不同分配区域，如数据库或其他数据或文件存储段。其他的变化和组织也是可以的。例如，工作流系统可以和门户服务器集成。

图2示出了系统的另一种可能的布置或视图。如图所示，用户与一个或多个工作流客户端进行交互，如通用工作列表(“UWI”)，其在与本申请同时提交的、代理卷号17900-003610US的美国专利申请中详细描述，其内容通过引用并入此处，用于各种目的。工作流客户端与工作流服务器的Java工作流服务API层交互，API层与核心层交互，核心层又与工作流对象、数据和其他所示的结构交互。

图3示出了被支持作为门户应用的工作流组件。

工作流引擎可以包括模板产生器，当终端用户修改过程定义以适应本地条件时，用来创建过程定义的新的版本。在创建新的模板版本之后，过程实例的运行时信息被合并到新的过程定义。因此，过程实例中的下一个活动已经附着到过程定义的新版本。

在许多工作流中，过程是按阶段来组织的，其中，期望在某个阶段内的每个工作项目在该阶段结束和下一个阶段开始之前完成。一些传统的工作流系统强制要求，只有当前阶段内所有的工作项目完成之后才能开始后面的阶段，而其他的系统允许阶段的改变，其中，在当前阶段内的打开的项目被标为完成或废弃，然后移至下一个阶段。这两种方法都很受限，因为它们既不够灵活，又可能丧失必要的后续活动。

特设型(ad hoc)的工作流引擎可以包括与其他应用的无缝集成，这样用户可以使用其他工具来创建特设型的工作流。特设型的工作流可包括简单的规则，如用于每步的授权、替换、增加、调度的规则，以及更复杂的操作，如并行化、替换的使用、条件操作等。同时，用户可以自由地制作其认为对本地操作必要的非正式的工作流，系统管理员可以提供模板来在一定程度上使用户的工作流结构化。因此，用户可根据要求步骤的概要从多个模板中选择。工作流可包括要采取的步骤、要制作的通知以及其他工作项目。可以在诸如SAP的NetWeaver平台的平台上实现特设型的引擎，以最有效地使用资源。

利用这里所描述的改进的工作流引擎，可识别过程的某个阶段中未完成的步骤，并更智能地对其进行处理。当管理员把工作流引擎从当前阶段移至下一个阶段时，工作流引擎通过允许管理员顺延工作项目来处理未完成的项目(或可以自动进行)。在顺延决定里面可以包括终端用户的协商内容。被顺延的工作项目可作为并行活动添加到下一个阶段。

如这里所描述的，一个工作流引擎是在用Java开发的，并在SAP的web应用服务器WebAS 6.20和6.30上运行。其包括容易配置的审批过程，用于在知识管理应用(KM)内的文件审批和在用户管理引擎(UME)内的用户自我注册。在特定的实施里，工作流引擎激活门户中的通用工作列表(UWL)。

本发明的各方面允许按结构化的方式处理特设型的过程。在用户之间的每个交互都有某种形式的与其相关联的隐式的或显式的过程。例如，打电话开始时说“你好”，结束时说“再见”，电子邮件有所定义的协议和格式，但这是非结构化的通信。

一种灵活的支持许多这类过程的引擎将会使用户受益。要成功管理特设型的过程，就不得不脱离与传统的工作流相关的许多原则。例如，传统上工作流以管理员为中心，但通常由终端用户驱动特设型的过程。因此，管理员定义过程，终端用户是严格的工作流过程的参与者。这不是依赖有效处理与用户交互相关的高度可变过程的途径。

特设型过程管理允许用户定义工作流过程，其中用户既可以是管理员，也可以是参与者，从而来启动过程、改变过程、完成步骤并跟踪其启动或参与的过程的状态。这里所描述的特设型过程管理系统的实施例可以提供服务，能够把参与者动作和步骤连接起来。补充的传统的结构化的机制可使用户增加特设型子过程以及过程内的特设型子过程。

特设型工作流和使用结构化方法的协作

假设用户Dirk、Christian、Matthias、Cyrille和Tim都是负责撰写白皮书的团队的成员。传统上，由于不存在用于编辑的过程或中央机制，这将要求发送大量的电子邮件，并对这些电子邮件进行连续的状态检查。这里所描述的系统可以允许用户执行若干不同的任务以协同工作并有效地交流正在进行的工作。特设型过程管理引擎，如本文所描述的，可使用户围绕其正在执行的工作来组织用户工作过程。

图4示出了可配置的工作流的各方面。在图4A的例子中，作为管理员的用户“Cyrille”产生工作流，并提供其作为标准的工作流用于文件查阅过程。用户“Cyrille”作为管理员设置过程，其中，Christian先查阅文件，然后Dirk，然后Tim，然后Matthias。作为管理员，Cyrille能够改变次序，如箭头302、304所示。如图4B所示，Cyrille可将查阅分配到协作室310，该协作室是一种组织结构，其中，任务不是分配给单个的人，而是由一个或多个与该协作室相关的人来完成。如图4B所示，一些用户可在室外，一些用户可在室内。如图4C所示，终端用户(Dirk或其他授权的用户)可以用特设型工作流来改变过程流程，该特设型工作流由用户启动，但仍由结构化的工作流系统来处理。

这里描述的工作流引擎在工作流和群件之间的鸿沟上架起了桥梁，这样终端用户就能以集成的方式在其上操作。知识管理(KM)系统通常表示这样的工作，这些工作通常是被分配了这些任务的个人所进行的手工处理步骤。而工作流项目通常由自动的过程或由个人按不同的方式来处理，定义未来的工作，分配给所识别的个人、多个个人构成的组，或分配后决定的角色，如在运行时。工作流项目通常嵌入到控制流中。

工作项目可表示手工的步骤(类似于知识管理任务)或计算机化的步骤，这里，假定工作项目所有人从应用程序屏幕输入数据并点击应用程序按钮。工作流工作项目表示由工作流系统分配给一个用户或多个用户的一件工作。工作项目明确属于工作流实例(实例化的工作流定义)，并保持对工作定义的参照。终端用户通常可通过如UWL的设备访问工作项目，UWL允许搜索、过滤并操纵操作，如前转、拒绝、执行、重新提交等。

在这里所描述的一些工作流引擎内，KM任务和工作流工作项目从用户的观点来集成。在图1所示的模型中，KM任务可存储在KM仓储框架(RF)内，而工作流工作项目和工作流活动直接存储在数据库内。由于性能的原因，数据库优先用于工作流工作项目数据。例如，终端用户从UWL发出的查询必须要满足高性能要求，而RF是不能轻易满足此要求的。另一方面，通过使用RF作为存储区，可以轻松地使用许多KM基础服务，如附件服务、预定服务、版本服务、搜索引擎等。

为了保持KM任务和工作项目的一致性，可以使用相互注册回调。每当在工作流之外开始KM任务，就创建工作项目。每当在工作流之外定义没有立刻开始的KM任务，则不创建工作项目。但是，当该任务放入工作流模板时，则参考该KM任务创建工作流活动。反过来，当工作流引擎执行要求创建还未与KM任务相关的工作项目的活动时，则创建KM任务。

通过保持KM任务和工作流数据一致并通过RF提供商适配器来展示工作项目，可以使用如搜索引擎的门户工具使终端用户方便地查询过程数据。通常，对于传统的搜索引擎，过程数据不能修改。

图5示出了用于在协作室创建任务的用户界面的修改版本。注意“Smart Collaboration”按钮。使用该按钮，用户能够把已经输入的任务安排到结构化过程中。图6示出了能用于安排此类任务的用户界面的例子。通过点击“Save”按钮，创建工作流模板。所有已经输入的KM任务被当作工作流活动来处理。通过点击“Start Process”按钮，所产生的工作流模板被实例化，并创建工作流实例。在为每个KM任务执行工作流实例期间，创建相应的工作项目。通过此方法，实现KM任务和工作流工作项目的集成。

图7示出了用户界面，这里在“Team Tasks”下面有两个新的分类：“My Processes”，“All Proceses”。这两个实体列出已经通过点击“SmartCollaboration”按钮而组成的过程。后一个分类可用于所有的室内参与者。这有效地使终端用户可远程结构化任务。

特设型工作处理的变更

传统的工作流系统允许执行由擅长开发过程的过程管理员定义的过程。通常，这些过程是相当详细、优化和有效的。其目的是实现商务战略，并加强过程的一致执行。在配置之前，通常对这些生产工作流过程作充分的测试。

终端用户通常没有任务定义过程的意图，公司内的其他员工必须遵守这些定义的过程。终端用户并没有花太多的时间(或根本没花一点时间)来测试其可能定义的过程。如果他们在其过程中遇到问题，他们想远程地解决这些问题，如在运行的时候。他们可能想与其他人共享其过程，并邀请其他人作为工作流参与者参与其个人的过程。

如果工作项目源自传统的工作流系统，这些系统通常对偏离工作项目的标准执行方式不会提供任何支持。

但是，在许多情况下接收到此类工作项目的终端用户事先不知道如何执行该工作项目。通常，工作项目的执行取决于其判断力。在接受或拒绝请求之前，他们可能想对同事进行检查，他们也许想首先从同事处得到对于由工作项目表示的子任务的批准，或他们也许想设置其自己的规则用于处理所接受的工作项目。总之，终端用户将从支持这些情况的工具中受益，如从预定的处理路径的偏离或系统的“学习能力”，以便有效地应付类似的将来可能发生的情况。

通用工作列表(UWL)可作为终端用户的主进入点。终端用户能够从UWL定义其私有的过程。可替换的终端用户进入点可以是门户，如SAP的Rooms门户系统。如果用户是某个室的成员，他们能够从该室的用户界面来定义过程。作为默认，这些过程可以只能在此房间内可视。

工作流引擎可以提供API用于创建、维护以及部属工作流模板。可以从各种工具调用该API。例如，应用程序可以提供向导，该向导允许定义最终调用工作流API的过程。可以使用图形编辑器来按图形方式来构造工作流定义。

工作流引擎在其执行的同时可支持工作流模板的改变。终端用户能够增加步骤、改变步骤的顺序以及修改工作流过程内的步骤。每次改变工作流定义，就会创建一个工作流定义的新版本。相应的工作流实例的下一个步骤已经附着到此更新的工作流过程定义。

除了手动执行工作项目，用户可以设置工作项目自动处理的规则。这些规则能够引用多种数据源，如工作项目属性(例如，创建日期、工作项目类型、工作项目的创建人等)、相关的商务对象及其属性(例如，文档、文档的长度、购买定单、购买定单的数量等)以及所属工作流实例的环境(该过程的上一个步骤、该过程的到期日等)。

废弃活动/工作项目的处理

为了简明，设计用户交互以支持按阶段组织的过程。各阶段按顺序处理。可以创建新的阶段，也可以删除已经输入的阶段。把任务分配给阶段。通过把任务分配给阶段，定义了执行任务的顺序。如果多项任务分配给一个阶段，此阶段内的所有任务将由工作流引擎并行执行。通常，分层组织过程，即过程通常包括活动，活动本身也能是过程。过程中最高层的活动能被当作该整个过程的阶段。如果要求严格遵守该层次，则只有当前面的阶段完成后才可开始下一个阶段。

可以为每个阶段定义特性，即在什么情况下执行和/或终止阶段。处理其他的各种优点，这允许在过程中定义替换的分支或加快过程的执行。在此分支有用的时候，通常可能要求在延迟阶段的关闭以确保该阶段内的所有项目已完成或转移并可能遗漏项目之间进行折衷。

有这样一些情况，尽管当前的阶段还未完成，但是开始下一个阶段的处理是安全的(或由于时间限制而要求的)。在这些情况下，当前阶段的未完成的活动将被改成“废弃”。一段时间之后，不会再有人记起这些废弃的活动。由于不能得到预期的结果，这对整个过程的成功会有不利的影响。

使用这里所描述的工作流系统和智能协作，能提供一种处理废弃活动或工作项目的确定方法。不是自动地将其状态改变成“废弃”，而是将这些活动移至后续阶段或任何其他阶段。想开始下一个阶段的终端用户能够进入每个废弃活动的用户对话，该对话显示该活动将会发生什么。将未完成的活动设置成“废弃”是一种选择。其他的选择是将它们(或它们的一部分)分配给过程的其他阶段。在此情况下，应由用户来定义这些活动的位置。

下面的两个附图说明了这一点。图8A示出了分层的过程，其中一些活动(活动1.1和活动1.2.1)已经完成。阶段1的一些其他活动(活动1.2.2和活动1.3)仍然处于打开状态。如果过程所有人决定开始阶段2的处理，她必须决定对于这些打开的活动应将发生什么。图8B说明了这一点。过程所有人决定将活动1.2.1移至阶段2，并因此也将活动1.2移至阶段2。而且，她决定将活动1.3设置成废弃。

现在已经说明新的工作流系统。工作流引擎的核心可实现成状态引擎(state engine)。可以提供一种瞬时步骤处理器用于存储器内工作流的执行。可以提供一种基本的规则引擎用于评估规则。由工作列表管理器来创建和管理工作项目。其规模涉及整个组织机构并提供合适的协作工具的协作解决方案的特殊实施例可包括：灵活的商务过程和合作冲突解决；基于政策的团队协同；用于资源、角色、用户和环境管理的商务规则；基于政策的访问；意识准备和定制的监测；用于团队合作、协作本体、动态团队、工作场所、政策以及过程创建的决策支持；用于协作产品的供应链管理；用于联合活动和大型团队的可量测的工具；用于协作技术集成的中间件；和/或为支持特定应用领域(例如，情报收集、风险管理、产品数据管理)内的团队合作而开发的工具。

虽然本发明使用了特殊要素的组合来进行说明，应理解要素的其他组合也在本公开内容的范围之内。以上描述是说明性的，不是限制性的。对本领域的普通技术人员来说，通过阅读本公开内容，本发明的许多变更是显而易见的。因此，不应以上面的描述来定义本发明的范围，而是参照权利要求全部的范围或等同物来确定本发明的范围。

Claims (17)

1.一种结构化工作流系统，包括：

第一数据存储区，其用于结构化的工作项目，其中每个工作项目是数据对象，表示由动作人要执行的任务，其中动作人是一个或多个人、一组人以及一台机器，由商务过程产生器定义结构化的工作项目用于商务过程；

第二数据存储区，其用于本地工作项目，其中本地工作项目是响应所述商务过程的操作而输入的数据对象，并与由所述商务过程产生器定义的所述商务过程不同；

工作流引擎，其处理工作项目和本地工作项目，包括处理在至少一个工作项目和一个本地工作项目之间的链接，以便在处理本地工作项目时，服从由所述商务过程产生器对所述商务过程定义的约束。

2.如权利要求1所述的结构化工作流系统，其中，把第一套许可分配给所述动作人，所述第一套许可表示修改和/或访问第一数据存储区的要素的安全限制，其中，把第二套许可分配给所述商务过程产生器的操作员，并且其中第二套许可包括至少一个未包括在第二套许可内的许可。

3.如权利要求2所述的结构化工作流系统，其中，所述至少一个未包括在第二套许可内的许可是执行创建、修改和删除商务过程中至少一个的许可，从该商务过程定义了所述第一数据存储区内的结构化工作项目，并且其中所述第一套许可包括执行创建、修改和删除本地工作项目中至少一个的许可。

4.如权利要求1所述的结构化工作流系统，其中，所述商务过程产生器是由人操作来输入所述商务过程的计算机系统。

5.如权利要求1所述的结构化工作流系统，其中，所述商务过程产生器是自动的计算机过程。

6.如权利要求1所述的结构化工作流系统，其中，所述本地工作项目包括一个或多个与所述商务过程的偏离、用于处理工作项目的本地规则、本地过程以及对象的额外路由。

7.如权利要求1所述的结构化工作流系统，进一步包括门户服务器，其连接至工作流引擎以处理来自所述动作人的输入和到所述动作人的输出。

8.如权利要求1所述的结构化工作流系统，其中，所述动作人包括作为协作团队操作的多个终端用户，并且至少一个工作项目表示由所述协作团队的终端用户来完成的工作。

9.如权利要求1所述的结构化工作流系统，进一步包括第三数据存储区，其用于本地工作过程，所述本地工作过程包括由动作人产生的商务过程，其与由所述商务过程产生器定义的商务过程不同。

10.如权利要求9所述的结构化工作流系统，其中，所述第一数据存储区、第二数据存储区和第三数据存储区是通用数据存储设备的分配区域。

11.如权利要求1所述的结构化工作流系统，其中，第一数据存储区和第二数据存储区是通用数据存储设备的分配区域。

12.一种结构化工作流系统，其中，商务过程产生器产生把工作项目预先定义到多个阶段的商务过程，并且其中工作流引擎操纵工作项目，作为执行商务过程工作流的部分，该系统包括：

存储器，其用于存储当前阶段标识符；

输入端，其用于接收把当前阶段标识符从当前阶段改变成下一个阶段的请求；

扫描逻辑，当接收到改变当前阶段标识符的请求时，其用于确定商务过程内的工作项目是否依然是当前阶段未完成的工作项目；以及

逻辑，如果所述扫描逻辑确定当前阶段的至少一个工作项目依然是未完成的，其从所述商务过程产生器请求输入，以决定当前阶段内的未完成工作项目的进一步处理，进一步处理包括以下处理中的一个或多个：把当前阶段内的未完成工作项目标注为废弃、把当前阶段内的未完成的工作项目标注为完成、以及修改当前阶段内的未完成的工作项目使其成为下一个阶段的工作项目或不同于下一个阶段的后续阶段的工作项目。

13.如权利要求12所述的结构化工作流系统，其中，所述商务过程产生器中是由人操作来输入所述商务过程的计算机系统。

14.如权利要求12所述的结构化工作流系统，其中，所述商务过程产生器是自动的计算机过程。

15.如权利要求12所述的结构化工作流系统，进一步包括逻辑，用于在没有终端用户输入的情况下自动处理未完成的工作项目。

16.一种处理商务过程工作流中工作项目的方法，包括：

读取预定的工作流，其中，所述预定的工作流由商务过程产生器配置，并包括多个工作项目，至少其中一些工作项目通过工作项目之间的控制流相关性来连接；

执行预定的工作流；以及

如果遇到本地工作流改变，执行本地工作流改变，然后返回执行预定的工作流。

17.如权利要求16所述的方法，进一步包括：

向动作人分配第一套许可，所述第一套许可表示对修改和/或访问预定的工作流的要素以及允许创建本地工作流改变的安全约束；

从动作人接收本地工作流改变；

把至少一个本地工作流改变耦合到至少一个预定的工作流；

存储本地工作流改变；以及

遇到并执行至少一个本地工作流改变，作为至少一个预定工作流的执行的部分。

Images