在线工作流设计-关于通达OA2011工作流设计

什么是工作流

工作流最早起源于生产组织和办公自动化领域,它是针对平时工作中的业务流程活动而提出的一个概念,目的是根据将工作分解成定义良好的任务或角色,根据一定的原则和过程来实施这些任务并加以监控,从而达到提高效率、控制过程、提升客户服务、增强有效管理业务流程等目的。

为了更好地实现某些业务工作目标,可以利用计算机在很多个参与人之间按某种既定原则自动传递文档、信息内容或者任务。

因此,只要信息在人与人、人与系统或者系统与系统之间进行传递,就必须构建工作流。

工作流类型有哪些

工作流是在整个工作区中发生的,有些是结构化的,有些是非结构化的。当数据从一个任务转移到另一个任务时,工作流就存在了。但是,如果数据没有流动,就没有工作流。比如遛狗、去杂货店和取干洗衣物等,这都不是工作流,而是任务管理。

主要的工作流包括以下三种:

1.流程工作流(Process Workflow)

当一组任务具有可预测性和重复性时,就会发生流程工作流。也就是说,在项目开始工作流之前,您已明确数据的流转方向。比如采购申请批准工作流,一旦申请提交,每一步处理工作相对固定,工作流几乎不会有变化。

2.项目工作流(Project Workflow)

项目具有类似于流程的结构化路径,但在此过程中可能具有更大的灵活性,项目工作流只适用于一个项目。比如发布一个新版本的网站,你可以准确预测项目的任务流程,但是这个任务流程不适用于另一个网站的发布。

3.案例工作流(Case Workflow)

在案例工作流中,对于数据流转的方向是不明确的。只有收集到大量的数据时,数据流转的方向才会比较明显。比如保险索赔,一开始并不知道如何处理,只有经过一番调查,才会明确。

自动化工作流VS手动化工作流

在手动化工作流中,一个人必须时刻跟进申请,并手动发送到每个申请人处。例如,当员工填写报销单时,她必须通过电子邮件将其发送给经理以获得批准。经理批准后,她必须通过电子邮件发送到财务部门。财务部门收到后,需要付款并电子邮件告知员工付款已经完成。

在自动化工作流中,当人工完成某项任务时,她不负责将数据传递给下一个人。系统会自动管理任务流,包括通知、截止日期和提醒,最后会自动发送到财务部门进行处理。

在手动化工作流中,必须手动更新电子表格,也需要发送大量消息和电子邮件来了解项目所处的状态。而在自动化工作流中,追踪项目可以直接在系统中直接看到。因此自动化工作流可以为员工节省大量的手动操作时间和操作错误,显著提高工作效率。

重视工作流管理的公司都会使用工作流管理软件。使用力软进行工作流管理,您需要按照需求创建一个内容丰富的表单,并搭建一个清晰的流程。然后,申请人填写初始表单,软件自动将流转处理申请的数据,直到完成为止。最后,会有可视化报表显示数据的情况。

工作流自动化的好处

1.消除冗余的任务提高效率

通过力软工作流进行信息收集,可以舍弃使用Excel进行填写,并可以自动整理数据。通过力软工作流进行在线聊天,可以舍弃使用微信QQ等进行交流。最后,通过力软工作流进行数据分析,可以舍弃手动创建数据报表。三个环节都可以消除冗余的任务,并提高效率。

2.更高的可视化程度

力软强大的报表功能可以让你快速分析数据情况,清晰的跟进项目的实施情况。

3.明确各节点负责人的责任

无论采用哪种工作流类型,都可以将工作分配到每个节点负责人手里,而且每一步操作内容都可以通过流程日志进行查看,方便后期责任的确认和追踪。

这个好处理呀:审批人比如有三个,你用三个控件,分别将控件名称命为:审批人1(我是命名为部门主管审批),审批人2(我命名为部门经理审批),审批人3(总经理审批)。这三个控件都设为显示当前用户姓名

接下来在流程设计里,在各经办人那里,将可以字段分出来。比如流程流到部门主管审批时,你在这步的可写字段中,将“审批人1”列进去,其它2和3不要列入。那么进入这个步聚时,只能自动填写审批人1,即自动显示当前用户姓名。

同样,进入经理审批时,那么可写字段设为审批人2,这样第一步的审批人那一栏在第二步是无法更改的,第二步只能填写第二个审批人的姓名

第三步一样的

要实现流程的“可配置”,即相当于由用户自己“组建”流程,那么,对于程序的开发者,要做的事自然就是一个相反的过程(“拆解”流程)。考虑如何拆解流程能使用户重新组建时省力省心,实际上就是设计一个好用的、可配置的工作流的过程。

清楚了我们要做的事之后,在开始做事之前,我们还需要制定一些做事的原则(“拆解”的原则和方向),毕竟,我们的初衷,不仅仅是能把事做完,把事情做好才是最终目标。那么,什么才是一个好用的可配置的工作流呢?我们认为,好的工作流应包含下面几个特点:组建过程简单、快速,易于维护,用户无需培训、易于掌握等。

制定了上述原则后,我们现在就开始来拆解流程了,首先画一个简单的流程图作为参考。

简单流程图

大致看一下图1中的流程图,先不考虑复杂的内容,我们对一个流程最直观的判断是:流程由环节和路径组成。如果仅将流程拆分成这两个元素,对用户来说是非常好理解的。那么下面,我们就尝试使用这两个元素建立可配置的流程。先粗略地拟一下各元素对应的表单需要包含的域:

1、环节文档:环节名称、处理人员

2、路径文档:路径起点环节名称、路径终点环节名称、流转条件

上面两个文档都是配置文档,要建立一个完整的工作流系统,除配置文档之外,我们还要建立一个包含待审批的业务信息的文档(以下称为主文档),主文档要与配置文档相关联,就需要在主文档中记录一些配置文档相关的信息,这里也先粗略地拟一下这些信息:

3、主文档:当前环节、当前用户

相关基础文档建立起来之后,接下来就开始考虑将各个分散的内容连接起来形成一个完整的工作“流”。假设当前主文档处于申请人环节,那么下一个环节是A领导还是B领导呢?从我们现有的配置文档来看,两个环节文档是通过路径文档连接的,那么我们首先要找到以申请人为起点的所有相关路径,搜索结果为:路径1、路径2、路径3都符合要求。接下来就是判断当前文档符合哪一个路径流转的条件即可筛选出唯一确定的一个路径。然后,从唯一确定的路径文档中可获得下一个环节的名称,通过下一个环节的名称搜索环节文档即可获得下一个环节的处理人员。将上述处理过程放大,就可以实现一个任意庞大的流程。

流程流转过程

看上去上面的方案似乎已经完全实现了一个“可配置”的流程,实际如何呢?下面,我们拿一个复杂一点的流程来分析这种方案的优缺点:

有重复环节和路径的流程图

可以看到,“B领导审核”环节和“会计”环节出现了2次,“B领导审核”到“会计”的路径也出现了两次,假设当前环节为“A领导审核”环节,如果通过上面的处理方式,我们搜索到的符合条件的下一个环节是“B领导环节”环节,然而,“B领导环节”以后有2个可能的路径,如果仍按上述方式处理,我们本来要走的路径5可能会走到路径6而导致流程最终无法流经“总经理”环节。为了避免这种情况,我们可以有很多种选择,下面列出了其中的两种:

第1种:将两个“B领导审核”环节命名为不同名称,如其中一个环节名称改为B领导审核2。

第2种:在环节文档中增加一个位置域,标志其所处位置以区别不同位置出现的同一个环节名称,即使用位置取代环节名称作为环节文档的关键字。

采用第1种方式虽然较“笨”,但是可以不修改我们原来的程序,而且流程的组建过程也是最简单的。但是有些用户可能不会接受这种方式,因为在这样的系统架构下,组建流程的管理员需要绞尽脑汁地考虑“第二名称”怎样命名,而且这个“第二名称”不一定会获得最终用户的认可。为了避免这些麻烦,我们可以采用第二种方式。

下面我们看看环节文档中增加了位置域的效果(图4)。采用“位置”域作为关键字,在主文档、路径文档也相应增加当前位置域即可以唯一确定流程的走向。

增加环节的位置信息

在环节文档中增加位置域的方法解决了环节名称重复的问题,但进一步看,我们仍需要为相同环节名称不同位置的两个环节建立两个环节文档,站在系统管理角度来说,这也是一种很不好的方式,因为调整这种重复环节文档中的任何信息(如:调整环节包含的人员)的时候都需要修改2个或者更多的文档(很可能改了一个忘了一个)。因此,我们有必要将环节名称的其他信息和位置信息再拆分,拆分后各文档包含的域有:

角色文档(职位文档):角色名称、处理人员

环节文档:角色名称、位置

同时,为了配合这一改动,我们还需要将路径文档、主文档中当前的环节信息拆分成当前角色和位置:

路径文档:路径起点的位置、路径终点的位置

主文档:当前角色名称、当前位置、当前用户

解决了同一流程中重复环节的问题后,我们将流程继续扩展,接下来还将遇到不同流程使用同一环节,不同部门使用同一流程等问题。经过同样的分析过程,我们仍将面临为各种配置文档添加关键字域以区别不同情况或再次拆分成不同配置文档的情况。就像上面提到过的一样,选择添加域或者拆分各有有缺点,添加域可以维持程序的易用性,而拆分成不同文档可以减少系统中的重复配置,提高配置文档的可重用性和可维护性。易用性和可重用性这两个特性在大多数时候是一对矛盾体,如何取舍就全靠我们的系统设计人员把握了。我们这里采用的是以易用性为主,可重用性为辅的策略。图5显示了我们这种策略下的一种数据结构。

可配置的工作流的数据结构

刚才我们都是将流程不断扩大来细化我们的拆分方案,现在,我们将从另一个同样重要方向来继续这一过程,即流程环节的增、删、改。上面我们也曾提到过流程环节的“修改”(修改承办人员),一般情况下修改环节都不是问题,难点的在于增加和删除环节。下面我们尝试在“A领导审核”环节和“B领导审核”之间增加一个“C领导审核”,看看我们的系统是否需要做出修改,见下图:

增加环节

增加环节时,我们需要删除路径4文档(起点位置为2,终点位置为3),增加“C领导审核”环节文档和路径8文档(起点位置为2,终点位置为8)、路径9文档(起点位置为8,终点位置为3)。假如当前环节为“A领导审核”,程序流转时仍将使用主文档中保存的当前位置(位置2)搜索路径文档,此时结果可以从路径4文档变成路径8文档,可见这种设计是可以适应增加环节的。同样,这个设计也可以适应删除环节的情况。

注意,环节增删改时还有一种特殊情况,即删改当前环节。这种情况下不仅仅要修改流程配置文档,主文档中的相关内容也要进行更新,如果没有“外力”,主文档包含的当前处理人(这个还涉及了主文档的读写权限)和当前位置是不会自动发生变化的,因此,需要其他手段配合才能实现一个完美的“可配置”工作流。

到目前为止,一个简单的可配置的工作流就算完成了(跟关系式数据库建模的过程非常相似)。经过这一个过程,才发现其实IBM在Lotus WorkFlow中建立的工作流引擎(数据结构)在技术上已经是一种比较完美的方案了。我们绕来绕去自以为会发现新大陆,到了最后还是回到了前人走过的路上(对比Lotus WorkFlow,主要的不同之处是我们这里没有把人员和角色分拆,原因是不想再配置一次中已存在的用户)。不管怎么样,从这个简单的可配置流程设计的过程中,我们还是获益匪浅,也深刻认识到一个再完美的工作流引擎也不可能成为普世真理,因为工作流的易用性和适应能力常常是矛盾的,不同的用户会提出不同的要求。因此,技术人员不必执着于技术不可自拔。