工作流实施策略
这两年工作流应用越发火爆了，大多管理信息系统都或多或少涉及到流程应用。一方面客户对流程认识和需求在提高，另一方面开发商也希望通过流程技术为客户提供更灵活的应
用支持。
先简单说说什么是工作流：
工作流（Workflow）就是工作流程的计算模型，其表示的是：对流程中的任务（活动），以什么样的逻辑或者规则串接起来，并以什么样的模型进行表示和计算。
上面的概念解释比较抽象化，由于本篇不是定位于讲解工作流概念的文章，所以我们暂且不深入的探讨工作流的一些基础知识和理念。简单的举例加以说明：例如，在日常办公中，当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，而非手工传递。这就可以称之为工作流。
本篇主要探讨工作流实施过程中的一些需要注意的问题。对于工作流的实施，其实就是基于一个工作流引擎或平台，通过扩展开发实施，满足客户对流程信息化应用的需求。从一
个开发商接手一个流程应用开发，到其给客户实施成功，需要面对一些比较棘手的决策性问题，而这就是本篇所要探讨的主题。通过对一些工作流实施问题的讲解和方案探讨，来辅助开发商进行一些基本决策。
第一个问题：为什么就一定需要使用工作流技术？首先简单阐述一下为什么一定需要使用工作流技术。
我想最直接的原因应该是来自于客户的管理和运营信息化的需求推动：在客户的运行管理体系中，在不同的职能领域，是由各种各样的处理流程交互协助的，而这些处理流程都是由一些
处理活动和任务组成的。传统的信息系统仅能满足客户对数据处理信息化的最基本要求，却很难满足客户对“协助处理信息化”的要求，这就是客户为什么需要工作流技术的基本原因。而从另一个角度来说，开发商也希望通过流程技术的应用，一方面提高流程项目的实施进度，另一方面则希望能够为客户带来更高体验度的实施效果。
这个问题不过多的解释，因为目前工作流的应用已经是越来越广泛。
第二问题：工作流技术就真的可以提供工作流项目实施进度吗？
这几年在工作流培训过程中，碰到很多技术人员问我这个问题。在他们看来：首先他们对工作流系统是存在一些困惑的，特别是从来没有接触过工作流系统的开发人员；其次他们
搞不清楚工作流技术是否真的能提高项目开发进度。单纯说使用工作流技术提高项目实施效率，这不一定就有效。这几年的实施的流程项目很多，但只有个别几个，因为客
户对流程相关的应用应用的需求不是很复杂（如表单、权限等），我们流程产品本身辅助的表单系统也基本满足客户的需求，在这样的情况下实施的流程应用相对是快很多的。
但绝大多数实施的流程项目，单纯从按照客户的需求来完成流程运行和实施，有没有工作流引擎支持，其实并没有提高的太多。我记得2002 年下半年的时候，给国家发改委实施
了一个“提案信访”的流程，流程本身不是很复杂，如右图所示。当时我们已经有一个较为完善工作流系统了，但这个流程项目依然实施了半年多。主要原因是耗费了大量的开发精力在客户操作习惯、交互界面以及组织管理中的一些非常规权限方面。
可以说，一个单纯的工作流引擎，本身似乎并不能提高多少的流程项目实施效率。但是我们依然推崇使用工作流技术来解决流程性问题。这是因为工作流技术本身是基于“定义模型、解析模型、运行模型”原则，这就是说“流程是可被描述的”，一般我们会采用xml 来描述流程定义。基于这个模型“定义——解析——运行”原则，则会带来两个最直接的益处：（1）基于可被描述的模型，也就意味着流程定义是可被复制的。那么对于类似的流程就可以很容易被快速复制和扩展。
（2）基于模型的解析运行，也就代表着可被有效的监控和管理，这是传统硬编码开发很难逾越的。
第三个问题：如果去获取一个工作流引擎或平台？
工作流项目实施的前提就是必须已经存在一个工作流平台或工作流引擎，基于这个引擎或平台实施项目：这个平台或引擎，不论是够买第三方的，还是自己研发的，抑或是扩展自
开源的，但总归必须是有那么一个了。如果某一个厂商，其有自己的工作流产品，那么这个问题似乎就没有存在可能性了。但是对国内大多数开发商来说，这是一个很头疼的问题。当这些开发商接到一个工作流项目的时候，摆在他们面前的最直接问题就是：怎么搞定这个基础的工作流系统或工作流引擎，是够买一个现有流程产品，还是基于开源引擎扩展，抑或是自主研发？
这三个选择似乎都很困难，因为现在国内的工作流应用蓬勃发展，工作流厂商也如雨后春笋般一个接着一个的冒出来了，而且其中不乏有很多是以提供Platform 为主的；而开源引擎也越来越成熟和完善；而很多开上也着实希望能够用有自己知识产品的引擎，为以后项目实施解决成本。
下表就显示了一些代表性厂商和开源引擎：
平台厂商起步、浪潮楼上、炎黄盈动、普元、中创
工作流厂商西安协同、东兰、Joinwork、信亚达、华创动力、盛松
开源工作流引擎jBpm、OSWorkflow、Shark
所以对开发商来说，选择什么样的方式，是首要问题，甚至有可能上升到战略性问题。
在此，提供一些基本分析意见，供参考：
（1）如果仅仅只是实施一个或一些简单的流程应用，这个简单的意思不是指流程的结构简单，而是指客户的操作性简单，没有诸如“回退”“会签”“跳跃”之类的运转模型；而且客户对流程图形化定义也没有什么要求，只要能保证流程稳定运行，以及可进行简单的管理和监控操作即可。那么这种情况下，应该首先考虑“基于开源引擎扩展”。这是因为目前开源引擎基本上都比较成熟和稳定了，特别是jBpm，自从其被JBoss 收购之后，jBoss3 是越来越完善。据我所知，目前国内很多开发商就是基于jBpm 之上进行扩展实施流程项目的，并且很多都已经成功应用。
（2）如果项目要求非常紧，而且客户对流程设计、流程运行的要求也比较高。那么这种情况下，一般建议优先考虑商业应用产品，虽然采用商业产品必然会带来成本的增加，但是从满足客户的需求应用角度来讲，还是比较值的。但选择什么样的产品，这对很多厂商来说，也是较难于把握的。这一点我们随后再讲，先接下来看看什么情况适合自主研发。
（3）相信很多开发商都希望能拥有自己的工作流引擎或平台，因为对他们来说，首先是采用第三方的厂商产品会带来采购成本的增加，其次较为担心在流程项目实施过程中，因
为客户需求的复杂或突然变更，而厂商产品接口有限或功能却恰巧不满足的情况下，则会带来非常麻烦的事情。
但自主研发只在如下情况比较合适：目前项目交付压力不是很大，有至少两至三人的研发团队，持续投入半年到一年，并且其中有对工作流系统结构模型等方面有较深理解，并有
适当的实际引擎开发经验更好。从上面的条件可以看出来，这个要求是很高的，对国内大部分开发商来说，是很难提供这样的研发环境。自主研发工作流引擎或系统，一般都需要半年到一年左右的研发期，还需要一两年左右的项目实施和完善期，才大约能够走向成熟。
比较有代表性的开发商如下：
公司工作流引擎名称研发启动时间引擎初版发布
北京用友软件工程Nucleus 2004 年初2005 年中
北京慧点科技Galaxy 2003 底或2004 初2004 年底或2005 年初
在这里也顺便提个忠告，存在一些开发商的管理人员把工作流技术看的过于简单。当突然碰到有类似的项目的时候，以为找个开发人员，让其在开源引擎上去研究一段时间就可以应付复杂流程项目，这是大错特错的，而且大多都以失败告终。在我前面的参考方法中，第一句话就是——“仅仅只是实施一个或一些简单的流程应用”，才应该优先考虑开源引擎。
第四个问题：如果考虑第三方工作流产品，那么选择哪家产品更合适自己？
接下来，讲讲如何选择商业工作流引擎。
这两年国内工作流厂商是越来越成熟，产品的定位和分层也逐渐显现出来，比如西安协同的流程产品逐渐开始支持于基于ESB 的分布式流程应用，而上海携创的Joinwork 则依然定位在嵌入式工作流引擎。但是对于那些决定采用第三方工作流产品的开放商来说，如何选择一个最适合的产品，也依然是件非常困难的事情，毕竟国内大大小小的工作流产品有数十家：
在google 上搜索“工作流产品”，大约会搜索出7840000 条记录。下表列出一些较为常
见的工作流厂商和产品（不包括一些平台性厂商，如起步、普元、炎黄盈动等）：
神马EasyFlow、西安协同SynchroFLOW、上海携创的Joinwork、
信雅达SunFlow、东兰LiveFlow、中创InfoFlow、
有生博大RiseBPM、华创动力MatrixFlow、慧点Galaxy
东方易维Workflow、华苓AgentFlow、世纪金政Koof、盛松W-Flow、
东方通TongWorkFlow、维泰WiseFlow、超微SuperFlow、明基逐鹿eFlow
面对这么多的工作流厂商，开发商的选择主要困难在三个方面：
（1）很多开发商只有在接到工作流项目的时候才匆忙考虑购买产品，但此时客户需求详细调研还尚未完成，其所面对的客户也很难提出清晰明确的流程应用需求。所以开发商很难有个准确的衡量标准来评价什么产品最适合他们
（2）很多产品的功能表述的都很类似，产品演示也看似相近。功能似乎很多，但是到底哪些功能是真正需要的，而哪些产品是适合后续应用和扩展的，对开发商来说是很难决断的。（3）开发商的心理担心和犹豫：毕竟购买的工作流产品，对他们来说，似乎就像一个“黑匣子”一样，很担心后期实施中，因为客户的需求不满足而又无法更改产品，从而造成实施不下去的情况发生。
基于这几年工作流咨询和培训的经验，简单阐述一些选择的标准。主要是从如下几个角
度进行选择：
（1）首先搞清楚客户对流程设计器的要求或期望如何，是倾向于B/S 的web 设计器还是，
还对C/S 设计器也可接受。可能很多最终客户对这两者是用上的区别不胜清楚，那么就需要开发商首先自己需要清楚这两者的区别，以及斟酌所定位的客户的应用习惯和场景，那种操作凡是更适合客户使用。
（2）其次，客户对流程的应用模型和操作习惯如何，诸如是否支持“串型”“并型分支”“条件分支”“同步异步子流程”“多种类型的执行人分配”“会签”“回退”
“取回”“跳跃（速称自由流）”等等，这些都是国内常用的基本流程应用需求。相信这些功能很多产品也都宣称支持，但是具体支持的力度，却需要自己仔细分析。举个例子：有些产品宣称支持回退，但是在项目实施的时候，却告诉开发商在流程图上需要额外多绘制一条转移连接线来实现回退的操作。那么一旦开发商所面对的客户要求能够实现“逐级回退”则变得非常棘手。
（3）客户的流程变更性如何，如果客户提出了流程变更，那么如何维护流程的变更操作是开发商需要仔细考虑的。一方面以此来分析工作流产品如何支持流程变更，一方面需要确定是否会存在客户自己进行流程定义更改的情况。毕竟一个工作流系统实施后，最终的使用者还是客户，而客户的业务应用有可能会在后续发展中发生变化的。
（4）客户的应用系统中流程是否很多。存在有些工作流应用中，只实施几个流程而已，但也存在有的项目实施中，一个系统却包含几十个甚至上百个流程定义。前一种情况如果产品提供商所提供的工作流系统完整性还不够的话，通过后续开发商的实施尚且可以弥补；而后一种情况则要非常小心了，开发商必须选择一个系统完整化和成熟度比较高的工作流产品。这样一类的工作流产品除了流程设计器和引擎以外，还可能会包含：可扩展的组织模型、表单系统、工作列表系统，甚至还有监控和管理部分。——但是系统复杂度越高，扩展复杂度也越大，所以开发商必须在这个层面寻找一个适度的平衡。
（5）就国内目前的绝大多数流程应用来说，流程监控应用性需求还不是很高。很多客户提出对流程监控的需求，也仅仅只是“觉得有这个必要”，但等到系统真正上线后，使用流程监控功能的却很少的。但是，有这一类功能的工作流产品总归比没有要强一些，但需要哪种深度的监控，那就需要开发商自己斟酌一下了。这两年在给一些开发商咨询的过程中，碰到很多开发商希望工作流产品能够“assembling on demand”，就是能够按照需要的功能组装。因为很多开发商抱怨，他们用昂贵的价格选择了一个很好的工作流产品，但是却只使用了很少的功能；而那些价格较低的轻量型流程产品，却在有些功能上不能满足或细粒度不够，很难达到客户和二次开发的需求。事实上我也一直在期待国内能有这样架构的流程产品出现。
第五个问题：如何更加有效的进行流程系统实施
如果此时开发商已经有一个基础的工作流引擎或产品了，不论是采购第三方的，还是自主研发的，那么接下来所面对的最大的一个问题就是如何更加有效的实施流程了。很多工作流实施阶段本身其实没有太多的技术难度关口，最大的难度是在需求调研阶段的“流程梳理”。很多开发商在需求阶段都会反复抱怨“客户没有什么需求，或者客户让我们先做个demo 再
提需求”。
就目前国内流程应用情况来说，绝大多数客户都会直接把“流程需求”的问题直接推给开发商自己处理。这就需要开发商采取正确的策略和方式来一步步推进，而不能再像早期实施其它MIS 系统似的采用“需求+静态页面Demo+数据库设计+开发”策略了。
对于很多客户来说，实施工作流系统一方面是响应“从有纸化转变为无纸化”号召，逐渐推进信息化应用；另一方面则希望通过“流程系统”有效的梳理出某些流程在办理过程中的真正处理过程。在早期没有流程系统的时候，不论在政府办公还是企业管理，某些处理流程虽然有“规章制度约束”，但是在真正办理过程中，因为一些人为的因素，会存在一些变通的处理，从而会造成某些流程实际在审批过程中会“跳过”或“多出”一些环节。而且对一个管理人员来说，当其面对一个审批文件过来的时候，一般是很难非常清晰这个事情到底要经过哪些环节、哪些人的审批的。所以在现实操作过程中，很多情况是依据一些常规经验和个人判断处理。
那么流程信息化就要逐步帮助管理人员来逐步规范和梳理这些流程的处理步骤。这也是很多客户在流程信息化中的现阶段真实目标。开发商只有摸清客户对流程的真实目标期待，才能过采取有效的需求调研和实施方案，以及流程实施功能定位。
网络上不乏有一些所谓工作流实施介绍的文章，大体会告诉大家采用如下的步骤：
建立项目管理办公室、业务分析、确定目标、确定实施计划、流程建模、软件集成······。这套步骤对于那些具有深厚的行业应用积累经验以及成熟的工作流实施经验的厂商是非常合适的，但是对于很多开发商来讲，却存在很大的误导性。
前面已经说过，对很多客户来说，其真正关心的是“梳理真实清晰的现实流程”。如果开发商能够通过与客户的不断沟通，逐渐帮助客户梳理现实操作中的流程处理过程，并用流程系统实现，则基本百分之九十的满足客户需求了。这个梳理过程不是一次两次就可以清晰搞定的，需要开发商在需求调研阶段不断的绘制流程图（最好就用流程设计器直观的绘制），绘制一次就与客户进行沟通和演示，依据客户确认后提出意见再修改，再完善，再由客户确认。如此反复，才能正确帮助客户梳理出流程。
在梳理流程阶段，一定要把握几点：
（1）一定不要抱怨客户提不出什么需求，这个必须自己去逐步挖掘需求。因为客户对流程系统和流程信息化所带来的办公操作和影响并没有预见性，这需要开发商逐步帮助客户去理解，去应用。
（2）一定要不断的找相关业务处理的负责人进行流程确认，找真实办理职员进行系统演示，因为只有这些人员才清楚现实流程的真实办理过程。
（3）不要把需求调研和流程实施过分区分开，如果在需求调研过程中，就一步步地用流程设计器进行流程绘制，并给客户演示，则更容易让客户提出一些潜在的流程需求，而不至于到了项目后期或上线试运行阶段，客户才大量的提出修改需求来。
作者简介：
胡长城，网名“银狐999”。就职于TIBCO CDC，Infrastructure team
国内J2EE 开源应用的支持者，有过六年的J2EE 应用和产品开发及架构经验，huihoo
开源组织成员。
国内工作流应用的推广者，有过四年的工作流研发经验。利用个人主页和Blog 共享了
很多宝贵的工作流研究心得。尝试开拓了工作流培训方式，为企业工作流应用提供咨询和指导。
工作流系统需求分析 业务过程描述： 工作流是一种反映业务流程的计算机化的、实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务模型。工作流起源于生产组织和办公自动化领域，其目的是将现有工作分解，按照一定的规则和过程来执行并监控，提高效率，降低成本。 下图是用户使用工作流系统的业务过程：
业务模型描述：
系统组成： 工作流管理系统由客户端、流程定制工具、流程监控与管理和工作流运行服务四个部分组成，下图是系统构件图： 系统功能划分： 工作流管理系统是指运行在一个或多个工作流引擎的软件上用于定义、实现和管理工作流运行的一套软件，从用户建模的过程来看在建立阶段功能主要是工作流过程和相关活动的定义和建模，在运行阶段包括运行流程的监控、管理以及执行过程中的人机交互等。 工作流管理系统由流程定制工具、流程监控与管理、工作流运行服务和客户端交互四个部分组成，整个系统的使用者可以分为四种：系统管理员、流程设计人员、流程管理人员、普通用户。 下图是整个工作流管理系统的顶层用例：
第一部分流程定制工具 本部分主要完成企业信息流中业务过程的图形化建模，定制工具提供丰富的图形化元素、简单易懂的建模方法以及完善的模型管理方式。 流程定制用例图：
打开流程模型 参与者：流程设计者。 前置条件：流程定制工具已经打开。 后置条件：被选择的流程模型中的内容被展开。 步骤序列： 1．打开流程模型列表或新建流程模型文件。 2．选择流程模型文件名称。 3．展开流程模型中的设计内容。 保存流程模型 参与者：流程设计者。 前置条件：某个流程模型已经被打开，并且被修改。 后置条件：修改过的流程模型存到了物理文件中。 步骤序列： 1．保存流程模型到物理文件中。 删除流程模型 参与者：流程设计者。 前置条件：拥有可被删除的流程模型。 后置条件：选中的流程模型被删除。 步骤序列： 1．用户打开流程模型列表。 2．用户选择想要删除的流程模型。 3．系统删除选中的流程模型。 导入导出流程模型 参与者：流程设计者。 前置条件：拥有可被导入的文件或导出的流程模型。 后置条件：流程模型被导出成文件或模型文件被导入到设计系统成为流程模型。 步骤序列： 1．用户打开可被导入文件列表或设计工具中的流程模型列表。 2．用户选择将被导入的流程文件或选择将被导出的流程模型。 3．系统把导入文件生成流程模型或把导出流程模型生成流程文件。 流程发布 参与者：流程设计者。 前置条件：拥有设计完成并可供发布的流程模型。 后置条件：流程模型被发布并可通过客户工具执行。 步骤序列： 1．用户打开流程模型列表。 2．用户选择发布的包或流程。 3．用户选择发布的运行服务器。 4．用户形成发布版本。
湖北XXXXXXXXX）产业集团 关于修订印发《工作流使用管理办法》的通知 各单位/部门： 为减少工作流使用不当的情况发生，从而提高工作流审批效率及企业信息化实施水平，我部门制定了《工作流使用管理办法》。根据该办法前期执行的实际情况，经征求各方面意见后，我部门对部分条款进行了修改和完善。现将修订后的《工作流使用管理办法》（见附件）印发，请各单位认真组织学习。 修订后的《工作流使用管理办法》自2012年8月20日实施，望各单位/部门遵照执行。 特此通知! 信息中心 二O—二年八月十九日
工作流使用管理办法 第一章总则 第一条为推进企业信息化建设的顺利实施，规范0A系统工作流的管理，明确公司工作流使用的要求，达到提高工作及管理效率的目的，特制定本办法。 第二条本办法适用于湖北XX建筑装饰工程有限公司（以下简称集团公司）及子公司所有员工。 第二章工作流的定义 第三条工作流：0A内置的流程子系统，可实现各类工作的申请、审批、会签、登记、查询等环节的管理，可将协同工作的过程进行记录，便于日后审核与查询；并实现业务数据的规范化录入、查询、统计和存档；0A的工作流系 统由表单和流程两个重要元素构成。 第四条表单：是与工作相关的数据的载体，相当于现实工作中的纸质工作单，工作单上的手写数据通过表单上的各类控件得以体现；除表单以外，我们还可以通过公共附件或会签区传递一些数据和信息，以便更好的完成工作流程。 第五条流程：是工作过程和环节的描述，流程由工作的多个步骤组成，每一步由指定的经办人填写指定的表单控件。 第三章工作流的发起 第六条为节约办公耗材，提高工作效率，实现信息化的有效推广，经集团公司审核通过的工作流禁止采用纸质操作。 第七条各员工需认真学习各工作流的作用及适用范围，在发起流程时，需选择与该工作相对应的工作流。 第八条对于明确指定了对应发起人的流程（IT类、盖章类、物业服务类等），当其他人员需要申请该工作流时，需和具有相应申请权限的人员进行对接， 委托该人员进行流程的申请。
Toward Workflow Block Activity Patterns for Reuse in Workflow Design Lucinéia Heloisa Thom and Cirano Iochpe Federal University of Rio Grande do Sul, Brazil; Vinícius Amaral and Daniel Viero, iProcess, Brazil 1.I NTRODUCTION Research on both business process modeling and implementation issues re-lated to workflow technology have quickly increased over the last years. The most significant initiatives are in the field of standardization [1], [2], [4], specification [5] and workflow definition languages [6], [7], [3]. However, since it is a relatively new and still evolving technology, workflow design pre-sents some challenges, especially with respect to techniques that can en-force correctness as well as efficiency during both the requirements analysis and the modeling phase of the workflow project. Within this context, research on workflow patterns has attracted increasing attention mainly because of the advantages of reusing patterns [8], [9]. The most extensively studied are in the field of control/data flow patterns [10], [11] as well as resource and application–oriented patterns (12). Such pat-terns are being used not only in business/workflow process modeling but also in critical evaluations of workflow languages and workflow tools (13). However, a lot less research can be found relating workflow design to a set of recurrent business process “pieces” or “parts” that must be atomically exe-cuted by the workflow process (e.g., an activity request execution and a noti-fication activity). Although one can precisely characterize the semantics of such business process “pieces” [14], [15], [16] and they have to be recur-rently re-designed in practically every workflow modeling process, there is no known research relating these business process structures to workflow pat-terns. 1.1 Approach Our approach applies the concept of block activity to well-known business processes. An activity set is a self-contained set of activities and transitions [7]. Transitions in the set should refer only to activities in the same set and there should be no transitions into or out of the set. Activity sets can be modeled as block activities. The block execution starts at the first activity in the set and executes the next activities by following the partial order im-posed upon them by the transitions until an exit activity is reached. Work-flow execution then returns to the next activity following the block. In this paper, we apply the block activity concept in order to represent a set of business (sub-)process types (e.g., logistic, financial, information and de-cision) that we call “workflow block activity patterns”. These patterns are re-lated to a set of specific atomic structures that are frequently found in busi-ness processes and have already been identified in the literature [14], [15],
流程业务需求 Prepared by 拟制方进 Date 日期 2013-10-16 Reviewed by 评审人Date 日期 Approved by 批准Date 日期
1工作流建设目标 为某某公司建立统一，集成的工作流系统平台，实现业务审批流程电子化。体现某某公司业务执行的透明度和规范化，提高业务处理效率和协作效率。 1.1管理需求 管理模式：通过实施工作流理顺业务流程，即销售业务审批流程，设计业务审批流程，行政管理审批流程等，提高业务协作效率，实现公司有效规范的管理目的 数据集成方面：工作流系统与业务系统集成，共享业务数据，实现单一创建多出引用原则 技术方面：要求系统在集成性，稳定性，拓展性，可适应性方面符合某某公司的发展需要。对于权限和安全性方面，提供可靠的保障。同时需要支持移动设备的审批。 组织和人员：通过工作流的建立帮助企业实现业务处理的完整性，实现业务和公司规范执行的有效结合。帮助企业梳理业务，规避风险，提升工作质量。 1.2技术要求 ◆流程设计工具实现流程定义，实现，人员，角色，部门定义。实现流程版本控制 ◆流程设计工具实现表单定义 ◆实现流程中不同的节点和不同的表单关联 ◆工作流节点支持脚本扩展,比如编写beanshell脚本,或其他语言的脚本 ◆实现表单中，一对多的主子表单的关联，比如在《担保支付运费服务协议》中除 了有正文合同，可能还有授权委托书a1，授权委托书a2，第三方代付费用，结算 方案确认合同等等。 ◆对于流程审批的人员管理如何设定 ◆审批委托设定，比如部门经理a出差，委托经理b待审批流程。 ◆手持设备访问工作流，进行审批动作 ◆流程中的某个节点长期没有审批，设置一个阀值，超过该阀值触发邮件动作提醒， 或终止流程等业务动作。 ◆工作流系统与其他业务系统集成方式
工作流程的定义及工作流系统如何开发 时间：2004-10-10 工作流就是： 在一个工作群组中，为了达成某一个共同目的而需要多人协力以循序或 平行工作的形式来共同完成的任务” 关于工作流的几个名词解释： 工作的流动性是一个人接着一个人执行，或同时由多人分开执行，或是上 述两类工作合并之后的混合性工作 泛指各种事务上所 必需执行的流程性 工作 循序或平行工作 若是单人就可以完 任务 多人
成的工作,则不能
归类为流程工作。 凡是一件工作必须 经由两个或更多人 来协力完成的工作 才能称为流程工作 多人参的流程性工 作，必须是以完成 共同目的为前提。 如果一群人是分别 共同目的 针对不同的专案来 执行各别的工作， 并不算构成一个工 作流程 工作流程的应用范围 在一般的组织活动中，有相当多数量的事务性工作可以被归类到流程性工作的范围里面，举例如下： 工作报表呈报流程
采购单 流程贷款审核流程 员工绩效考核 流程
各类报 表会签 流程 如何架构一个工作流程 首先要定义出在一个群组工作的环境下，所需要执行或控管的事务性工作性质 及其内容 根据所定义的工作内容，再将它分成许多子工作，或称为步骤。每个步骤都都 包含了在这个阶段所需要完成的项目清单，而且这些步骤内的项目应当是在逻 辑上适合在同一步骤内完成的。任何一件流程工作都会有许多不同的方法来分 解成许多子工作，而如何切割一个流程工作，则要根据实际的情况来做判断；决定各个步骤需要那些专业背景的人员来执行； 决定各个步骤在流程执行时的顺序； 在执行的过程中，有些步骤的执行会因为某些条件不同而产生不同的结果，进而影响到下一个步骤的执行。所以我们必须要找出这些特定的步骤，并且将相关的执行状态条件定义清楚； 将工作流程中的所有执行步骤及每个步骤之间的关系图画出来，并且根据这份关系图来验证流程的可行性。 根据各个步骤的不同需求，分别建立各阶段所需要的表单，工作指令，文件……等项目。 工作流系统开发一般的工作流管理系统由三个部分组成：工作流引擎、流程管理工
西北工业大学软件与微电子学院 <工作流管理系统> 需求规格说明 版本：1.0 编写：年月日校对：年月日审核：年月日批准：年月日
目录 1引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (2) 2任务概述 (2) 2.1目标 (2) 2.2用户特点 (2) 3需求详述 (3) 3.1关键信息 (3) 3.1.1名词解释 (3) 3.2过程描述 (5) 3.2.1系统管理 (5) 3.2.2流程设计 (8) 3.2.3业务管理 (14) 3.2.4用户操作 (23) 4说明 (26)
1引言 1.1编写目的 本需求规格说明书对系统所要实现的功能分模块进行了详细说明，它是一份描述系统整体结构及工作流程的文档。本需求规格说明书主要向客户方及与本项目相关的人员发放，使他们了解该软件的功能结构详细情况。 1.2背景 待开发系统是由631所提出的，针对该所的业务要求及外协任务说明。该系统包括四个子系统： 系统管理； 流程设计； 业务管理； 用户系统。 本系统由西北工业大学软件与微电子学院负责开发，系统的开发环境为：Windows＋J2EE。 1.3定义 WfMC（Workflow Management Coalition）：工作流管理联盟。 流程设计：创建工作流模型，根据实际的业务流程创建可视的流程模型。 业务管理：是对工作流模型和实例进行监控和管理。 活动：是一项工作的原子单元。有时会使用节点代替活动。 流程：是活动的集合，有时会使用工程代替流程。 角色：指工作流模型的参与者和任务承担者，和权限相关联。 用户：指工作流系统的使用者。 连接：是两个活动之间顺序依赖的根据，有时会使用边代替连接。 变量：是工作流的数据单元，被称做工作流相关数据。
1. a. b. c. 2. 1. 1. 工作流配置 工作流范例 工作流快速配置 更多工作流程配置 工作流功能列表 触发条件 (并行审批) 用户在待审批人字段 中 只有当前用户在 ‘待审批人’ 字段中，才会显示当前工作流动作按钮。 '待审批人字段' 在 下面处理结果中三个并行审批设置中的任一个设置中指定： 章节(并行审批) 批准 (并行审批) 拒绝 (并行审批) 反馈 (并行审批)隐藏工作流动作 用于对所有用户隐藏当前工作流动作按钮。一般用于系统自动执行。例如：当所有审批人都审批完成后，工作流动作自动执行 '完成' 的动作。 校验条件 (并行审批)备注必填 用于检查用户是否填写了备注。备注可以被复制到 ‘审批意见’ 字段，以便于集中展示所有审批人的审批意见。 处理结果 (并行审批) 批准 执行并行审批的 批准 动作。 执行这个工作流动作后，都会把当前用户从 ‘待审批人’ 字段移动到 ‘已审批人' 字段，当 待审批人 字段 为空时(即所有人都审批完成)，自动执行 ‘审批完成’ 的工作流动作。 如果用户填写了审批意见，那么在JIRA 问题查看页面，就会标注审批意见类型为 目录工作流范例工作流功能列表 触发条件 校验条件处理结果
2. 3. 4. 同意 (并行审批) 拒绝 执行并行审批的 拒绝 动作 如果用户填写了审批意见，那么在JIRA 问题查看页面，就会标注审批意见类型为 拒绝 (并行审批) 反馈 仅用于只添加反馈意见的多人并行流程。 执行这个工作流动作后，都会把当前用户从 ‘待审批人’ 字段移动到 ‘已审批人' 字段，当 待审批人 字段 为空时(即所有人都审批完成)，自动执行 ‘审批完成’ 的工作流动作。 如果用户填写了审批意见，那么在JIRA 问题查看页面，就会标注审批意见类型为 反馈 (并行审批) 复制项目角色成员到自定义字段 如果每次申请的审批人都相同，不希望用户每次都手动选择审批人，就可以使用这个功能。通过用户角色维护审批人，然后插件会将项目角色成员复制到审批人字段，。 将指定项目角色中用户复制到指定多用户类型自定义字段 这个设置与 ‘(并行审批)批准’ 的区别在于，填写的 ‘审批意见’ 的类型不同。
版本一： 回退（Rollback WorkItem） 回退是工作流参与者对自己“待办任务”（实际是对工作项）的一种操作，即参与者主动回退待办任务列表中的任务到已经执行过的人工节点。 为什么要回退？ 参与者接受任务后，发现不应由自己办理此任务或以前的执行者办理有错误等情况后，需要将此接受的任务回退给以前某个节点的执行者重新办理。 回退模式 回退的情况实际上是非常复杂的，其中包括了参与者的重新选择以及回退的条件判断等等。这里先列出常见的回退模式（其实也是我们支持的模式）。 串行
这种情况最为简单，后续节点可以回退到前续任意人工节点。回退后，节点重走。 分支 这种情况也相对简单，实际执行的分支上的节点可以回退到前续任意人工节点（不区分主支和分支）。同样，主支上的节点也可以回退到任意实际执行的分支上的节点。 可能的问题：多次回退后的回退节点选择。例如：第一次流程经过节点2、节点3到达节点5，节点5可以回退到节点1、节点2和节点3的任意一个，此时节点5回退到节点1，节点1重走，这一次流程改为经过节点4到达节点5，节点5回退时如何选择回退节
点？此时的策略是以最近实际执行的分支为准，即节点5只允许回退到节点4和节点1，不允许回退到节点2和节点3。（抹去记忆） 并发 对于并发的情况，分支节点只允许在分支的节点间回退。
同理，主支节点也只允许在主支的节点间回退。多实例汇聚
在这种情况下，节点5会产生2个实例，实际相当于继续并发。节点5根据具体哪个节点触发的它而产生回退节点。同时不允许回退到节点1以及前续的节点去。 子流程 支持子流程到父流程的回退，也支持父流程到子流程节点的回退。 需要注意的是子流程节点有可能产生多个子流程实例，在这种情况下不支持父子流程之间的相互回退。 回退节点的参与者选择 默认策略是由原先节点的实际参与者重新处理，比如节点2回退到节点1，则节点1的实际参与者重新处理该节点任务。这也符合大多数实际的业务场景。
关于双鸭山市煤炭局信息化子系统原型设计及工作流实现总结 在近一个月的工作时间里，主要针对双鸭山市煤炭局信息化子系统进行了基本模块的概要需求分析，其中针对建设项目管理和生产技术管理模块进行了具体的需求分析并实现了此两个模块的原型。对详细需求分析的过程了解到实现建设项目及其它各种审批使用工作流实现较符合。对于工作流的使用进行了两方面的接触，一方面是使用.NET中的Workflow Foundation(简称WF）进行自行开发，另一方面是使用现在市场上已经成行的工作流配置产品。 使用WF实现工作流主要用到了三个类库System.Workflow.Runtime; System.Workflow.Activities; System.Workflow.Activities.Rules。其中System.Workflow.Runtime包含的类和接口用于控制工作流运行时引擎和工作流实例的执行。System.Workflow.Activities定义一些活动，可将这些活动添加到工作流，以便创建并运行工作过程的可执行表示形式。程序员也可以实现自定义的活动。System.Workflow.Activities.Rules中的类定义了组成规则的条件和操作。.Net FrameWork提供工作流持久化服务，对SQL数据库的持久化提供了完全的支持与实现，对于其它类型的数据库在完成持久化服务的时候要由程序员编程继承WorkflowPersistenceService 类来实现。 在使用WF进行编程时可分为业务逻辑实现、具体数据库访问、自定义活动三个部分，程序员在进行实现时无须对三个部分全部熟悉，只要针对具体的部分熟悉其它部分了解即可。比如对工作流的流程熟悉的程序员可以实现业务逻辑部分，这部分主要是根据用户的业务流进行绘制工作流，对工作流各活动进行配置相应的参数的关联即可。目前对于在VS开发过程中如何配置工作流的操作基本可以完成，但如何把VS中工作流制作模块移植到B/S页面中还未操作过。
关于工作流系统技术选型可行性分析 1系统背景 医院的运作过程本质上是人、财、物等资源的优化和配置，形式上无一不体现为信息流、资金流、物流、价值流等合理的流动；随着医院不同科室、部门分工的日益具体化，合作已成为主题，合作的体现形式必然是一个完整而高效的工作流程；有管理的医院的活动过程必然是有序的，这种有序性体现为合理的工作流程。因而工作流(workflow)无处不在。 2系统建设目标 1)隔离workflow系统的控制逻辑和医院业务系统的业务逻辑，使得业务逻辑 的变更对于控制逻辑透明。 2)利用该引擎开发的业务信息系统可以根据具体业务需求量身定制个性化的 业务流程，而不用修改控制逻辑，甚至无需修改源代码。 3)业务人员、开发人员、实施人员可以共同参与流程制定、流程、节点维护 4)提供灵活、丰富的标准开发接口，使得开发人员能采用自己习惯的开发工 具在该平台上定制和扩充模块。 5)采用多层分布式组件技术，力求技术先进性和应用的健壮性。 6)工作流自动化和医院应用积木化。 3工作流技术选型方案 3.1 技术选型目标 1)较好的流程定义工具。 2)工作流技术架构与业务系统之间解耦性较强。
3)工作流系统定位为嵌入式系统，并进行嵌入式部署。 4)业务人员、开发人员、部署实施人员均可参与对流程定义做可视化管理 5)业务人员、开发人员、部署实施人员均可参与流程走向做可视化管理。 6)可从容应对较常使用的工作流场景 7)架构开源程度——100% 8)开源社区活跃度较高 9)架构文档较为齐全 10)监控、管理功能支持 11)有较好其他工作流引擎整合方案 3.2 开源工作流选型 当前开源工作流种类繁多，现对目前国内较活跃的三种工作流（jBPM4,jBPM5,Activiti5）做简要介绍与分析，供参考： 3.2.1jBPM4 3.2.1.1架构简介 jBPM4 全称java Businuess Process Management 第四版(最后一个修订版本jBPM4.4发布于2010-07-19 ),是一种基于javaEE 的轻量级工作流管理软件包。jBPM 项目由Tom Baeyens 2002年发起，并与2004加入到JBoss组织，至今jBPM 发展至今有九年时间，在国内外均有大量的社区与商业支持。jBPM3、jBPM4拥有极度活跃的用户论坛和开发者论坛。
工作流设计参考（包括PHP实现） 本文关键词：php工作流,workflow 工作流设计的工作流很少有让人满意的，即便是国内用的比较多的jbpm，用起来也会觉得很便扭。再加上PHP中没有什么好用的工作流，于是干脆自己设计一个，设计的原则如下： 1 根据80/20原则，只使用wfmc模型中最符合自身应用的20％功能 2 充分吸收国内使用jbpm开发BOSS中遇到的问题，工作流引擎只负责参数的收集和流程的流转，具体和业务的控制，交给每个流程定制的控制类去实现。 3 表单采用简单的html+控制标签的方法实现 4 权限和模板引擎，以及其它辅助函数直接使用办公系统自带的框架 5 充分利用PHP语言的特点，流程设计是基于数据库的，程序上使用OO设计，但采用重对象的方法 6 不把可视化设计流程的工作交给最终客户，而且由设计时完成，因此不考虑流程版本更新的问题 一、工作流数据表设计
二、常见流程人工决策 领导传阅 部门领导审批填写表单
结束 放弃 提交 同意 重填（退回） 不同意 完成 外部响应 发送支付信息 接收支付成功响应（外部WS触发该流程） 三、PHP设计 运行的函数由结点在设计时候决定，如果没有设定，就使用默认的函数。利用了PHP语言的以下特性
使用前可以用method_exists来检查。 WorkflowService.php WorkflowService $defination $process $node $thread $input 用户输入的和流程有关的变量 list_defination(){ } init_process(defination_id){ global user; 取得$defination，得到业务的handler,例如WorkflowProposalHandler 建立$process行记录 } start_process(){ 调用WorkflowProposalHandler->start($process)//新建业务对象，并把业务类的参数例如proposal_id放到$process[‘context’]里面 init_thread(1); //默认调用第一个结点 } list_ my_thread (){ global user; } init_thread(node_index){ 取得$node 取得$process 修改$process为运行到当前结点 Switch($node[‘node_type’]) Case 1: 人工决策 建立$thread WorkflowProposalHandler-> init_function ($process,$node,$thread) 发送提醒 Case 2: 自动处理 建立$thread WorkflowProposalHandler-> init_function ($process,$node,$thread) 调用run_thread(thread_id) Case 3: 等待外部响应 建立$thread WorkflowProposalHandler-> init_function ($process,$node,$thread) Case 4: 分支 取得所有分支的子结点
工作流系统功能介绍 目录 1概述 (2) 2流程系统设计总图 (4) 3建模工具 (4) 3.1组织机构管理 (5) 3.1.1主界面 (6) 3.1.2岗位管理界面 (7) 3.1.3部门管理界面 (8) 3.1.4员工管理界面 (9) 3.2权限管理 (10) 3.2.1主界面 (11) 3.2.2权限组管理界面 (12) 3.2.3权限设置界面 (14) 3.3流程管理 (14) 3.3.1流程管理主界面 (15) 3.3.2启动节点配置界面 (15) 3.3.3处理者配置界面 (19) 3.3.4流转条件配置界面 (19) 3.3.5控制节点配置界面 (20) 3.3.6子流程节点配置界面 (21) 3.4表单管理 (21) 3.4.1表单管理主界面 (22) 3.4.2选择用户控件界面 (23)
4工作流引擎 (23) 4.1基本功能 (23) 4.2任务节点类型 (25) 4.2.1启动节点 (25) 4.2.2结束节点 (26) 4.2.3交互节点 (26) 4.2.4子流程节点 (26) 4.2.5控制节点 (26) 4.2.6查看节点 (26) 5业务平台 (26) 5.1业务平台主界面 (27) 5.2例子:差旅费报销流程 (27) 5.3未认领任务 (29) 5.4已认领任务 (30) 5.5已完成任务 (30) 5.6查看流程图 (30) 6与门户sps系统的整合 (31) 7流程监控服务系统（即时消息和Email） (32) 1概述 随着计算机软件应用的普及，信息化系统发挥的作用也越来越大，企业信息化建设的不断深入，对系统功能和自动化程度要求越来越高。客户要求系统功能与实际的工作情景紧密结合，对每个业务环节的控制要求越来越精确。如何让我们的信息化系统更加贴近客户需求，满足客户不断变化的业务流程成了我们软件开发商不得不面对的问题。
湖北XXXXXXXXXX产业集团 关于修订印发《工作流使用管理办法》的通知 各单位/部门： 为减少工作流使用不当的情况发生，从而提高工作流审批效率及企业信息化实施水平，我部门制定了《工作流使用管理办法》。根据该办法前期执行的实际情况，经征求各方面意见后，我部门对部分条款进行了修改和完善。现将修订后的《工作流使用管理办法》（见附件）印发，请各单位认真组织学习。 修订后的《工作流使用管理办法》自2012年8月20日实施，望各单位/部门遵照执行。 特此通知！ 信息中心 二〇一二年八月十九日
工作流使用管理办法 第一章总则 第一条为推进企业信息化建设的顺利实施，规范OA系统工作流的管理，明确公司工作流使用的要求，达到提高工作及管理效率的目的，特制定本办法。 第二条本办法适用于湖北XX建筑装饰工程有限公司（以下简称集团公司）及子公司所有员工。 第二章工作流的定义 第三条工作流： OA内置的流程子系统，可实现各类工作的申请、审批、会签、登记、查询等环节的管理，可将协同工作的过程进行记录，便于日后审核与查询；并实现业务数据的规范化录入、查询、统计和存档；OA的工作流系统由表单和流程两个重要元素构成。 第四条表单：是与工作相关的数据的载体，相当于现实工作中的纸质工作单，工作单上的手写数据通过表单上的各类控件得以体现；除表单以外，我们还可以通过公共附件或会签区传递一些数据和信息，以便更好的完成工作流程。 第五条流程：是工作过程和环节的描述，流程由工作的多个步骤组成，每一步由指定的经办人填写指定的表单控件。 第三章工作流的发起 第六条为节约办公耗材，提高工作效率，实现信息化的有效推广，经集团公司审核通过的工作流禁止采用纸质操作。 第七条各员工需认真学习各工作流的作用及适用范围，在发起流程时，需选择与该工作相对应的工作流。 第八条对于明确指定了对应发起人的流程（IT类、盖章类、物业服务类等），当其他人员需要申请该工作流时，需和具有相应申请权限的人员进行对接，
工作流系统需求分析及设计 业务过程描述： 工作流是一种反映业务流程的计算机化的、实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务模型。工作流起源于生产组织和办公自动化领域，其目的是将现有工作分解，按照一定的规则和过程来执行并监控，提高效率，降低成本。 下图是用户使用工作流系统的业务过程：
业务模型描述：
系统组成： 工作流管理系统由客户端、流程定制工具、流程监控与管理和工作流运行服务四个部分组成，下图是系统构件图： 系统功能划分： 工作流管理系统是指运行在一个或多个工作流引擎的软件上用于定义、实现和管理工作流运行的一套软件，从用户建模的过程来看在建立阶段功能主要是工作流过程和相关活动的定义和建模，在运行阶段包括运行流程的监控、管理以及执行过程中的人机交互等。 工作流管理系统由流程定制工具、流程监控与管理、工作流运行服务和客户端交互四个部分组成，整个系统的使用者可以分为四种：系统管理员、流程设计人员、流程管理人员、普通用户。 下图是整个工作流管理系统的顶层用例：
第一部分流程定制工具 本部分主要完成企业信息流中业务过程的图形化建模，定制工具提供丰富的图形化元素、简单易懂的建模方法以及完善的模型管理方式。 流程定制用例图：
打开流程模型 参与者：流程设计者。 前置条件：流程定制工具已经打开。 后置条件：被选择的流程模型中的内容被展开。 步骤序列： 1．打开流程模型列表或新建流程模型文件。 2．选择流程模型文件名称。 3．展开流程模型中的设计内容。 保存流程模型 参与者：流程设计者。 前置条件：某个流程模型已经被打开，并且被修改。 后置条件：修改过的流程模型存到了物理文件中。 步骤序列： 1．保存流程模型到物理文件中。 删除流程模型 参与者：流程设计者。 前置条件：拥有可被删除的流程模型。 后置条件：选中的流程模型被删除。 步骤序列： 1．用户打开流程模型列表。 2．用户选择想要删除的流程模型。 3．系统删除选中的流程模型。 导入导出流程模型 参与者：流程设计者。 前置条件：拥有可被导入的文件或导出的流程模型。 后置条件：流程模型被导出成文件或模型文件被导入到设计系统成为流程模型。 步骤序列： 1．用户打开可被导入文件列表或设计工具中的流程模型列表。 2．用户选择将被导入的流程文件或选择将被导出的流程模型。 3．系统把导入文件生成流程模型或把导出流程模型生成流程文件。 流程发布 参与者：流程设计者。 前置条件：拥有设计完成并可供发布的流程模型。 后置条件：流程模型被发布并可通过客户工具执行。 步骤序列： 1．用户打开流程模型列表。 2．用户选择发布的包或流程。 3．用户选择发布的运行服务器。 4．用户形成发布版本。
特殊说明，均属虚构。 本手册以及本手册所提及的任何产品的使用均受适应的最终用户许可协议限制。本手册由上海泛微软件有限公司制作。本手册中提及的所有商标、商标名称、服务标志及徽标均归其各自公司所有。
目录 五、工作流程(e-workflow) 工作流管理是提高组织效率的有效工具。与传统的纸张上的操作相比，在电子化的流程当中，每个请求不会丢失，而且在工作流的每个阶段由谁来负责处理请求也都有了明确的定义。 工作流管理模块同时也提供了可定制的浏览和报告的功能，从这些报告中可以清晰的了解哪些请求是创建最频繁的，哪些人处理的请求最多，以及每一个工作流完成所需要的时间周期。 通过电子化的方式，可以很方便的根据一个工作流相关的政策信息和手续对工作流进行定义，每一个请求的创建和批准都是基于一个规范，这将有助于按照统一、合理、高效的方式处理各种请求。 在系统中通过工作流管理模块可以按照组织的需求设置所需的工作流类型。 工作流管理模块与系统其他模块的链接关系，下图是一个示意图： 由于每一个请求都对应了一个系统定义的工作流，所以所有同类型的请求都将由一种工作流类型的方式来完成。这种类型的所有请求包括了同样的信息类型，同时在请求中明确了每一步由哪些人负责处理这些请求。 定义一个请求类型指创建这种类型的请求时，相应的工作流的表现方式。例如，一个缺席请求应该由该员工的经理和人力资源部门来进行批准。这样当一个员工递交缺席请求时，这个请求将自动流转到该员工经理那里。这些信息需要在定义该请求类型时进行设置。 当建立一个请求类型时，与之相关的选项和必要条件也就相应的确定。因此建议在建立和使用新的请求类型之前，用户需要参考和此请求类型相关的政策和文档。 这样做的原因是，并不是要等到需要递交某个请求时再去对请求类型进行设置，而是通过一个统一的方式，进行集中的定义。 5.1类型设置 工作流类型设置用于将工作流进行分类，如按照流程的使用性质，我们可以将流程分为日常工作、人事管理、费用相关等。 （图5-1-1） 具体操作为： 1）工作流管理员在（图5-1-1）所示页面选择【工作流程】->【类型设置】，进入如（图5-1-2）所示页面，这里显示的是已有的流程分类； 2）在（图5-1-2）所示中右键点击新建按钮后显示如（图5-1-3）所示的页面，在说明栏中输入流程分类名称后点击保存，一个流程分类就设定好了。 （图5-1-2） （图 5-1-3）
第 1 页 工作流需求说明书 1 前言 为构架完整EDM 产品，更好满足特定用户需求，需要进行项目管理和工作流管理模块的开发。 此需求计划由公司内部提出，在需求讨论和编写过程中，总结PDM 组在“863”项目中开发工作流原型的经验，吸收部分企业对工作流的需求意见，参照国内外同类产品的现有系统，确定了我公司开发的要求和目标。 此工作流需求说明书作为项目组内部开发指导文件。 1.1 目的 开发项目管理和工作流模块，所有的过程逻辑控制在工作流中实现，并通过项目管理进行任务分发、任务提交、过程跟踪等。工作流系统中的服务模块（如工作流引擎）基于DCOM 实现，作为组件提供给系统使用。 本文档的预期读者为项目组开发人员、质量保证人员、市场销售人员及公司领导层。 1.2 范围 实现的项目管理（ProjectManage ）和工作流管理（WorkflowManage ）作为CEDM 的两个模块，不单独包装为产品。 工作流管理实现WfMC 定义的基本功能：工作流引擎、图形化定义工具、工作流客户端、工作流管理平台。但实现的功能为WfMC 定义功能的子集，不考虑异构工作流系统间的交互，不考虑数据对象在工作流上的传递，不考虑工作流结点上脚本的实现。 项目管理以工作流管理为核心。项目加载工作流模板后，对任务进行描述，包括设定项目承担人、任务截止日期、任务优先级等，进行工作流的启动、流转、操作。项目管理不包括对设备等其他非人力资源的调度，不负责对项目进度排程的优化和组合。 1.3 定义、缩写词、略语 WfMC(Workflow Management Coalition)工作流管理委员会，有关工作流的国际标准化组织。
Jira工作流项目设置操作指南 转载一篇关于Jira的文章 Jira工作流项目设置操作指南 一、几个概念 在具体开始创建一个Jira的工作流项目之前，必须先了解几个Scheme概念，Scheme 这里可以理解为“组合设计方案”。 Scheme 相关设计元素 说明 Issue Type Scheme Issue Type 定义一个项目拥有哪些问题类型，例如缺陷、需求、变更请求、问题、建议等 Notification Scheme Event 定义一个项目的邮件发送规则，例如问题创建的时候需要发送给管理者，问题指派的时候需要发送给被指派人等。 Permission Scheme Permission 定义一个项目的操作权限控制规则，例如创建问题的权限，编辑的权限，查看的权限等。不包括工作流的权限和全局权限。 Issue Security Scheme Security Level 定义一个项目的单个问题的查看权限，例如可以对某个或某些敏感问题设定只有指定的人可查看。 Field Configuration Scheme Field Configuration
定义了一个项目中每个问题类型分别需要用到的字段，以及是否必填和默认值等信息 Issue Type Screen Scheme 定义了一个项目中不同问题类型分别对应的视图组合设计方案（Screen Scheme）Workflow Scheme Workflow 定义了一个项目和指定的问题类型对应的工作流。 Screen Scheme（不直接跟项目绑定） Screen 定义了一个视图组合设计方案，例如创建的使用用哪个视图，编辑用哪个视图，以及没指定视图的操作默认使用的视图等。 二、设计步骤 具体开始创建一个工作流项目之前必须按照上表中的相关设计元素一栏所列内容展开，本文按一般的设计思路顺序逐一介绍。 1、确定需要用到的所有Issue Types，并在jira中设计好 2、根据Issue Types确定需要用到的所有字段域，如果非系统默认字段，则需要在jira 中设计Custom Fields，并添加一个Field Configurations，来对每个字段进行显示设置。最好添加一个Field Configuration Schemes来绑定issue type跟Field configuration的关联。 3、根据不同的Issue Type来确定是否需要针对不同的Issue Type设计不同的Workflow，Workflow的设计是最关键的一步，需要全局考虑很多设计元素，例如Permission(工作流权限,谁或哪些角色可以进行工作流操作)、event（一般会使用到邮件通知event）,screen（每一步工作流响应需要绑定到哪个screen）。 A、画出workflow的状态转移流程图，方框代表状态，箭头代表触发状态转移的路径，箭头上的标注代表触发的动作。 B、根据状态转移流程图确定每一个操作的权限控制，以及每一个操作结束触发的event （例如邮件通知） C、根据权限控制的需求，确定用户的组和角色设置（这个也可以在最初规划好）