第一篇:BPM系统实现采购申请流程的自动化
BPM系统中实现采购申请流程的自动化
采购申请是请求和授权组织内的一个部门购买产品和服务的一个流程。它包含了要购买的产品或服务的描述及数量,需要的到货时间、帐号以及采购部门获批用于采购产品或服务的经费数目。作为组织机构内部财务控制的一部分,会计部门负责按照一个采购申请流程,来管理所有产品和服务的采购申请。这些请求会形成文档,依次经过组织机构的各级批准,然后送给会计部门。
一、组织机构实现采购申请流程时所面临的挑战
组织机构可以创建一个采购申请流程来帮助管理所有的采购申请,但是,为了能够控制开销,并符合所在地区严格的会计政策,这一流程需要在整个机构内实施。然而,那些不经常进行产品和服务采购的请求者,几乎不知道如何采购他们需要的东西,也不清楚公司现在有哪些政策需要遵守,有哪些预算和花费限制,也缺乏对流程和会计要求的理解。另外,如果试图强制实行严格的采购申请流程或规则,不可避免将导致这些过程都被牵涉其中,但是,没有正式文档的临时性的花费,仍然是组织内的一个企业文化问题。
此外,一个手工的,使用纸质文档的流程是非常费力的:申请者需要手工打字,重新键入,记入日志,验证生效,发送到各个部门,然后保存起来。这样的流程不但效率低下,并且容易犯错,对于使用者和管理者来说都很麻烦。由于数据分散在各个系统中,要想获取相关信息,使用者要浪费不少时间,并导致缓慢的申请周期。人工通知,跟踪,和报告都会造成效率低下,也会导致采购工作周期的失去有效控制。二、一个真正全面的采购申请流程,应该具有以下特性:
●对所有类型的花费,有一个简单,统一的申请流程 ●所有人和系统都在相同的平台之上,从而实现有效合作 ●负责所有类型的供应来源和流程 ●采购申请流程要和采购系统集成起来 ●使用简单,适合不同阶段,不同场景 ●用户可以看到采购政策并采用 ●需要考虑未来采购的长期规划 ●每项采购的财务结果清晰可见
●具有可扩展性,能满足组织未来的发展需要
一个好的解决方案应该能够降低一个纷复繁杂的采购方案的复杂性,采用一种简单灵活的表现形式,并确保组织采购和授权政策的合规。这个系统应该能获取实时的数据,并让所有牵涉的人都在同一平台上实现有效合作。
三、采购申请流程自动化的好处
组织结构可以实现采购申请流程的自动化,从而大幅度的降低管理成本,更好的管理厂商支付。如果申请流程是建立在一个业务流程管理平台之上,组织机构可以很容易的将其ERP及其他核心业务系统同自动化的采购申请流程集成在一起。于是乎,组织机构可以缩短批准周期,降低管理开销,在保持合乎规定的同时,有效的控制和加速申请过程。
●采购过程流水线化,提高效率和生产力 ●系统具有可扩展行,能适应突发的采购增长 ●排除人工处理,将流程错误降低最低
●实时通知相关人员,缩短批准周期,提高KPI和SLA水平●对流程监视,调整,实现最优化 ●符合所有企业和政府的政策 ●消除人工干预,提高数据的准确程度 ●可以和现有的以及遗留应用进行集成
●根据流程的前后顺序,通知相关操作人员,确保流水化作 ●降低管理和运送费用
●确保文档的准确性,安全性和可靠性 ●用户的权限管理
景尚科技建议,构建于一个好的BPM产品之上的解决方案将会最小化管理成本,并实现流程的全部自动化。所有利益相关者都使用同一个平台,并使这个流程对每个人都可见,那么,批准时间就可以大大缩短。BPM解决方案将会有效地推进购买策略的实施,从而可以削减所采购货物和服务的成本。
这个解决方案不仅能解决当前的需要,并且能支持在政策,文档类型,用户和连接系统等各个方面的改变,如果要采用多个当前的标准,这个方案也很容易实现。
(文:成都景尚科技有限公司)
第二篇:采购申请、审批流程
规范企业采购申请流程
一、请购及其规定
1.请购的定义
请购是指某人或者某部门根据生产需要确定一种或几种物料,并按照规定的格式填写一份要求获得这些物料的单据的整个过程。
2.请购单的要素
完整的请购单应包括以下要素:
(1)请购的部门;
(2)请购物品所属项目;
(3)请购的用途;
(4)请购的物品名;
(5)请购的物品数量;
(6)请购的物品规格;
(7)请购物品的样品、图纸或技术资料等;
(8)请购的物品的需求时间;
(9)请购如有特殊需要请备注;
(10)请购单填写人;
(11)请购部门主管;
(12)请购单审核人;
(13)采购负债人审核;
(14)财务审核人;
(15)公司总经理。
3.请购单及其提报规定
(1)请购单应按照要素填写完整、清晰,由公司领导审核批准后报采购部门;(2)固定资产申购按照附表一(固定资产购置申请表)的格式进行填写提报;(3)其他材料设备及工程项目申购按照附表二(物资采购申请表.)的格式填写提报;(4)日常零星采购按照公司印制的按照附表三(物资采购审批单)的格式填写提报;(5)请购部门在提报请购单是应要求采购部签字接收人请购部门备份;(6)涉及的请购数量过多时可以附件清单的形式进行提交,为提高效率该清单的电子文档也需一并提交;
(7)遇公司生产、生活急需的物资,公司
领导不在的情况,可以电话或其他形式请示,征得同意后提报采购部门,签字确认手续后补。(8)如果是单一来源采购或指定采购厂家及品牌的产品,请购部门必须作出书面说明。(9)请购单的更改和补充应以书面形式由公司领导签字后报采购部。
4.公司物资请购单的提报部门
(1)公司经营生产的物资、劳务、固定资产、工程及其他项目由生产部门提报;(2)公司生活及办公的物资、固定资产、服务或其他生活及办公项目由办公室提报;
(3)公司各部门专用的物资由各部门自行提报。
二、请购单的接收及分发规定
1、请购的接收要点
(1)采购部在接收请购单时应检查请购单的填写是否按照规定填写完整、清晰,检查请购单是否经过公司领导审批;
(2)接收请购单时应遵循无计划不采购,名称规格等不完整清晰不采购,图纸及技术资料不全不采购,库存已超储积压的物资不采购的原则;
(3)通知仓库管理人员核查请购物资是否有库存;
(4)对于不符合规定和撤销的请购物资应及时通知请购部门。
2、请购单的分发规定
(1)对于请购单采购部应按照人员分工和岗位职责进行分工处理;(2)对于紧急请购项目应优先处理;
(3)无法于请购部门需求日期办妥的应通知请购部门;
(4)重要的项目采购前应征求公司相关领导的建议。
3、采购周期的规定
(1)单次采购金额预算在1万元以下的零星采购项目或预算在1万元以下可市区采购的物资及产品的采购周期不应超过5天;
(2)单次采购金额预算在1万元以上的项目比价采购,采购周期不应超过15天
(3)单次采购金额预算在20万元以上的项目采购部自行招标采购,采购周期不应超过40天;(4)单次采购金额预算在100万元以上的项目可委托代理招标公司代理招标,采购周期不应超过60天;
(5)请购部门应按照以上(1)-(4)条中规定的时间提前提包请购单采购部如未能按时完成采购任务时应向公司领导说明原因;
(6)遇到紧急采购应汇报公司领导采取快速优先采购的策略;
三、询价及其规定
1.询价请应认真审阅请购单的品名、规格、数量、名称,了解图纸及其技术要求,遇到问题应及时的与请购部门沟通;
2.属于相同类型或属性近似的产品应整理、归类集中打包采购;
3.对于紧急请购项目应优先处理;
4.所有采购项目上必须向生产厂家或服务商直接询价,原则能不通过其代理或各种中介机构询价;
5.对于请购部门需求的物资或设备如有成本较低的替代品可以推荐采购替代品;
6.遇到重要的物资、项目或预估单次采购金额大于10万的采购情况,询价前应先向公司相关领导汇报拟邀请报价或投标单位的基本情况,按照附表四(拟报
价/招标单位名单)的格式提报公司领导批准方可询价或发放标书;
7.询价时对于相同规格和技术要求应对不同品牌进行询价;
8.除固定资产外单次采购金额在1万元以下项目可以自行采购;单次采购金额预算金额在1万元以上的所有项目都应要求至少三家上的供应商参与比价或招标采购,比价或招标项目应至少邀请四家以上单位参与;单次采购金额预算价格在20万元以上的项目应由采购部组织招标,公司相关领导参与监督;单次采购金额预算价格在100万元以上的项目由公司领导决定是否委托第三方机构代理招标;
9.比价采购或招标采购所邀请的单位均应具备一定资质和实力,具有提供或完成我公司所需物资和项目的能力;
10.比价采购或招标采购应按照附表五(材料或设备询价表)的格式或拟定完整的招标文件格式进行询价;
11.在询价时遇到特殊情况应书面报请公司领导批示。
三、比价、议价
1.对厂商的供应能力,交货时间及产品或服务质量进行确认;
2.对于合格供应商的价格水平进行市场分析,是否其他厂商的价格最低,所报价格的综合条件更加突出;
3.收到供应单位第一次报价或进行开标后应向公司领导汇报情况,设定议价目标或理想中标价格;
4.重要项目应通过一定的方法对于目标单位的实力,资质进行验证和审查,如通过进行实地考察了解供应商的各方面的实力等;
5.参考目标或理想中标价格与拟合作单位或拟中标单位进行价格及条件的进一
步谈判。
四、比价、议价结果汇总
1.比价比价、议价汇总前应汇报公司相关领导,征得同意后方可汇总;
2.比价、议价结果汇总应按照附表六(比价/招标汇总表)的格式完整列出报价、工期、付款方式及其他价格条件、列出拟选用单位及选用理由,按照一定顺序逐一审核;
3.如比价、议价结果未通过公司领导审核应进行修改或重新处理。
五、合同的签订及其规定。
1.合同
合同是当事人或当事双方之间设立、变更、终止民事关系的协议。依法成立的合同,受法律保护。广义合同指所有法律部门中确定权利、义务关系的协议。目前我们的采购工作主要涉及工矿产品买卖合同。(1)合同正文应包含的要素
1)合同名称、编号、签订时间、签订地点;
2)采购物品/项目的名称/、规格、数量/工程量、单价、总价及合同总额,清单、技术文件与确认图纸是合同不可分割的部分; 3)包装要求;
4)合同总额应含税,含运达公司的总价,特殊情况应注明;
5)付款方式; 6)工期; 7)质量保证期; 8)质量要求及规范;
9)违约责任和解决纠纷的办法; 10)双方的公司信息; 11)其他约定。(2)合同签订及其规定
1)如涉及到技术问题及公司机密的,注意保密责任; 2)拟定合同条款时一定要将各种风险降低到最低;
3)为防止合同工程量追加或追加无依据,打包采购时要求供货方提供分项报价
清单;
4)遇货物订购数量较多且价值较大或难清点的情况时务必请厂商派代表来场协助清点; 5)质保期一定要明确从什么时候开始并应尽量要求厂商延长产品质保期;
6)详细约定发票的提供时间及要求;
7)针对不同的合同约定不同的付款方式,如设备类的合同一般应分按照预付款、验收款,调试服务款、质量保证金的顺序明确付款额度、付款时间和付款条件等 8)与初次合作的单位合作时,应少付预付款或不付预付款; 9)违约责任一定要详细、具体;
10)比价/招标汇总表巡签完毕后方可进行合同的签订工作;
11)合同签定签应按照附表七(合同审查批准单)的格式对合同初稿进行巡签审查; 12)合同巡签审查通过后应由公司领导签字,加盖公司合同章方可生效;
13)签订的所有合同应及时报送财务部门。
六、付款及合同执行 1.付款规定
(1)所有已签订合同付款时应参照公司《修造船公司材料采购付款及报销流程V1.修改版》及《修造船公司资金支出审批及报销签字权限及管理制》中的相关规定执行;(2)按照进度付款的采购项目必须确保质检合格方可付款;
(3)按照贵司规定和合同约定达到付款条件的合同在付款时应填写附表八(资金支出审批单)或附表九(付款审批单),该审批单巡签完毕后提交财务部付款;
(4)财务部门在接到付款审批单后应在3天内付款,以免影响合同的执行和供货周期,遇特殊情况限延期付款的应及时的通知采购部并汇报公司领导。
2.合同执行
(1)已签订合同由采购部项目负责人负责跟进,由采购部负责人进行监督,如出现问题,采购部应及时提出建议或补救措施,并及时通知请购部门及公司领
导;
(2)已签订的合同在执行期间,应及时掌握合作单位对于合同义务和责任的履行情况,跟踪并督促其保质保量,按时履约;
(3)合同在履行期间应按照上方约定严格执行合同,遇未尽事宜应及时协商并签订补充合同。
七、报验与入库
1.报验
(1)供应单位已经履行完毕的合同,采购部应及时的通知质检部门进行验收;(2)对于不同类型的合同的标的物的验收标准参照公司质检部门的相关规定执行;(3)达到质检和报验条件的合同标的物应在第一时间报请质检部门进行质检、验收;(4)质检部门在接到采购部报验通知后应及时报验,并出具报验结果证明书,对于质检不及时延误生产部门使用或不能入库的情况质检部门应负主要责任;(5)用于公司生活和办公的物资不在公司质检部质检范围之内。
2.入库
(1)公司所有的生产材料、设备及外协加工件入库前均应通过质检部门的检验或验收;(2)合同标的物在运达公司后采购部应及时通知请购部门,由请购部门及时安排卸货与搬运;(3)质检部门未及时验收的合同标的物,仓库在收到送货清单后应将其作为暂存物资接受;(4)质检部门已经验收的产品仓库应及时的入库,并及时出具入库清单;(5)外协加工件应按照原材料入库;
(6)质检合格后的固定资产及服务按照公司财务规定不入库。
第三篇:工作流与K2 BPM的实现
背景
工作流产品众多,而它们之间又缺乏统一的标准,使得不同的产品之间很难实现协同工作。为了解决这一问题,工作流管理联盟(WFMC)于1993 年成立,并提出了工作流参考模型,制定了五个标准接口。
其中有一个接口是过程定义接口。几乎每个工作流产品都有自己的过程定义语言(也称为工作流语言),可以从四个方面(控制流、数据流、资源、操作)来研究流程,工作流模式(Work Flow Pattern)只是涉及到其中的控制流部分。控制流(control flow)描述了活动在不同结构中的执行顺序。控制流对我们有效认识、理解工作流规范具有很大帮助。工作流规范需要不断地扩展,以便满足新的需求,因此有必要对控制流进行基础的认识和分析。1.模式总述
工作流模式系统化地表述了基本的和复杂的结构。模式(pattern)是从具体形式中抽象出来的。面向对象的设计模式,规定了不依赖于具体的实现技术,同时也不依赖于所在领域的基本需求。
Carl Adam Petri基于Petri网原理提出的21个工作流模式,用于工作流过程建模和分析。这些模式,仅限于静态控制流,而不考虑资源分配、实例控制、异常处理和事务管理。
支持工作流模式
过程种类
顺序(Sequence)
基础控制过程
(Basic Control Patterns)
并行分支(Parallel Split)同步(Synchronization)排他选择(Exclusive Choice)简单合并(Simple Merge)多路选择(Multiple Choice)
高级分支和同步过程
多路合并(Multiple Merge)
(Advanced Branching and 同步合并(Synchronizing Merge)Synchronization Patterns)鉴别器(Discriminator)
M中N鉴别(N out of M)
结构化过程
(Structural Patterns)多实例过程
(Patterns Involving Multiple Instances)
任意循环(Arbitrary Cycles)隐式终止(Implicit Termination)非同步多实例(MI-without Sync)在设计期间预先确定的多实例(MI with a Priori Design Time Knowledge)
在运行期预先确定的多实例(MI with a Priori Runtime Knowledge)
无法在运行期预先确定的多实例(MI without a Priori Runtime Knowledge)
过程状态
(State-based patterns)过程取消
(Cancellation Patterns)
1.K2 Blackpearl
K2 Blackpearl 是SourceCode公司基于.NET WF构建的流程开发平台的核心产品。代码可支持生成WF代码,流程设计环境使用WPF构建,并完全嵌入到VS 2005中,与微软产品紧密结合。
K2 blackpearl 包括业务流程管理与工作流性能。可以通过建立应用来管理业务流程并使其自动化,或者集业务流程、人员、服务、信息和系统于单一的应用,从而帮助推动业务发展。
1.基础控制过程
这五个模式的共同点在于:模式所涉及流程的执行路径是在设计时即可确定的,不需运行时的信息。包括:Sequence(顺序模式)、Parallel split(并行分支模式)、Synchronization(同步模式)、Exclusive choice(排他选择)、Simple merge(简单合并模式)。顺序(Sequence)
延期选择(Deferred Choice)
交叉并行路由(Interleaved Parallel Routing)里程碑(Milestone)取消任务(Cancel Activity)取消流程(Cancel Case)
描述:
工作流中的各个活动在同一个进程中按顺序依次执行。
案例:
“用户付款”后才能进行“发送货物”。
K2实现: 平行拆分(Parallel Split)
描述:
工作流中从一个线程中的一个点拆分为在多个线程中平行执行的多个活动。这些平行的活动之间没有关联,执行没有顺序关系。
案例:
“用户付款”后激活了“发送货物”以及“通知用户”的执行。
K2实现:
同步(Synchronization)
描述: 在流程中的某个点,多个并行的子流程或者活动,合并成一个流程。流程必须等待所有的分支都执行完以后,才能激活后续活动,这就是“同步”之意。
模式3一般与模式2配合使用。
案例:
“发送货物”以及“通知用户”两个并行活动执行完毕后,激活“存档”活动。
K2实现:
每个分支维护自己的完成标记,所有Line Rules都设置成:所有分支均完成。排他选择(Exclusive Choice)
描述:当一个活动完成以后,可以有多个分支进行选择,但是只能选择其中的一个分支,即多选一。
案例:“下完订单”后,可以选择“银行卡付款”或者“邮局汇款”,只要选择一种方式即可。
K2实现 : 两个Line Rules的逻辑是互斥的。
简单合并(Single Merge)
描述:
有两个或多个可选择的分支,在某一点处合并成一个分支,但并不是同步合并(与模式2的区别)。与模式4也有点相似,都是“多选一”,但模式4是分散,而模式5 是合并。一般采用“先进先出”原则,但是后续活动只产生一次(如果后续活动执行多次产生多实例,就是模式8)。
模式5一般与模式4配合使用。
案例:
无论在何种方式的“付款”之后,进行“发送货物”。
K2实现: 每个分支维护自己的完成标记,所有Line Rules都设置成:有且仅有本分支完成。
1.高级分支与同步模式 多路选则(Multi-choice)
描述:
当一个活动完成以后,有多个分支进行选择,可以选择其中的一个或者多个分支,即“多选多”(模式4 选择是“多选一”模式)。选择的多个分支可能存在并行执行的情况。模式6可以认为是模式4的扩展。
案例
“发起会签”之后,可以多种选则会签方式,但至少要选择一种。
K2实现
3个Line Rules的逻辑是独立的。
同步合并(Synchronize Merge)
描述: 在流程中的某个聚合点,多个分支路径合并成一个路径。在聚合点,流程会等待所有的分支到来,才能激活后续的活动。这个模式可以选择分支路径,如果只选择一个分支,实现的功能类似于模式5 简单聚合模式;如果选择两个及以上的分支,实现的功能类似于模式 3 同步模式。
模式7可以认为是模式5的扩展。模式7一般与模式6配合使用。
案例:
要等待所有需要会签的活动都结束才进入“会签结束”,忽略不需要会签的活动。
K2实现
每个激活的分支都维护自己的完成标记,Line Rules都设置为:所有激活的分支均完成。多路合并(Multi-merge)
描述:
在流程中多个分支(可能是模式6 多重选择的一个或多个分支;也可能是模式2 并行中的多个分支),在合并时每个分支执行完都会激活后面的活动。与模式5 简单合并的区别在于:简单合并的分支只有一个可执行并且后续活动只激活一次;而多路合并是多个分支可执行,后续活动激活多次。有的工作流引擎不支持。
案例:
报销过程中假如分为住宿费、交通费、飞机票特殊报销,每种类型都需要进行审批。如果飞机票的审批比较严格,拖得较久,可能就需要其他的费用先审批通过进入下一环节。
K2实现:
无需添加任何的Line Rules。
鉴别器(Discriminator)
描述:
在流程中的某个聚合点,等待所有的分支(可能是并行分支,也可能是多重选l 择分支)中的第一个分支执行到达后,就立刻激活后续活动。
案例:
M个“会签”活动中只要一个会签完成就立即进入“会签结束”。
K2实现:
“会签”节点的Destination Rules 为Create M Slots,Line Rules的逻辑为at least 1 of slots。M中N鉴别模式(N out of M)
描述:
在流程中的某个聚合点,等待所有的M 个分支(可能是并行分支,也可能是多多选分支)中的前N 个分支执行到达后,就立刻激活后续活动。与模式9的区别在于模式10有N路同步的概念。
案例:
M个“会签”活动中只要N个会签完成就立即进入“会签结束”。
K2实现:
“会签”节点的Destination Rules 为Create M Slots,Line Rules的逻辑为at least N of slots。
第四篇:需求申请及采购流程
有关采购采购流程再次明确
一、需求申请发起
1、采购申请单,相关列表填写要求如下:
1.1、品名——所需物资的名称、规格型号
1.2、单位——物资标准计量单位
1.3、数量——此次采购所需数量
1.4、计划单价——此次需求申请计划单件商品单价
1.5、计划合计——此次需求申请计划花费总金额
1.6、上次采购日期——明确填写上次采买此类商品的采购日期(年、月、日)(若无可不填)
1.7、上次采购单价——明确填写上次采买此类商品的藏偶单价(若无可不填)
1.8、用途及品质要求——根据实际需要填写
2、采购申请单,其他项目填写要求如下:
2.1、申请部门——物资需求部门
2.2、申请人——制单人签字确认
2.3、时间——填写制单日期
2.4、部门经理——由部门负责人确认所需购买物资的必要性
2.5、总经理——由公司负责人确认是否同意购买商品
3、根据填写完整的采购申请单,在签批流程完成后,转采购进行采买
二、采买物资相关要求
1、采购部人员需求部门要求进行采买,采买物资需有如下环节:
1.1、货比三家——对所购买物资进行比价,在选择性价比最优商品进行采购,零星采购由采购部负责人进行审核,并转公司负责人确认
1.2、明确供应商资质——对供应商资质进行确认(零星采买可不进行此操作),一般包括:营业执照、银行开户许可、相关卫生检验证明等
1.3、确定供应商——已确定的供应商,由采购部提交货比三家及相关资质证明,由采购部负责人签字确认后,转公司负责人审批。
1.3、签订合同——我司购进原材料等物品要求签订合同,重点明确合同主要条款,包括:合同起止时间、所购物资项目品类,数量、单价、金额,明确票据种类、结算方式、运费承担、意外损失责任确认等双方权利
义务,1.4、采购有关物资,根据供应商提供的销售出库单等有有效凭据办理入库手续。
1.5、根据实际入库情况,与供应商索要相关发票,凭发票办理结算手续。
第五篇:工作流与K2 BPM的实现
1.结构化过程
这两个模式的共同点在于:模式所涉及流程的执行路径是由运行时决定的,而非设计时确定。包括:Arbitrary cycles(强制循环模式)、Implicit termination(隐式终止模式)。 11 任意循环(Arbitrary Cycles)
描述:
工作流中的一个点可以让一个或多个活动反复的执行。
案例:
“修改提交”后进入“经理审批”,但未通过,又回到“修改提交”。
K2实现:
12 隐式终止(Implicit Termination)
描述:
在一个流程中,如果没有活动可执行了那么流程就会终止。换句话说,在工作流中没有active 状态的活动了,而且也没有活动会被激活,这就是隐式终止。(前提:工作流不能处于死锁状态)。
有的工作流引擎不支持。 案例:
“主管审批”通过后进入“经理审批”,未通过则无下一个活动。 K2实现:
如果“主管审批”的输入为“不同意”,流程将终止。
一般都会采用显示终止,因为隐式终止可能会引起不被察觉的错误,例如意外的输入可能导致流程的结束。
多实例过程
“多实例”是指在流程图中,一个活动在同一时刻拥有多个可运行的、处于活动状态的实例。
13 非同步的多实例(Multiple Instances Without Synchronization)
描述:
在流程中,一个活动可以激活多个实例,也就是说可以把一个活动分发成几个控制线程。每个控制线程之间都是相互独立的,并不需要同步它们。
案例:在网上订购书籍,以书为单位,每一本都会独立产生一个购书实例,并且每个实例之间不需要同步数据。 K2实现:
IPC Event调用方式需要选择为Asynchronous。
14 在设计期间预先确定的多实例(Multiple Instances With a Priori Design Time Knowledge)
描述:
一个活动可以激活多次产生多个实例。而产生的实例的个数在流程设计时就事先知道了。一旦所有的实例都执行完成,就会激活其他活动。 案例:
有关某些特定资源的请求需要完成固定几个不同的审核流程。 K2实现
主流程结构为模式2平行拆分 + 模式3同步,IPC Event中调用方式需要选择为Synchronous。
15 在运行期预先确定的多实例(Multiple Instances With a Priori Runtime Knowledge)
描述:
一个活动可以激活多次产生多个实例。而产生的实例的个数是变化的,取决于实例的特点或者可用资源数目,但是在流程执行过程的某个时期,在这个活动的实例产生以前,要产生的实例个数是能确定的。所有的实例都运行完成后,激活后续活动。 案例:
处理一个订单,订单中有多本书,要分别检查每一本都有库存,所有的书都检查完成后才开始进入送货。 K2实现:
主要结构为模式6多路选择 + 模式7同步合并,IPC Event中调用方式需要选择为Synchronous。
16 无法在运行期预先确定的多实例(Multiple Instances With a Priori Runtime Knowledge)
描述:
在一个活动能够被多次激活的这种情况下,在指定情况下的指定活动的实例数量无论是在设计时或者运行时都不能在活动的实例被创建之前预先确定。但是,在活动被创建之前,在运行中的某个阶段,这个数量是可以预知的。一旦所有的实例都完成了,其它的活动应该被启动。这个模式和模式14的区别在于,在某些实例运行结束之后,新的实例仍能被创建。 案例:
订购100 台电脑,涉及多个供应商,但是每个供应商供应多少台电脑是不知道的,因此供应商的数量事先也不确定。但是当每次供应商送货后,就会将现在所拥有的电脑数量和所需的100 台进行比较,来决定是否要下一个供应商继续送货。 K2实现:
比较复杂,可以利用模式11任意循环实现。
基于状态的模式
这三个模式的共同点是:模式所涉及根据当前运行的流程状态来改变流程里的执行路径,包括:Deferred choice(延迟选择模式)、Interleaved parallel routing(交替平行路由模式)、Milestone(里程碑模式)。
17 延迟选择(Deferred Choice)
描述:
工作流中的一个点,有一个或多个分支已经被选择。与XOR拆分相比,并没有明确的选择,但是,选择是取决于环境的。与AND拆分相比,两者中只有一个被执行。这意味着一旦环境启动了其中的一个,另一个就被取消。要注意,选择是被延迟到两个分支中的一个真正开始执行时,也就是说,选择是可以尽可能的推后的。 案例:
在收到货物之后,可选择两种方法将其送到。选择取决于相关资源的可用性。如果资源均不可用,选择会被推迟到直到其中一个资源可用为止。 K2实现:
“监听资源状况”的Destination Rules是一个Robot帐号,只实现监听作用。
18 交替平行路由(Interleaved Parallel Routing)
描述:
一组活动以任意的顺序执行,每个活动都被执行,他们的顺序是在运行时决定的,并且在任意一个时刻都不会有两个活动在执行。 案例:
体检流程中的活动有各种常规检查和血液检查,哪个在先哪个在后都可以,但是不可能同时检查。 K2实现:
K2并无直接实现方法,需要编码,变通解决。
19 里程碑(Milestone)
描述:
一个活动能否执行取决于一个指定的状态。也就是说,只有在到达一个特定的未过期的里程碑时,活动才被执行。 案例:
客户在确定交付的前两天是可以取消订单的。 K2实现:
时间上的一些状态可以在Start Rule 和Activity Escalations中实现,其他的复杂逻辑需要编程实现。
取消模式
这两个模式的共同点在于:模式所涉及的流程在运行时disables一个活动或者整个流程,包括:Cancel activity(活动取消模式)、Cancel case(实例取消模式)。 20 取消活动(Cancel Activity)
描述:
一个可执行的活动被强制失效了,也就是说,一个正在等待执行的活动所在线程被移除了。 案例:
网上购书时已经下了订单,“支付货款”活动激活,这时如果取消了订单,那么相应的“支付货款”活动也要取消。 K2实现:
利用K2 的API实现。
21 取消实例(Cancel Case) 描述:
如果一个活动产生了多实例,那么仅仅撤消这个活动是不行的,要将这个活动的所有后代(实例)都移除才行。 案例:
网上购书时如果取消了购书的活动,所有因订单激活的购书流程实例都要取消。 K2实现:
利用K2 的API实现。
其他扩展模式
21个工作流模式并不能囊括所有情况,还有其他的一些扩展模式,例如:流程启动、回退、转发、通知、代理、催办、回收、任务批处理、任务分组处理、流程合并、子流程等等。