在OA办公系统中流程作为可拆分复杂工作，并落实到不同人“协同”执行的一种工作方式，往往代表政府机构或企业的一种管理经验积累。比如客户关系中的一个“客户投诉处理流程”，往往通过以下文字进行描述。

          “产品销售出去以后，往往会碰到客户投诉的情况。客户在产品使用过程中，碰到不满意的地方，会通过传真、电话或者是电子邮件进行投诉，投诉如果得不到及时、完善的处理，就会影响客户满意度，进而影响产品的销售。一般的投诉处理流程是这样的：客服部接到客户投诉后，会根据投诉的类型进行分流；假如属于一般投诉，则送商务部，进行客户安抚；假如属于产品质量投诉，则需要送研发部和生产部进行分析和备案，处理后返回商务部。”

          根据以上文字，我们可以粗略的描述工作流的流向状况。流程可以通过简单的流程图表示。比如图1.3，而数据的流向通过箭头表示，分流任务通过选择符号表示。图1.3表示的是很典型的，通过所谓数据流向示意（DFD）图表示的流程。当然了，DFD最大的问题是不能表示并发执行的活动，但作为一般概念理解，图1.3已经足够了。

                  OA办公系统 

          在业务处理中，我们看到流程的定义，一般针对的是业务处理的一种“规范”。政府机构或企业规定了流程化的业务处理，为的是要落实的工作有序化，相关人员按部就班地执行分配下来的任务。要达到这种业务执行的“效果”，必须要有执行机制的配套，比如及时通知相关人员，自动获取状态，然后推进下一步。

          要达到自动化的控制，我们需要另一种定义，这种定义一样可以通过符号表达，但不是为了让人员阅读和理解，而是要让软件系统理解和执行，这就是我们经常听到的“工作流定义（Process Definition）”。软件系统“理解了”流程的定义，才可以按需求实现流程的推进机制。比如某人提交了工作流，流程可以根据下一步活动的安排，发送通知给相关人员，进行待办提示。当下一步涉及的所有人员都完成了彼此的任务，流程通过状态感知，能马上进行下一步的驱动。

          支持将自然语言描述的业务流程转化为软件系统能够理解的“流程定义”并付诸执行的过程，就是我们在不同OA厂商的宣传口号听到的“图形化工作流”、“流程定义符号”，等等软件功能点。通过上述材料的介绍，我们不难总结几个对流程定义的评价标准。

          1. 是否支持并发活动

          2. 是否具有明确的“开始”和“结束”标志

          3. 是否能自动发送流程通知

          4. 是否需要人员具有专业的知识才能定义流程

          标准1、2、3是一个流程是否满足工作流的“有序”和“自动化”两个业务特点。第4方面要求用于流程定义的符号一定要人性化，能和人员对流程的自然表述一一对应。

          图1.3用的是数据流（DFD）图进行表达。数据流图作为结构化程序设计的主要算法示意图，可以在很多描述业务的场景中应用，但存在几方面的不足。

      不支持工作流的并发描述

      不支持流程推进的几种方式（人为推进、系统自动推进）的描述

      不支持回滚描述（当系统遇到未能达到某个阶段目标应如何处理）

      不支持多种和流程互动的描述

      不支持流程不同环节（决策、活动）和相关人员捆绑

          根据这些不足，软件行业的统一化模型语言（UML）中有一套刻画并发活动的活动图描述语言（Activity Diagram）可以解决上述的一些方面，比如：并发和决策。但活动图也有不足的地方，就是缺少人员以及相关的决策机制的描述。比如某个流程环节，需要什么人、做什么事情，都需要通过定义指出，否则就不反映工作流的基本目的是为分工和业务协同而服务的。

                   OA 

          图1.3和图1.4虽然在读者的角度看上去的分别不大，但对软件系统却是意义重大。对图1.3定义出来的流程，软件系统只能通过单步、串型的方式进行执行，也不能确定研发部处理了投诉是不是就可以往下发，还是要等生产部处理了才往下发；而图1.4定义出来的流程，虽然已经制定了质量分流后，应该同时送研发部和生产部，但却不知道是不是自动发送，还是应该让某个人员进行选择性发送。

          由此可见，流程采用什么样的方式定义，已经不是一个纯软件或者纯管理的问题，而是一个综合问题。这个问题的解决，需要软件人员和最终用户进行一个妥协。

      首先，需要软件人员提供一套符号表达流程。这套符号必须可以支持软件系统进行高效执行；

      同时，这套符号对客户非常直观和可理解；客户可以通过灵活应用这套符号来表达流程化的管理制度